3 Ways to Plan an Identity Model for Your Office 365 Deployment

When I speak to customers about their Office 365 plans they generally fall into one of two categories:

• A brand new business starting with Office 365, or a “green field” deployment (this is the minority, in my experience)
• An existing business migrating from on-premises Exchange infrastructure to Office 365 (this is the majority)

In each case I like to have a discussion early in the conversation about their expectations for identity management, as this element of the solution will heavily influence how the rest of the Office 365 deployment or migration goes.

For green field deployments the decision is fairly easy. Usually the business has no desire to deploy any on-premises IT infrastructure, except perhaps some basic printer sharing or local file storage, and so there is no on-premises Active Directory to consider. This type of customer can reasonably easily adopt a cloud identity model (which I’ll explain shortly).

Organizations with existing on-premises infrastructure have more to think about. Any of the three identity models might suit them, depending on their long term plans, so we discuss the options and choose one.

Here’s an overview of the three Office 365 identity models to consider.

Cloud Identity

With the cloud identity approach Azure Active Directory becomes the source of identity for the organization, and user accounts for each person in the organization exist in the cloud. The Azure AD identities are used by Office 365 services like Exchange Online, and can also be used to sign on to third party services that support federation with Azure AD such as Dropbox and Salesforce.

Cloud identity works well for organizations with no on-premises Active Directory, because users have a single set of credentials to remember and manage. Cloud identity is less suitable for organizations that have a legacy on-premises Active Directory, because users will have two sets of credentials (one for authentication to on-premises resources, and one for cloud services). When I’ve seen this used in the real world it can be awkward, confusing and frustrating for end users, and often leads to weakening of security by configuring non-expiring passwords, or worse, the same password for everyone.

Administrative effort is also duplicated, requiring IT to make updates to attributes (such as display names, or phone numbers) to two separate objects rather than a single object that is synchronized. However, a cloud identity model doesn’t require IT to deploy and manage any special infrastructure, which may be a positive.

Directory Synchronization

With the directory synchronization approach administration is simplified because the on-premises Active Directory is the source of identity for the organization. Objects and their attributes are synchronized from the on-premises AD to Azure AD using a directory synchronization tool. Microsoft provides several directory sync tools, the latest of which is Azure AD Connect.

As well as objects and their attributes, the directory synchronization tool can also synchronize password hashes from the on-premises AD to Azure AD so that the user can log on to Office 365 services with the same credentials. Password sync is optional, but highly recommended. Without it users will have two sets of credentials to remember, similar to the cloud identity model, which negates one of the key user experience benefits of the directory synchronization approach.

An advantage of the directory sync with password sync approach is that Office 365 authentication is not reliant on the availability of the on-premises Active Directory. However, this approach does not provide for true “Single Sign-On” (SSO) and is usually referred to as “Same Sign-On” instead (which helpfully for marketing folks has the same acronym).

Directory Synchronization with Federated Identity

With the federated identity approach directory synchronization is used, however instead of using Azure AD to authenticate log on requests, Office 365 services pass the authentication requests to an on-premises Active Directory Federation Services (AD FS) service, or optionally, a third party federation service. The federation service (even though third party products are available I will generally just refer to AD FS) is responsible for authenticating the user and providing an authentication token for the user to then access cloud services.

Federated identity removes the need to synchronize password hashes to Azure AD (although you can still do it anyway, in case of the need to switch back to the non-federated authentication method), which makes it an attractive option for organizations that want a single source of identity without passwords (even hashes) being held by an external party. It comes at the cost of having to deploy, manage and maintain the AD FS infrastructure.

The federated identity model can provide a near-true SSO experience for the end user, and also provide much more control for enforcing organizational security policies (such as log on hours, or third party multi-factor authentication), however it relies on the availability of the on-premises AD FS and Active Directory infrastructure for users to log on. This means that the on-premises infrastructure must be resilient and highly available, which of course means deploying multiple servers across multiple sites.

Using Identity Models to Select Migration Method

One of the reasons I discuss identity models early with the customer, aside from ensuring that expectations are set early and user experience is considered, is that it influences the migration methods that we consider for moving their workloads to Office 365 (which is usually email first).

For example, if a customer can’t, or won’t, deploy a directory synchronization tool, then that rules out Staged and Hybrid migrations. Similarly, if a customer is willing to deploy directory synchronization, or has specific needs that AD FS fulfils, then it opens up Hybrid or Staged migration as an option.

I am no fan of the Cutover migration method, mostly because the technical simplicity has a huge trade-off in end user impact and project logistics, so I’m generally happier to see the conversation go towards Hybrid or Staged migration instead. Granted, there are other factors to consider such as the version of on-premises Exchange, so the identity discussion is just one part of the overall picture.

Summary

In this article I’ve described three identity models that can be used with Office 365. Establishing an identity model for your organization’s Office 365 deployment is critical to the success of your project. The identity model has an impact on the end user experience, the infrastructure requirements, and the ongoing capabilities such as restricting log on hours or using third party multi-factor authentication.

The identity model is not a one-time choice that can never be changed. The directory synchronization models can be switched to a cloud identity in future, or you can switch between password sync and federated identity if required. However, it can be difficult (but not impossible) to transition from a cloud identity model to a synchronized or federated model later due to the one-way sync of objects and most attributes.