I often used to stumble around in understanding the Office 365 Identity Management process and hence I spent some time today trying to do some research on this topic and gained some knowledge about the Identity management process followed in Office 365.
Now this post is for those who are new to Office 365 and would like to understand how the identity management process works and what are the three main models involved in it.
There are basically three main models that can be used for Office 365 identity management and it’s up to you and your business to analyze and choose the one which suits your need.
Office 365 Identity management models:
- Cloud Identity
- Synchronized Identity
- Federated identity
![model]()
Now, let’s take a look at these models.
Cloud Identity:
In this model users are created and managed in Windows Azure Active Directory (WAAD) i.e., in the Office 365 Admin center on the "Users" tab. There is no connection to any other directory. This is the simplest model as there is no integration to any other directory. Each user has an account created in the cloud which does not synchronize anywhere else. Also the password created for this account will be verified by Azure Active Directory and the password policies applied for these accounts are strictly limited only to the Azure Active Directory. However, note that you will still typically need additional on-premises credentials to gain access to a local workstation and local resources. These accounts can’t help you to login to a PC or access a printer that has been joined to the domain.
![cloud]()
Synchronized Identity:
In this model users are created and managed in the on-premises directory and then get synchronized to Office 365 so they can access Office 365 resources. Typically this means running the DirSync appliance or in some cases FIM with the Windows Azure Active Directory Connector. The newer builds of DirSync allow for the user’s password hash to be synchronized up to Office 365. However, please note this does not say clear text password. So using this model users can log on to Office 365 using the same credentials as on-premises with no additional infrastructure. The user enters the same on-premises password as they do in the cloud and during the sign-in this password will be verified by Azure Active Directory.
Note:
This is a one way sync from on-premises AD to Azure active directory and hence any change made to a user's synced account in Office 365 won't be valid.
Sign-in procedure:
The web browser is redirected to the Office 365 sign-in service, where you type the user name and password for your work account. The sign-in service authenticates your credentials and generates a service token, which the web browser posts to the requested service and logs you in.
![Synchronized]()
Federated Identity:
This model is similar to the 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. This is often referred to as single sign-on.
Sign-in procedure:
Federation relies on directory synchronization so that WAAD is populated. When the authentication request is presented to Office 365, the service will then contact the on-premises ADFS infrastructure so that AD is responsible for authenticating the request.
![Federated]()
In addition to these there are many third party identity providers that can be used to implement single sign-on, please take a look at this TechNet link.
Read more articles on Office 365: