If you would like to read the other parts in this article series please go to:
- Exchange Online Identity Models and Authentication Demystified (Part 1)
- Exchange Online Identity Models and Authentication Demystified (Part 2)
- Exchange Online Identity Models and Authentication Demystified (Part 3)
- Exchange Online Identity Models and Authentication Demystified (Part 4)
- Exchange Online Identity Models and Authentication Demystified (Part 5)
- Exchange Online Identity Models and Authentication Demystified (Part 7)
Introduction
In part 5 of this article series revolving around the available identity models and the authentication story for Exchange Online, our focus was on the Exchange Online authentication story as it was up until now. We took a closer look at what modern authentication consists of and how the authentication flow looks like for ADAL enabled Outlook clients.
Let’s get going.
Enabling ADAL Client Support at the Tenant Level
So as discussed previously in this article series, most of the Office 365 clients have already been automatically moved to the modern authentication model in an automatic fashion. However, in order to utilize modern authentication for ADAL based clients like the Outlook desktop client, one or two things (depending on the version of the respective Outlook client) must be performed. The first thing is to ensure modern authentication support is enabled in the Exchange Online tenant.
In order to enable this, we need to connect to Exchange Online using PowerShell and set the parameter “Oauth2ClientProfileEnabled” to “true”. This parameter lives under the “OrganizationConfig” noun. Let’s first verify whether it is enabled or disabled for our Exchange Online tenant. We can do so with the following command:
Get-OrganizationConfig | fl *Oauth*
Figure 1: Verifying the configuration state of the OAuth2ClientProfileEnabled parameter
As you can see in my case it is set to false. So we need to enable it using the following command:
Set-OrganizationConfig –OAuth2ClientProfileEnabled $true
Figure 2: Setting OAuth2ClientProfileEnabled to “True”
Note:
It is not possible to enable modern authentication for ADAL based clients in Exchange Online using the UI. However, I was told some time ago that this will be possible via a simple knob sometime in the future.
I have been asked quite a few times whether enabling ”OAuth2ClientProfileEnabled” will affect Outlook 2013 desktop clients that currently use basic authentication based authentication. The answer is no, this will not affect these clients as long as the required registry key (more on this key later) has not been set on the client machine. However, bear in mind that it would affect Outlook 2016 desktop clients as they will try to use modern authentication by default. I am mentioning this as organizations usually want to take changes like this one through a test run on a set of selected pilot users prior to enabling it for everyone in the organization. So if you use Office 2016 in your organization, you would want to disable modern authentication using the relevant registry key (more on this this key in the next section).
Important:
The expectation from the Office 365 team is that customers will use the Outlook desktop 2016 in its default authentication mode, which as mentioned is modern authentication. If you disable ADAL in the Outlook 2016 desktop client in order to use the old basic authentication method while modern authentication is enabled in the Exchange Online tenant, you can run into IDCRL related bugs. Hopefully these will be fixed in the near future, but needless to say, thorough testing is key.
Enabling ADAL for Modern Authentication Clients
Ok so with the tenant side of things prepared, let us switch to the client side. So as I already mentioned, the only Outlook desktop versions that support modern authentication through the use of the ADAL component is Outlook 2013 and Outlook 2016.
For Outlook 2013, you must have the March 2015 update applied. With that said, you should of course always strive after using the latest cumulative updates available for the client. Outlook 2013 also requires a registry key to be set on the client machine. The following registry keys should be set for the Outlook 2013 desktop client:
| Registry Key | Type | Value |
| HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL | REG_DWORD | 1 |
| HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version | REG_DWORD | 1 |
Table 1: Enabling ADAL for an Outlook 2013 Desktop Client
Outlook 2016 supports modern authentication via the ADAL component out of the box. So no need to set any registry keys when in a pure Outlook 2016 environment. However as mentioned in the previous section, you may want to disable modern authentication for all users except the pilot users for a period of time. To disable modern authentication in the Outlook 2016 desktop client, you need to use the following registry key:
Figure 3: Disabling ADAL in the Outlook 2016 Desktop Client
When ADAL is disabled, we get the “good” old basic authentication as shown in Figure 4.
Figure 4: ADAL Disabled in Outlook 2016 – Basic Authentication Prompt
If you use Windows 10 based client devices with Outlook 2016 clients that have modern authentication disabled per above, bear in mind you may have issues with the autodiscover service hanging on search for your mail server settings when setting up a profile. To fix this, you need to add the following registry key:
| Registry Key | Type | Value |
| HKCU\SOFTWARE\Microsoft\Exchange\MSOAuthDisabled | REG_DWORD | 1 |
Table 2: Disabling MSO Authentication for an Outlook 2016 Desktop Client
As you can see, the Outlook 2016 desktop client was clearly developed and tested with modern authentication in mind.
Using an Outlook Desktop Client after enabling Modern Authentication
Let us try to launch an Outlook desktop client, in this case Outlook 2016, but will be the same experience for Outlook 2013, to see how the experience is from the end user side. Instead of the old Outlook credentials dialog box, the end user will now see the modern login screen.
Depending on the identity model used in your organization and whether end users are using a domain-joined client or not, the experience will differ. For the “Cloud Identities” and the “Synchronized Identities with Password Hash Sync Enabled”, the user will be prompted for credentials the first time they launch Outlook. But remember, it will only be the first time as the logon and refresh tokens will come into effect from there. So unless the client is not used for longer periods, the logon token will be refreshed using the refresh token in a transparent fashion meaning that the end user will not be prompted for authentication.
Figure 5: End User Prompted for authentication in a non-federated scenario
If you use a “Federated Identities” model and the client is domain-joined, the end user will get a transparent login experience similar to the browser based Outlook on the Web client (OotW). If the client is not domain-joined, he will be presented with the AD FS login page as shown in Figure 5.
Figure 6: End User Prompted for authentication in a Federated scenario
This concludes part 6 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:
- Exchange Online Identity Models and Authentication Demystified (Part 1)
- Exchange Online Identity Models and Authentication Demystified (Part 2)
- Exchange Online Identity Models and Authentication Demystified (Part 3)
- Exchange Online Identity Models and Authentication Demystified (Part 4)
- Exchange Online Identity Models and Authentication Demystified (Part 5)
- Exchange Online Identity Models and Authentication Demystified (Part 7)
