Exchange Online Identity Models & Authentication Demystified (Part 3)

By /

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

Introduction

In part 2 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 third identity model, which is federated identities.

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

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

Exchange Online Client Authentication – The Past & Today

So as we discussed in the previous two parts of this article series, you can choose between three different identity models. Cloud Identities, Synchronized Identities with Password Hash enabled and Federated Identities. Depending on the model chosen, when you access the Exchange Online workload, you will need to:

  • Authenticate with your cloud credentials (UPN and password) when the workload is accessed
  • Authenticate with your cloud credentials (UPN and password), that match the on-premises AD credentials (aka “Same Sign-On”)
  • Authenticate automatically using on-premises AD credentials, when domain-joined and domain-connected (aka “Single Sign-On”)

However, when it comes to the “Federated Identities” model, depending on the client as well as the version of a client used to access the Exchange Online workload, the above does not necessarily match the reality. As you know, we can access our mailbox using several different clients. We have the Outlook Desktop client, Outlook on the Web (OotW), the Outlook app for iOS and Android, ActiveSync based clients, IMAP/POP clients, SMTP clients and clients based on the Exchange Web Services (EWS) protocol such as Outlook for Mac.

When it comes to the different clients accessing the Exchange Online workload in an “Federated Identities” model, they use different endpoints for authentication. We have the following endpoints for Exchange client authentication:

Passive Federation (WS-Fed Passive Profiles)

This endpoint is used by web clients or by all clients that use the new modern authentication method. For now, we will focus on non-modern authentication, so the only Exchange Online client using this endpoint is Outlook on the Web (OotW). A passive profile client that is domain-joined and located on internal network authenticates directly with the AD FS (STS) endpoint on-premises.

More specifically, when the web client connects to “outlook.office365.com” either by redirection from the on-premises Exchange OotW URL in a hybrid deployment scenario or by selecting the Outlook app title in the Office Portal, Exchange Online redirects the web client to the authentication endpoint in Azure Active Directory (login.microsoftonline.com).

Image
Figure 1: Web Client redirected from login.microsoftonline.com to on-premises AD FS farm

The Azure AD authentication endpoint will detect the UPN domain is federated and do another redirection to the internal AD FS endpoint on-premises (in my case “fs.azurelab.dk”), where AD FS will require the client to authenticate.

Once authenticated, AD FS will retrieve the necessary claims related information from Active Directory and provide the web client with a token holding the claims about the user. The client will present the token to Azure AD and after successful authentication, the web client will be redirected back to “outlook.office365.com” and access the mailbox via OotW.

I have tried to explain this flow visually in the below conceptual diagram (Figure 2).

Image
Figure 2: Authentication Flow for Domain-joined Passive Profile Clients on internal network

In case the client was located on an external network, the same steps would apply with the only difference of having the redirection to “fs.azurelab.dk” go through the Web Application Proxy (WAP) servers to the internal AD FS farm to which the external DNS record for “fs.azurelab.dk” would resolve. Since the user is not authenticated, he will need to authenticate via the sign-in page on the WAP servers. Otherwise all the steps apply.

Image
Figure 3: WAP Sign-in Page

Since both internal and external client will always hit “login.microsoftonline.com”, it is possible to have the client remember the UPN of the respective user (Figure 4), so that is doesn’t have to enter it each time he is required to authenticate.

Image
Figure 4: UPN remembered in the web client

Basic Authentication (Basic Auth Profiles)

This endpoint is used by non-browser based clients or non-modern authentication enabled clients that authenticate using basic authentication. Clients such as the Outlook Desktop client, IMAP/POP clients, Exchange ActiveSync (EAS) based clients, Exchange Web Services (EWS) based clients and TLS secured SMTP sessions use basic authentication. Basic authentication based clients have in common that Exchange Online does the authentication with AD FS on behalf of the client also known as proxy authentication.

More specifically, the client sends the Basic authentication credentials to Exchange Online over SSL/TLS (outlook.office3365.com) and then Exchange Online sends the authentication credentials to Azure AD using something called proxy authentication (proxy auth). Azure AD returns the respective endpoint for the on-premises AD FS farm (in my case “fs.azurelab.dk”) to Exchange Online. Note though that Exchange Online connects to the end point through the WAP servers and not directly. The internal AD FS servers then authenticate with Active Directory and is provided with a logon token containing the necessary user claims. The AD FS servers send this token to Exchange Online, which again sends it to Azure AD. Azure AD returns it to Exchange Online in a state where it can be used to authenticate the client.

I have tried to explain this flow visually in the below conceptual diagram (Figure 5).

Image
Figure 5: Authentication Flow for Basic Authentication based Clients

Although this article series is about Exchange Online specific authentication, it its worth mentioning there is a third endpoint known as the Active Federation (WS-Trust Active Profiles) endpoint, which is used by so called rich/MEX clients. This is Office applications (including Skype for Business), but of course except the Outlook desktop client, which we covered above. These clients use the Microsoft Online Services Sign-In Assistant (SIA) assistant if Office 2010 or the built-in SIA DLL files if using Office 2013, to provide the end user with a good SSO experience. Unlike Basic authentication, these clients authenticate directly with AD FS as in they do now use the WAP servers.

A Closer Look at the AD FS Connection Endpoints On-Premises

Let’s take a closer look at the authentication endpoints, that web (browser-based) clients, Rich/MEX Client profiles and Exchange Online (when a Basic authentication client is used) are redirected to on-premises in a federated identity scenario. To do so, we will connect to our AAD/Office 365 tenant using the Azure Active Directory PowerShell module and run the following command:

Get-MsolFederationProperty –DomainName “Insert federated domain” | fl

In my lab environment, they look like those shown in Figure 6.

Image
Figure 6: Federation Property settings in Exchange Online tenant

The AD FS (STS) endpoints in Figure 6 are used as follows:

  • ActiveClientSignInUrl: https://fs.azurelab.dk/adfs/services/trust/2005/usernamemixed is used
    by Basic Authentication based clients
  • FederationMetadataUrl: https://fs.azurelab.dk/adfs/services/trust/mex is used by Rich/MEX clients
  • PassiveClientSignInUrl: https://fs.azurelab.dk/adfs/ls/ is used by web (browser-based) clients and clients with modern authentication enabled (more on this later).

As you can see from the above, we need a more standardized model for the authentication flow, which all of us agree is quite complex today. The authentication flow is of course a little less complicated for non-federated scenarios, but without question, there is a need to have a more standardized approach going forward. And as I mentioned in the introductory of the first article, this is where the dedicated Office client authentication team that was established almost two years ago comes into the picture. Beginning with the next part in this article series, we will take a look at what they have up their sleeve.

This concludes part 3 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

Read Next

1 thought on “Exchange Online Identity Models & Authentication Demystified (Part 3)”

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