Determine the user identity model for your organization
To plan user identities, you must first understand the different types of Microsoft 365 user identities, namely: Cloud identities, Synchronized identities, and Federated identities. An organization can choose to maintain identities only in Microsoft 365, or it can integrate identities with its on-premises Active Directory.
Cloud identities
A cloud identity is a user account that only exists in Microsoft Entra ID.
Important
Azure Active Directory (Azure AD) is now Microsoft Entra ID. Learn more.
While an organization can create a cloud identity with the same name as an on-premises Active Directory Domain Services (AD DS) user account, there isn't any link between the two accounts. They're two different, unique identities, each with their own password. Administrators use the Microsoft 365 admin center to create cloud identities. Most often, only small organizations use cloud identities because they don't need to maintain a local Active Directory implementation.
Synchronized identities
A synchronized identity is a user that exists in an on-premises AD DS and in Microsoft 365. The system synchronizes and links together the AD DS user and the Microsoft 365 user. The system then synchronizes any changes that you later make to the on-premises user account to the Microsoft 365 user account.
Organizations can synchronize their on-premises and cloud identities using either Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync. The features of each tool are examined in greater detail in the training module titled Prepare for identity synchronization to Microsoft 365. These tools synchronize accounts and determine whether to synchronize passwords.
When an organization implements synchronized identities, its on-premises AD DS is the authoritative source for most information. As such, administrators must complete most of the administrative tasks on-premises. The system then synchronizes these changes to Microsoft Entra ID. In contrast, the system only synchronizes a small set of attributes from Microsoft 365 back to AD DS on-premises.
Authentication for synchronized identities occurs in Microsoft 365, unless the organization enabled Pass-Through Authentication (PTA). PTA is an authentication method provided by Microsoft 365 that allows users to authenticate directly against on-premises Active Directory instead of going through the Microsoft Entra ID cloud-based authentication. When an organization enables PTA, authentication for synchronized identities bypasses Microsoft 365 and occurs directly against the on-premises Active Directory.
If an organization doesn't enable PTA, authentication for synchronized identities occurs in Microsoft 365. In this scenario, Microsoft 365 evaluates the username and password without any reliance on the on-premises infrastructure.
Federated identities
A federated identity refers to an identity that an external identity provider (IdP) authenticated. When a user attempts to access a federated service such as Microsoft 365, Microsoft Entra ID redirects the authentication request to a designated, trusted IdP. The IdP is referred to as "trusted" because it has a mutual understanding and agreement with Microsoft 365 or Microsoft Entra ID regarding the authentication and authorization process for federated identities.
In a federated identity scenario, the trust relationship requires the organization to configure the settings and exchange the necessary information between Microsoft 365 or Microsoft Entra ID and the IdP. This configuration process typically includes:
- Configuring the relying party trust. Microsoft provides a set of administrative tools and interfaces that enable an organization's administrators to configure and manage the settings and policies within their Microsoft Entra tenant. The organization administrators have the authority and control to customize and define the policies that govern the authentication and authorization process for their users. So an organization that uses federated identities must configure Microsoft 365 or Microsoft Entra ID to recognize and trust a specific IdP as a valid authority for authenticating its users.
- Exchange of metadata. Microsoft 365 or Microsoft Entra ID exchanges metadata, such as security certificates and endpoint URLs, with the IdP. This metadata allows both parties to communicate securely and verify each other's identity.
- Trust policy configuration. Organizations can configure policies that govern the authentication and authorization process for their federated identities. These policies can define the rules and criteria for accepting the assertions made by the IdP, including:
- Which claims and attributes the organization considers valid.
- How the organization and IdP should handle the authentication process.
- Any other security requirements.
The IdP could be Active Directory Federation Services (AD FS) or another federated identity provider. It authenticates the user using its own authentication mechanisms, such as Windows Authentication (Kerberos) or other supported methods. Once the IdP authenticates the user, it generates a security token that contains the user's identity claims. Microsoft Entra ID then accepts and validates this token to grant the user access to the requested resources.
Implementing federated identities used to be more complex than implementing synchronized identities because of the requirement to implement AD FS. However, Microsoft 365 removed that complexity with the adoption of Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync, both of which deploy most of the AD FS infrastructure.
Because authentication to Microsoft 365 is dependent on the availability of AD FS, service interruptions to the on-premises infrastructure can affect Microsoft 365 authentication. For example, an on-premises Internet outage causes Microsoft 365 authentication to fail. However, organizations can mitigate this issue by placing a copy of AD DS and AD FS in Microsoft Azure.
The main benefit of using federated identities is single sign-on (SSO). Users authenticate at a domain-joined workstation by using their credentials. SSO uses these cached credentials to automatically authenticate to Microsoft 365 services. Synchronized identities typically need to enter their credentials manually when accessing Microsoft 365 services.
Federated identities also take advantage of password policies and account lockout policies in an on-premises AD DS. This design provides more flexibility when managing password policies for Microsoft 365.
Determining the best model for your organization
Each identify model has different advantages and disadvantages. To determine the best option for your company, you must first understand what scenario is best suited for each model, along with the greatest benefit for each model as outlined in the following table.
| Cloud Identity | Synchronized Identity | Federated Identity | |
|---|---|---|---|
| Definition | User account only exists in Microsoft 365. | User account exists in local Active Directory and an identical user in exists in Microsoft 365. | Synchronized user account authenticated by using AD FS. |
| Best for… | Small to medium-sized organizations or organizations that don't need a local Active Directory Domain Service (AD DS) anymore. | Organizations running on-premises Active Directory already and are planning to move to the cloud. | Organizations that want to centralize their authentication and authorization processes. Organizations that run a federated authentication system, or require a special type of sign-in, such as with an ID card, also use this model. |
| Greatest benefit | Simple to use; no extra tools required. | Same Sign-In, and where organizations must manage identities in only one place. | Single sign-on, and where organizations must manage identities in only one place. |