Microsoft Identity as a Service (IDaaS) for Enterprise Architects

“What IT architects need to know about designing Microsoft identity solution for customer while they deployed any public and private cloud (hybrid) with all types of cloud services such as IaaS, PaaS and SaaS“

Brief Introduction

In my previous article “Microsoft Azure AD Identity Solution – Part-2 !!!”, we discussed about Microsoft Azure AD as an identity solution in detail and how Azure identity (IDaaS) solution provides seamless SSO and MFA solution for SaaS and on-premises apps. Apart from that, we also discussed on how an Azure AD collaborates with B2B and B2C scenarios and then finally we talk about the use cases of Azure AD application proxy for accessing on-premises hosted applications.

In this article, we will talk about specific industry use cases scenarios such as identity authentication & authorization for applications hosted in IaaS cloud platform. Here we will discuss on how on-premises Active Directory Domain Services (generally called corporate or enterprise AD DS) and Active directory Federation Services (AD FS) are getting extended into IaaS platform and provides authentication and authorization to applications/workloads hosted in Infrastructure as a Service (IaaS).

In case of customer does not have the on-premises AD DS or AD FS exist into their corporate landscape then customer can leverage the Microsoft managed Azure Active Directory Domain Services (Azure AD DS) for providing authentication and authorization to applications or workloads hosted in Infrastructure as a Service (IaaS).

These are most common scenario used in industry for legacy and modern apps which are either migrated from on-premises into IaaS or directly hosted in IaaS as a fresh build.

Azure AD domain service (Azure AD DS)

Azure AD domain service is a cloud-based domain services that’s completely managed by Microsoft and provide below features:

• This cloud-based domain services provide certain features of on-premises AD such as domain join, group policy, LDAP & Kerberos/NTLM authentication in Azure laaS
• Remember that Azure AD DS has certain limitations as compare to on-Premises AD
• Customer can join their Azure VMs to a domain without deploying DC’s because Azure AD DS is part of customer existing Azure AD tenant and users can login using the same credentials, they use for Azure AD.

Note: This Azure AD managed domain is a standalone domain and is not an extension of on-premises AD domain/forest infra. However, all user accounts, group memberships, and credentials from on-premises AD are available in this via Azure AD tenant

Below figure shows how an Azure AD domain services provides the authentication and other domain services to customer line of business applications running under Azure infrastructure as a service (IaaS)

Synchronize on-premises AD accounts to Azure AD

This solution provides access to all of Microsoft SaaS and cloud-based identity options for Azure PaaS & laaS apps, two below approaches are recommended, choose either one

A. Directory & password synchronization

B. Identity federation

Directory and password synchronization
This is a simplest and recommended option for most enterprise organizations, below figure shows how an Azure AD directory, password sync and MFA can be achieved Azure AD connect tool:

• User accounts are synchronized from customer’s on premises directory to their Azure AD tenant. The on promises directory remains the authoritative source for accounts

• Azure AD performs all authentication for cloud-based services and applications
• Supports multi-forest synchronization

Note: Using cloud-only accounts is not recommended for enterprise-scale customer unless Windows AD is not already used on premises

Password synchronization: Users enter the same password for cloud services as they do on-premises. user’s passwords are never sent to Azure AD instead a hash of each password is synchronized

Multi-factor authentication (MFA): Apps in Azure can take advantage of the Azure MFA service whereas directory sync does not provide integration with on-premises MFA solutions

Identity federation

Federation provides additional enterprise capabilities, but It is also more complex & introduces more dependencies for access to cloud services as shown in figure below:

• All authentication to Azure AD is performed against the on-premises directory via Active Directory federation services (AD FS) or another federated identity provider
• Works with non-Microsoft identity providers
• Password hash sync adds the capability to act as a sign-in backup for federated sign-in (f the federation solution fails)

Use identity federation if
AD FS s already deployed or using a third-party identity provider

Having an on-premises integrated smart card or other MFA solution

Require sign-in audit and/or disablement of accounts

Compliance with Federal Information Processing Standards (FIPS)

Federated authentication requires a greater investment in infrastructure on premises

• The on-premises servers must be Internet-accessible through a corporate firewall Microsoft recommends the use of federated proxy servers deployed in a perimeter network, screened subnet, or DMZ
• Requires hardware, licenses, and operations for AD FS servers, AD FS proxy or web application proxy servers, firewalls, and load balancers
• Availability and performance are important to ensure users can access cloud applications

Placing directory components in Azure IaaS

Consider the benefits of deploying directory components i.e. AAD Connect/AD DS/AD FS to Azure laaS, as shown in figure, especially if customer plan to extend their on-premises AD to Azure virtual machines for their line of business apps

If customer hasn’t already deployed AD FS on-premises, consider whether the benefits of deploying this workload to Azure makes sense for the organization –

• Provides autonomy for authentication to cloud services (no on-premises dependencies) and reduces servers and tools hosted on-premises
• Use a S2S VPN gateway on a two-node duster or ExpressRoute to connect Azure
• Uses ACLs to ensure that Web App Proxy servers can only communicate with AD FS, not AD DCs or others server directly

Extending On-premises AD to virtual machines into Azure IaaS

Refer to the figure which shows the configuration of hybrid deployment on-Premises AD extension to Azure AD and It requires:

• A virtual network (VNet) in Azure laaS
• A S2S VPN or ExpressRoute connection.
• Extending customer on-premises to virtual machines in the virtual network
• Deploying one or more DC in Azure VNet designated as a GC to reduces egress traffic

When to use this solution?

• Schema extensibility and need to write to existing directory identities.
• Support for apps in Azure VNet where network isolation is a requirement
• Support across multiple Azure subscriptions.
• Certificate or smartcard-based authentication for apps

Note: On-Premises AD extension covers lots of limitation of Azure AD DS Below Microsoft FAQ covers features and limitations of Azure AD DS as compare to on premises AD DS: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/faqs

To have further more insight on my previous articles on “Microsoft Azure AD Identity Solution – Part-1 & 2!!!” , Refer to below article:

Microsoft Azure AD Identity Solution – Part-1 !!!

Microsoft Azure AD Identity Solution – Part-2 !!!

Rajeev Ujjwal has more than 18 years of transformation delivery experience in cloud computing, infrastructure, directory service, and cyber security with larger global customers. He is a senior cloud consultant and successfully delivered various kind of global project delivery such as greenfield, consolidation, separation and migration.