Over the next few weeks I undergo a move of critical organization services to Office 365.  Most of the subsequent posts will be related to activities required
to prepare the existing environment for O365.  This post  will focus on the three options for allowing users to access O365.

In order for users to access O365, they need to authenticate.  Office 365 authenticating takes place with the help of Azure Active Directory.   There are three options for authenticating to O365:

Cloud Identity – This is the simplest option; using Azure Active Directory (AAD) for authentication.  No on premise servers are needed when using this option and you can use a custom domain.  The downside with this option is that users need to log in every time they access O365.  Also, there is no synchronization between domain passwords and AAD, so users will need to track two sets of passwords in environments that use Active Directory.

Same Sign On – Same Sign On (not to be confused by Single Sign On) uses an agent to synchronize local AD properties with AAD.  Administrators can select the AD objects to replicate in the agent and it only passes along password hash values to AAD.  There is no risk to users’ passwords being compromised by only passing the hash value to AAD.   The advantage with this option is that domain passwords can be used to connect to O365 resources.  The drawback is that users need to sign in every time they access O365 services, even when connecting from a domain joined computer.

Single Sign On – Single Sign On provides the best user experience for most corporate environments.  In this configuration, users can access O365 resources outside the corporate domain with their AD email address and password.  This allows access to O365 resources within the organization without requiring users to sign in.  The downside to this is it’s the most complicated to implement.