Choosing a sign-in model for Office 365

We get a lot of questions about which of the three identity models to choose with Office 365. Which of these models you choose will impact where you manage your user accounts for Office 365 and how those user sign-in passwords are verified. In this post I’ll describe each of the models, explain how to move between them, and provide guidance on how to choose the right one for your needs.choosesignin_01

Three identity models for Office 365

In the diagram above the three identity models are shown in order of increasing amount of effort to implement from left to right. Our recommendation for successful Office 365 onboarding is to start with the simplest identity model that meets your needs so that you can start using Office 365 right away. Then, as you determine additional necessary business requirements, you can move to a more capable identity model over time. The way to think about these is that the Cloud Identity model is the simplest to implement, the Federated Identity model is the most capable, and the Synchronized Identity model is the one we expect most customers to end up with. Let’s look at each one in a little more detail.


Cloud Identity. In this model a user is created and managed in Office 365 and stored in Azure Active Directory, and the password is verified by Azure Active Directory. Azure Active Directory is the cloud directory that is used by Office 365. There is no equivalent user account on-premises, and there is nothing that needs to be configured to use this other than to create users in the Office 365 admin center.


Synchronized Identity. In this model the user identity is managed in an on-premises server and the accounts and password hashes are synchronized to the cloud. The user enters the same password on-premises as they do in the cloud, and at sign-in the password is verified by Azure Active Directory. This model uses the Microsoft Azure Active Directory Sync Tool (DirSync).


Federated Identity. This model requires a synchronized identity but with one change to that model: the user password is verified by the on-premises identity provider. This means that the password hash does not need to be synchronized to Azure Active Directory. This model uses Active Directory Federation Services (AD FS) or a third- party identity provider.

You can switch between the models

We recommend that you use the simplest identity model that meets your needs. If your needs change, you can switch between these models easily. Here’s a description of the transitions that you can make between the models.

Cloud Identity to Synchronized Identity. This transition is simply part of deploying the DirSync tool. You may have already created users in the cloud before doing this. If you switch from the Cloud Identity model to the Synchronized Identity model, DirSync and Azure Active Directory will try to match up any existing users. There are two ways that this user matching can happen. The first one occurs when the users in the cloud have previously been synchronized from an Active Directory source. In this case they will have a unique ImmutableId attribute and that will be the same when synchronization is turned on again. Users with the same ImmutableId will be matched and we refer to this as a “hard match.”

The second way occurs when the users in the cloud do not have the ImmutableId attribute set. In this case we attempt a “soft match,” which looks at the email attributes of the user to find ones that are the same. If we find multiple users that match by email address, then you will get a sync error. If you want to be sure that users will match using soft-match capabilities, make sure their PrimarySMTP addresses are the same both in Office 365 and in the on-premises Active Directory. If all of your users are entered in the cloud but not in your Active Directory, you can use PowerShell to extract them and then you can import them into Active Directory so that soft match will work.

Synchronized Identity to Federated Identity. This transition is required if you deploy a federated identity provider, because synchronized identity is a prerequisite for federated identity. The user identities are the same in both synchronized identity and federated identity. Because of this, changing from the Synchronized Identity model to the Federated Identity model requires only the implementation of the federation services on-premises and enabling of federation in the Office 365 admin center. Switching from Synchronized Identity to Federated Identity is done on a per-domain basis. The operation both defines the identity provider that will be in charge of the user credential validation (often a password) and builds the federation trust between Azure Active Directory and the on-premises identity provider. When you switch to federated identity you may also disable password hash sync, although if you keep this enabled, it can provide a useful backup, as described in the next paragraph.


Federated Identity to Synchronized Identity. You can convert a domain from the Federated Identity model to the Synchronized Identity model with the PowerShell command Convert-MsolDomainToStandard. Since the password sync option in DirSync is a recent addition, some customers will make this transition to take advantage of that and simplify their infrastructure. This transition can also be a useful backup in case there is a failure with the federated identity provider, because any failure with the federated identity provider—including the physical server, the power supply, or your Internet connectivity—will block users from being able to sign in.

The switch back from federated identity to synchronized identity takes two hours plus an additional hour for each 2,000 users in the domain. Once you have switched back to synchronized identity, the user’s cloud password will be used. We recently announced that password hash sync could run for a domain even if that domain is configured for federated sign-in. Previously Azure Active Directory would ignore any password hashes synchronized for a federated domain. This recent change means that password hash sync can continue for federated domains, so that if you switch from Federated Identity to Synchronized Identity the password validation will be available immediately. If you do not have password sync configured as a backup and you switch from Federated Identity to Synchronized Identity, then you need to configure that, assign passwords with the set-MsolUserPassword PowerShell command, or accept random passwords.

Leave a Reply

Your email address will not be published. Required fields are marked *