Office 365 is a popular cloud-based office productivity service built around Microsoft Office platform. Initially released in 2011, it has gone through a major upgrade in 2013 and is currently offered with different plans for home, small business, midsize and enterprise customers. Internally, Office 365 platform uses Microsoft Azure Active Directory for identity management and, with the exception of home and small business plans, offers three identity models for different user management scenarios. Recommended approach is to always start with the simplest model and transition to the more complicated one (or back) any time as requirements change. Let’s have a quick look at these models.
Cloud Identity
This is the simplest identity model and also the only one available for home and small business users. It’s typically used when an organization has no existing on-premise directory. In this case, user's details are stored in the cloud directory only and can be managed using the standard Office 365 admin portal, which supports individual account management, as well as rudimentary batch processing using CSV files. Administrators can also reset user passwords or assign certain users (such as helpdesk staff) to perform this for other users. There is no way for a user to reset their own password.
Microsoft also provides a set of modules for Windows PowerShell to enable automation of common administration tasks. Another convenient option is using the Azure AD Graph API, which is a RESTful programming interface for developers to easily build applications integrating with Azure Active Directory.
Synchronized Identity
The majority of organizations that already have an on-premise directory will definitely choose this model, which relies on several tools to synchronize existing user accounts with the cloud directory. Since Microsoft has introduced password hash sync in 2013, this model can also provide a “single sign-on” user experience with the same password on-premises and in the cloud without the complexity of identity federation.
Microsoft provides several different tools for directory synchronization, starting with the old and proven DirSync tool suitable for organizations that have a single Active Directory. In the simplest case DirSync can be installed directly on the domain controller and does not require any additional infrastructure.
Next-generation Azure AD Sync tool is being designed to replace DirSync with many new functions including support for other directories such as LDAP or SQL. More complex scenarios are possible using Microsoft Forefront Identity Manager and different connectors (currently this is still the only solution to synchronize with non-AD directories).
It should be noted that identity synchronization with Office 365 has several limitations. For example, synchronizing a single on-premise directory with several cloud tenants leads to multiple problems and is actively discouraged by Microsoft. Therefore, an organization having several Office 365 subscriptions should consider merging them into one using third party tools before setting up synchronization.
Federated Identity
Since Synchronized Identity model covers the vast majority of use cases with significantly less administration effort, organizations should really consider deploying the federation infrastructure only for certain complex scenarios, for example:
- An ADFS infrastructure is already in place or there are existing third party identity providers;
- Special technical requirements, like smartcard authentication or support for password reset via Office 365 portal;
- Special policy requirements, like login auditing requirement or regulations prohibiting password synchronization.
Important note: one should not forget that federation still requires user accounts to be synchronized with the on-premise directory, so one should never jump directly to federated model without setting up synchronization first. Azure Active Directory currently supports multiple protocols for identity federation with Active Directory Federation Services 2.0 or other third party Security Token Services. The most recent addition to this list has been SAML 2.0, which was announced in March 2014.
Microsoft has established “Works with Office 365 – Identity program”, which is a qualification for third party identity providers for federation with Office 365. A list of qualified providers is maintained here.
Unfortunately, current versions of Office desktop applications have a major incompatibility with many third party identity providers, since they only support the so called active authentication, which can only be accomplished using WS-Trust protocol. Until an update is released later in 2014, Microsoft officially only supports federation with AD FS 2.0 or with qualified third party providers from the list above.
Conclusion
Microsoft has gone a long way since the initial release of Office 365. Current generation of the Azure Active Directory enables different identity models that support nearly all possible usage scenarios. While there are still several major interoperability issues the company has to solve, unless you have a really unusual on-premise identity environment, you should be covered by one of the options above.
This article was originally published in the KuppingerCole Analysts' View Newsletter.