Exchange Online Identity Models & Authentication Demystified (Part 2)

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

Introduction

In part 1 of this article series revolving around the available identity models and the authentication story for Exchange Online, I provided you with an insight into the two of the three identity models (cloud identities and synched users with password hash sync enabled) that are supported with AAD/Office 365. I also explained which types of scenarios were the primary targets for each identity model.

In this part 2, we will continue where we left off in part 1.

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

Federated Identities

The third and last identity model is what we refer to as the “Federated Identities” model. Just like with the “Synchronized Identities with Password Hash enabled” model, this model requires that we synchronize our on-premises Active Directory users to the AAD/Office 365 tenant using one of the supported directory synchronization tools (preferably AADConnect). But the similarities end here. Because although the synchronization aspects are identical, the authentication parts are very different. Unlike with the “Synchronized Identities with Password Hash enabled” model, where a hash of the hash of the password is synchronized together with the user object to the AAD/Office 365 tenant, the Federated Identities model uses Active Directory Federation Service (AD FS) technology to establish a federation trust between the tenant and the on-premises Active Directory.

Note:
You can combine “Federated Identities” with “Synchronized Identities with Password Hash enabled” model. More specifically, you can use the “Synchronized Identities with Password Hash enabled” model as a backup (failover) for “Federated Identities” model. This means that in case your AD FS farm or even your Active Directory is unavailable for a longer period of time, you can convert the domain(s) in the AAD/Office 365 tenant from federated domain(s) to managed domains and thereby allow users to authenticate against Azure Active Directory and be granted access the respective Office 365 workload(s). For the glory details on how this works in detail, see this TechNet Wiki article.

Although it’s generally recommend to choose the least complex identity model, larger organizations that have one or more Active Directory forests and often also a complex on-premises infrastructure in many cases wants to keep the authentication mechanisms on-premises in order to have more control and options available when it comes to granular end user access management. In addition, nowadays there’s also a good portion of organizations that already have an AD FS farm in place for other federation purposes and see it as a natural step to also use this solution for AAD/Office 365 federation purposes as well.

Note:
Although the focus of this article is on Active Directory as the identity provider, Microsoft also support the use of third party SAML 2.0 based identity providers to implement single sign-on (read more here). Shibboleth based Identity Providers are also supported, however only a limited set of clients are supported in such a scenario (read more here).

Another reason to go with “Federated Identities” model over the “Synchronized Identities with Password Hash enabled” model is in order to provide the end users with a true “single sign-on” solution instead of a “same sign-on” solution. True “single sign-on” does not hold true for all client version scenarios though (more on this later in this article series). However, what’s attractive to the organizations is that it’s the end users Active Directory credentials that are used to authenticate against Azure Active Directory.

Image
Figure 1: When user access the AAD/Office 365 logon page being redirected to the on-premises federation service

Image
Figure 2:
Web Application Proxy Logon page

With the “Federated Identities” model, when a user tries to access an Office 365 workload, he will get an SAML security token from AD FS, which is handed to Azure AD as proof for being allowed to access the respective workload as shown in the following conceptual diagram. When it comes to Exchange Online, this flow depends on the client type and client version though as Exchange Online is a little special when it comes to authentication. We will talk a lot more about this later in the article series.

Image
Figure 3: Federated Identities authentication flow

As already mentioned, going with the “Federated Identities” model makes sense for organizations that want more control and options available when it comes to granular end user access management, but you should bear in mind this model requires at least four servers on-premises (two ADFS servers on the internal network and two WAP servers in the perimeter network). Although a single server AD FS and a single WAP server is sufficient as authentication endpoint for several thousand users (of course depending on user concurrency etc.) in AAD/Office 365 you would want to deploy a highly available federation farm. The reason for this is because if the federation service becomes unavailable, your end users will not be able to authenticate against AAD and for this reason also not be able to access any of the Office 365 workloads unless you initiate a failover to password hash sync, which depending on your specific topology can take several hours.

Some of the more important reasons why you want to go with the “Federate Identities” model are listed below:

  • The organization already has an AD FS farm in place and wishes to use this for AAD/Office 365 federation purposes.
  • The organization already has an existing smart card or multi-factor authentication (MFA) solution and do not want to (or are not yet ready to) switch to the MFA solution provided by an Azure AD (required Azure AD Premium subscription).
  • The organization has a security policy stating that a hash of a hash of the on-premises password must not be synchronized to the AAD/Office 365 tenant.
  • The organization wants to leverage the AD FS extranet lockout feature to protect users on the corporate network from AD account lockouts and brute force password guessing attacks. The Office 365 account lockout policy is 10 unsuccessful attempts and after that the end user is forced through a CAPTHA dialog as part of the logon.
  • The organization wants to have a true single sign-on solution and not a same sign-on solution. Bear in mind though that true SSO is not possible for rich clients (such as the desktop Outlook client) that use basic authentication. For Outlook 2013 and later, this can be solved by enabling modern authentication (more on this later in this article series).
  • The organization wishes to control at what time the end users are allowed to access Office 365 workloads using logon hours. Note: Personally, I have never encountered a customer with this requirement.
  • The organization wish to use client access policies to control which clients may access Office 365 based on location (i.e. block Outlook Anywhere from an external network).
  • The organization wants a user account that is being disabled in the Active Directory to be “immediately” reflected for AAD/Office 365 access. It will not be immediately, but quicker than what is the case for the “Synchronized Identities with Password Hash enabled” model.
  • The organization wants to use AD FS based conditional access (workplace join, group membership, device registration, certificate based access etc.).
  • The organization wants to enable password expiry notifications for end users (will be shown in the Office 365 portal).
  • The organization want to make use of custom claim rules for more detailed audit control.
  • The organization wants to provide the end users with a transparent login experience for web based access to Office 365 using smart links.
  • The organization wants detailed information for sign-in attempts (auditing), which will be logged in the Windows event log on the AD FS servers.
  • The organization cannot change/use the UPN as required and instead wants to use alternate login IDs.

This concludes part 2 of this multi-part article in which I provide you with an insight into the new Modern Authentication story and how it affects clients connecting to Exchange Online.

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

About The Author

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