Microsoft Azure Active Directory – Identity Models Explained

Muditha Chathuranga is a Senior Technical Consultant at Infront Consulting and a Microsoft MVP in Office Apps and Services. His personal blog, The Cloud Journal, covers Azure, Exchange, O365, Security, and much more. You can follow him on Twitter at @MudithaC .

Microsoft Azure Active Directory (AAD) is a multi-tenant cloud-based directory and identity management service. It combines core directory services, access management, and identity protection in to a single solution. Azure Active Directory is not to be confused with Azure Active Directory Domain Services, which is a separate service and not the focus of this article.

For every organization that chooses to subscribe to Microsoft Online Services– Office 365, Dynamics 365, Intune, etc., choosing the correct identity model for AAD becomes an important task. In this article, we will have a look at the characteristics of each.

While there are no specific dependencies on the identity model of AAD for Microsoft Online Services to function, your organizational needs and other factors such as manageability, access control, auditing, and user experience determine which identity model should be deployed.
 

Cloud Identity

Cloud identity is the simplest identity model for any Microsoft Online Services subscriber. Whenever you sign up for a new Microsoft Online service, it creates an AAD in the backend and ties it with the service(s) you are subscribing to at the time of the sign up, as well as any future subscriptions that you add later.

In this model, all users are created and managed (password reset, user details modification, etc.) in the cloud by using the Office 365 admin portal or the AAD admin panel in the Microsoft Azure Portal. Also, since the identities are created in the cloud, whenever a user tries to access a Microsoft Online service, the authentication happens on the Azure Active Directory. This model is the most convenient and easiest to deploy and manage.

This identity model is best used in small organizations and/or those that have an on-premises directory footprint. It doesn’t require advanced management capabilities.
 

Synchronized Identity

Figure 1: Synchronized Identity Architecture Diagram (Image Courtesy: https://docs.microsoft.com)

Synchronized identity is the most popular identity model for many organizations with an on-premise directory infrastructure. In this model, your on-premise directory gets connected to the AAD with an Azure AD Connect (AAD Connect) server. The AAD Connect server synchronizes on-premise directory objects (user accounts, groups, contacts, etc.) based on the synchronization rules configured in the AAD Connect server.

When user accounts get synchronized, the passwords of those users will be converted into hashes and synchronized, enabling users to use their on-premise user name and password for cloud services as well. In this model, the authentication for cloud services happens in the AAD itself without re-directing users to on-premise infrastructure, maximizing the availability and fault tolerance for identities in the cloud.

This identity model is ideal for organizations with an on-premise directory infrastructure who want to retain the identity management on-premise, quickly provision identities, and start using Microsoft Online Services.

Pass-through Authentication (PTA)

Figure 2: Pass-through Authentication Architecture Diagram (Image Courtesy: https://docs.microsoft.com)

When you choose the synchronized identity model, the authentication happens in the cloud Azure AD itself because the user password hashes are synchronized and stored in the Azure AD. If your organization’s security and compliance policies do not allow sending user passwords as hashes and you need to support Single-Sign On (SSO) for domain joined devices, then you should use Pass-through Authentication (PTA).

When you incorporate PTA, it enables users to validate their authentication directly against the on-premise directory service. This is configured with Azure AD Connect, which uses a simple on-premise agent that listens to validation requests. The agent can be deployed on multiple machines to improve availability and load balancing. Since this only serves outbound communications, it doesn’t require deploying additional infrastructure in the DMZ (as with AD FS) to receive incoming requests.

This authentication method is best suited for those who want to use the synchronized identity model but achieve a certain level of security without compromising simplicity and cost of maintenance as with the federated identity model.

Federated Identity

Figure 3: Federated Identity Architecture Diagram (Image Courtesy: https://docs.microsoft.com)

Federated identity is the most complex — as well as the expensive — form of identity model in the AAD. In this model, you still use AAD Connect to synchronize directory objects to AAD. But the authentication does not happen in the AAD for cloud services. Instead, the authentication request is re-directed to the on-premise federation services infrastructure to validate against your on-premise directory service, providing a true SSO experience for users when they access online services.

This model requires deploying additional on-premise infrastructure in DMZ as well as in the LAN, plus purchase of an SSL certificates from a public CA. When you federate your identities, the whole authentication depends on the availability of your on-premises federation infrastructure. Therefore, at a minimum you would need 4 additional servers in total for the federation services to support fault tolerance and load balancing, given the importance and criticality of the system. Depending on many other factors, you may need to increase the number of servers deployed for federation service.

This model is best suited for organizations that have strict security and compliance policies to handle every authentication on-premise, helping with various access controls, auditing, and other security concerns.

Before deciding on the final model, consider the features and strengths of each. Does the effort to deploy the solution, and the user experience of the sign-in process, address your business requirements? Evaluate whether your organization needs the advanced scenarios and business continuity features each identity model offers.