Office 365 Identity options comparisons


Office 365 has three basic identity models that you can elect to implement. Each model uses a combination of Azure Active Directory for cloud based identity and Windows Server Active Directory for on-premises identity. The cloud only model for example, only uses Azure Active Directory (AD), while the synchronized identity model combines both Azure AD and Windows Server Active Directory, while the federated model solely uses on premises Windows Active Directory. Each has advantages and disadvantages which we’ll now cover.


The most basic identity model is the cloud only identity. This is where a users identity information is managed, maintained and mastered in Office 365. All changes need to be made to user information via the Office 365 admin web portal. The benefit of the cloud only model of identity is that no on-premises equipment or configuration is required and can therefore be accomplished anywhere access to Office 365 is available either via a browser or PowerShell. The disadvantage is that a user may require different credentials to login to their desktop, other cloud services and Office 365. This means, in essence, there is no single sign on (SSO) with the user having to remember the login for each service.


The next identity model is what is known as synchronised identity. Here user properties such as name, email address and so on are copied (or synced) from a local directory (typically Windows Active Directory) to Office 365. This is accomplished through the use of synchronisation software which today typically means Azure AD Connect.


There have been a number of iterations of this synchronization software which initially started life out as DIRSYNC. The problem with DIRSYNC was that although it could copy user object information it could not copy the users password from on-premises to Office 365. This meant that the password would have to be manually set in Office 365 to match the password on-premises. Thus, with DIRSYNC it was entirely possible for on-premises password to differ from Office 365 which was very confusing for users.


The next iteration of the synchronisation software was called Azure AD sync. This included all the features of its predecessor, DIRSYNC, but now incorporated the synchronisation of secure password hashes.


This meant that now not only was a users details synchronised from on-premises but so was an encrypted version of their password. With Azure AD sync in place users on-premises password was now automatically replicated in Office 365.


The current iteration of the synchronisation software is called Azure AD Connect and brings all the benefits of Azure AD Connect but with additional features to allow things like the integration across multiple Active Directory Forests, integration with other third party directories on premises as well as better integration into the cloud.

The synchronised model copies the users details and password hash to Office 365. It however, is not a bi-directional sync, Azure AD Connect (and the previous synchronisation tools) copies from on-premises to Office 365, over writing anything that may already exist there. They do not copy back from Office 365 to a local directory.

The synchronised model requires synchronisation software to be running on a server in the local network. Best practice is to run this synchronisation software on a member server but Azure AD Connect does support being installed on a domain controller while previous versions of sync tools did not.

See my previous articles on installing the various sync tools:

Azure AD Connect tools – the basics

Azure AD Sync Services tool – the basics

Windows Azure Active Directory Sync tool (DIRSYNC) – the basics


The final identity model extends on the synchronisation model by adding Active Directory Federation Services (AD FS) to establish a trust between on premises AD and Office 365. This means that when a user requests an Office 365 services, Office 365 queries the local AD via AD FS to confirm the provided user credential. If the local AD confirms the identity a security token is passed back to Office 365 authenticating the user identity so that Office 365 can then allow the user access to the services.


A federated identity model requires the installation of an AD FS farm on premises, which is a role available on a Windows Server. This farm must be installed on member servers within the existing network. AD FS also requires third party certificates to be installed and maintained. Also, if the business requires users to roam outside the organisation and continue to access Office 365 it will also need to install a secure AD FS proxy farm to handle these external requests from outside its network.

Thus, if a user inside the network needs access to Office 365 services they are authenticated via the internal AD FS and the local AD. If an external user needs to access Office 365 services they do so via the AD FS proxy, which connects securely to the internal AD FS server and then to the local AD.

The challenge with federated identity is that the local AD, AD FS farm and AD FS proxy farm need to be available at all times to provide authentication. If they aren’t then no user login to Office 365 is possible because Office 365 can’t verify the identity of any users because it can’t access the local AD. Best practice is therefore to install these in a load balanced environment which means multiple servers.

The advantage that federated identity provides is that once users are logged on to their local AD they are not prompted again for separate Office 365 credentials. Because Office 365 has established a trust with the local AD, all Office 365 services are provided by credential pass through. This basically means a user isn’t prompted to access Office 365 because they have already logged into their local AD and Office 365 already trusts this. This provides users with a single sign in (SSO) experience.

Each of the models can easily be incorporated into any Office 365 but the most cost effective solution for environments with an existing AD infrastructure is the synchronised model as it generally does require the additional equipment that the federated model does.

You should therefore select the simplest Office 365 model for your needs. It is also possible to change between the models if required but getting it right up front can save a lot of extra configuration down the track. So plan your Office 365 identity requirements early and provide the best login experience for your users.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s