Exchange Online Identity Models and Authentication Demystified (Part 1)

By /

If you would like to read the other parts in this article series please go to:

Introduction

In this article series, I will provide you with an insight into the authentication story for Exchange Online. That is, I will go through the fundamentals, which are the available identity models, but I will also explain the authentication methods for the different users/clients/devices. Since the authentication story is going through a significant transformation, I will explain how the authentication is today and what you can expect in the near future.

When it comes to improving the authentication story, the Office 365 Business Group has really listened to the customer feedback received over the last couple of years and although we didn’t see many changes for, if you ask me, too long this doesn’t mean nothing has been going on inside Microsoft. Actually a team was put together to only focus on improving the authentication story for Exchange Online users/clients and Office 365 workload Users/clients in general.

Note:
Although a big chunk of the stuff we will cover in this article series will also apply to several of the other Office 365 workloads, our main focus will be on the Exchange Online workload.

Let’s get going. As usual, we have a lot to cover.

Starting with the Fundamentals – Identity Models

So as many of us know, the workloads included with the Office 365 Software As a Service (SaaS) offering are really just workloads enabled on an Azure Active Directory (AAD) tenant. This means that provisioned objects (cloud identities or synchronized users) are stored in the AAD tenant and authentication occurs against the respective AAD authentication endpoints. For this reason, one of the very fundamental and important decisions you need to take is around what identity model to use within the organization.

The authentication process differs quite a bit depending on the identity model you decide to use. We have three identity models to choose from, as depicted in the following conceptual diagram.

Image
Figure 1: Conceptual diagram of the three identity models available

Cloud Identities

The first identity model is cloud identities where users are provisioned directly in the AAD/Office 365 tenant using the Office 365 or Azure portal. The portal also supports bulk user provisioning based on a CSV containing up to 250 users. For more advanced provision requirements, you can of course also use the Azure Active Directory PowerShell for the provisioning process.

Image
Figure 2: Users provisioned directly in the tenant

The major benefit of the cloud identity model is that you do not need to make any changes or deploy any new servers in the on-premises infrastructure.

Image
Figure 3: Authentication for “Cloud Identities” model

However, since the cloud identity model means that a new identity will be created for the end users, it also means the end users will be provided with a new set of credentials. For this reason, this identity model is primarily targeted at:

  • Small enterprises that do not already have an on-premises Active Directory. Since the cloud identity model does not require any servers to be deployed on-premises, the enterprises can get up and running quickly.
  • Larger enterprises that want to try Exchange Online and other Office 365 workloads without needing to make significant changes in the on-premises Active Directory. If you go through this scenario, you can later convert to one of the other identity models if required. This is done by matching the cloud user identities with the respective on-premises Active Directory users using SMTP based soft matching.
  • Enterprises with up to 2.000 mailbox users that for one reason or another wish to migrate from on-premise Exchange to Exchange Online using a cut-over migration. The cut-over migration process itself includes provisioning of the users in the tenant. As mentioned, a cut-over migration supports up to 2.000 user mailboxes, but it is possible to circumvent this limit by hiding users from the GAL or if you are dealing with a merger of multiple on-premises Active Directories to a single AAD/Office 365 tenant. If you go through this scenario, you can later convert to one of the other identity models using the same method as in the previous scenario.

If you are dealing with a large enterprise that already relies heavily on Active Directory, you should not go with cloud identities unless you match one of the above scenarios. Introducing an additional set of credentials to your end users is a move in the wrong direction as they not only need to use different passwords and typically also username as most end users in large enterprises still use the SAM account name (domain\alias) for authentication purposes against the on-premises Active Directory. The AAD/Office 365 tenant expects the end user to authenticate with a user principal name (UPN) in the form of “[email protected]”.

Synchronized Identities with Password Hash Sync Enabled

The second identity model is synchronized identities, where the existing users in the on-premises Active Directory are synchronized to the AAD/Office 365 tenant using a directory synchronization tool. Three Microsoft directory synchronization tools exist today. We have the first one that was released named “DirSync”, which is still fully supported and the one that will be downloaded if you follow the steps in the Office 365 portal. The second tool is the Azure AD Sync (AADSync), which was released in order to provide a tool that supported multi-forest scenarios and more. Although the AADSync tool is still supported by Microsoft, it is no longer possible to download it as it has been replaced by the third tool released. The third tool is named Azure AD Connect (AADConnect) and is the recommended directory synchronization tool going forward as this is where the resources will be used. AADConnect supports all the features included in the AADSync tool and more. In addition, the setup wizard includes steps for configuring AD FS servers in your on-premises environment, if you want to go with federated identities.

All the three above mentioned tools support the password hash synchronization option, which is highly recommended to enable in a directory synchronization scenario where AD FS will not be used for federation purposes.

Image
Figure 4: Enabling Password hash synchronization

Since this identity model works by installing directory synchronization tool on a server in your on-premises infrastructure, you must usually deploy a new server for this purpose. I say usually as it is supported to install the tool on a Domain Controller, however I only recommend doing so in a test environment.

If you deal with a very large organization, you may also need to use a dedicated SQL database as the local SQL Express instance that is installed by default “only” supports up to 100.000 synchronized objects (including users, groups and contacts).

Image
Figure 5: Users synchronized from the on-premises Active Directory

The major benefit of using this identity model over the cloud identities is that users will be provisioned automatically using the directory synchronization tool and will be able to use the same set of credentials as they already use in their on-premises Active Directory resulting in not a “single sign-on” but “same sign-on” scenario where the user object and passwords are managed in the on-premises Active Directory. In a “same sign-on” scenario, the end user will, as mentioned, be able to use his existing credentials but needs to authenticate when accessing an Office 365 workload.

Image
Figure 6: Authentication flow for the “Synchronized Identities with Password Hash Sync enabled” model

When authenticated, a cookie will be generated so the user only needs to authenticate the first time he accesses an Office 365 workload during a workday. The cookie will then usually be kept alive. However, this of course depends on the specific user patterns within the organization.

It is also worth mentioning that the user cannot use his SAM account name to access Office 365 workloads, but instead needs to use his user principal name (UPN), which means that the end user may see this as being provided with a new username as he will typically use his SAM account name for Active Directory based authentication.

Unlike user attributes on an on-premises Active Directory object, which in case of a change are being synchronized every third hour by the synchronization tool, the password of a user is checked every second minute and synchronized in case a password change has occurred.

Moreover, it’s important to note that the end user passwords will not be stored in the AAD/Office 365 tenant. It will be a hash of a hash of the on-premises Active Directory password that will be stored there and the password itself cannot be retrieved through the hash of the hash of the password by a malicious user.

Synchronized identities with password sync enabled is primarily targeted at:

  • Small and larger enterprises that already have an on-premises Active Directory and want end users to be provisioned automatically and also manage users in the on-premises Active Directory as well as allowing end users to use their existing Active Directory password (via same sign-on method) to access Office 365 workloads. All this without the need to make major changes in the on-premises infrastructure as in only deploying a single server on-premises.
  • Larger enterprises that want to trial Exchange Online and other Office 365 workloads without needing to make significant changes in the on-premises Active Directory. If you go through this scenario, you can later convert to the federated identities model if required. This is done by matching the cloud user identities with the respective on-premises Active Directory users using hard matching via the “ImmutableID” or SMTP based soft matching.

This concludes part 1 of this multi-part article in which I provide you with an insight into the identity models available and the authentication story for users/clients connecting to the Exchange Online workload and Office 365 workloads in general.

If you would like to read the other parts in this article series please go to:

About The Author

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top