My Hybrid Exchange Modern Auth Nightmare

Modern Authentication is a method of identity management that provides more secure user authentication and authorization. It's available for Office 365 hybrid deployments of Skype for Business server on-premises and Exchange server on-premises, as well as, split-domain Skype for Business hybrids.

There is no doubt the security that modern authentication delivers, but many of you may wonder why use it? That’s a great question. Modern authentication is nothing new. In 2017, Microsoft made new tenants leveraging Exchange Online and Skype for Business Online leverage modern authentication by default. For on-premise utilization, you’re still authenticating in the typical manner; however, authorization occurs in Azure Active Directory. This enables some neat features such as the ability to wrapping multi-factor authentication around your on-premise OWA by configuring an app proxy.

This is all good and great, but I want to address the elephant in the room. Enabling modern authentication is not as straight forward as the documentation would lead you to believe. While the benefits are undoubtably beneficial, throughout your project you’re going to wonder why on Earth you’re bothering.

Microsoft does a decent job of describing the pre-requisites, if you know where to look. Which that’s the million-dollar problem to accomplishing this project. I’m going to share some of my experience, because I hope I can save others some stress and hours that me and my team endured trying to get it setup. For my example, this is a simple Exchange 2016 environment that has already been configured to be in a hybrid setup with Exchange Online.


Let’s start with the pre-requisites of Exchange On-Premise specific settings

Special Considerations

  1. Enable OAUTH (Modern auth) for Exchange Online. This is a requirement, especially if you want to move mailboxes back and forth between on-premise and Exchange Online.
    • Connect to exchange online (Find out how here)
    • Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
  2. You must be running Exchange server 2013 CU19 and up, or Exchange server 2016 CU8 and up.
  3. You must ensure there is no Exchange 2010 in your environment.
  4. On your internal and external load balancers, you cannot use SSL offloading.
  5. If you are using a proxy server in your environment, you must define it in your InternetWebProxy property in your exchange config. You can see how to set it here .

Hybrid Exchange considerations

If you are using Exchange server 2013, At least one server must have the Mailbox and Client Access server roles installed. While it is possible to install the Mailbox and Client Access roles on separate servers, we strongly recommend that you install both roles on each server to provide additional reliability and improved performance.

If you are using Exchange server 2016 or later version, at least one server must have the Mailbox server role installed.

There is no Exchange server 2007 or 2010 in the Hybrid environment.

All Exchange servers must have the latest cumulative updates installed. (Not exactly true, but it is a best practice.) We were not at the latest.

General On-premise Prerequisites

If you use ADFS, you should have Windows 2012 R2 ADFS 3.0 and above for federation

Your identity configurations are any of the types supported by AAD Connect (such as password hash sync, pass-through authentication, on-premises STS supported by Office 365, et cetera.)

You have AAD Connect configured and functioning for user replication and sync.

You have verified that hybrid is configured using Exchange Classic Hybrid Topology mode between your on-premises and Office 365 environment. Official support statement for Exchange hybrid says you must have either current CU or current CU - 1. (This more or less confirm best practice.)

Not mentioned in the documentation, but for any load balancers being used, you need to make sure that SSL offloading is not enabled.

Advice About Additional Prerequisites

These are all great recommendations, but I’d like to elaborate a little on number three on the pre-requisites. Do yourself a favor and go ahead and configure the Exchange hybrid. If you do it through Exchange, you need to make sure you go into you Azure AD Connection setup wizard and enabled the Hybrid Exchange. Under the “Optional Features”, it will be the first choice as of 2019.

Responsive image

Even if you do it through ECP on your on-premise servers, you’ll need this for Exchange writeback. That’s a nifty little nugget that Microsoft fails to mention. Reference here. If you have any intention of allowing your users the ability to reset their passwords through OWA, you need to ensure that password writeback is on as well. By doing this, you turn on the suite of self-service password reset options.

Let’s shift the topic a little. All these requirements have been server or Exchange Online focused. What Microsoft doesn’t put emphasis on your endpoints. you really need to think about your current outlook deployment, before you enable modern authentication. Ask yourself these questions:

  1. Are your systems on Windows 10 or older? If you’re not on windows 10, you can’t leverage modern authentication. They give no exceptions to this.
  2. Are you using Outlook 2010? If so, you cannot enable modern auth.
  3. If you’re using Outlook 2013, what version are your clients? To find the outlook client requirements reference this link
  4. What are your methods for quickly deploying registry changes? Are GPO’s your best route? Do you have a deployment tool to push registry settings like with SCCM?
  5. There are specific requirements on the endpoint side of things that should be in place if you’re using Outlook 2013 especially. You absolutely must have the following registry entries on your workstations before you can move forward with modern auth . You can find those registry entries by visiting this link
    • The following registry entries need to be in place.
      • HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL DWORD and set the value to 1
      • HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version DWORD and set the value to 1

The night you go live with modern auth, you will need to enable a registry entry to use Exchange Online for Autodiscover. This registry setting is needed regardless of your outlook version. It is important that you do NOT enable this registry setting until you have enabled modern authentication. If you do, you will redirect all your outlook clients out to Exchange online for Autodiscover. For us the need for it was few and far between, but we did apply it to systems that struggled to get the setting to remediate prompts for Autodiscover.

When you go to enable a GPO, you will want to have an entry to create the DWORD, and another that is MODIFY, so that existing values can be updated. To revert it, you will flip the entry to value of 0.

HKEY_CURRENT_USER\Software\Microsoft\Exchange\AlwaysUseMSOAuthForAutoDiscover DWORD value of 1.

If you have the opportunity, enable Seamless SSO (Single-Sign On). This will vastly improve the end user experience once you enable modern auth. When modern auth is turned on, the end user will see a pop-up where the users account is signed into Office 365. This established the OAUTH token. Without seamless SSO, then you will need to enter in a password. There are circumstances where a user may need to enter in their email address anyways, so have seamless SSO will grab the current logged in session of the Windows 10 workstation and pass it through. (Make sure you’re using passthrough auth). Use the following link to see how to setup Seamless SSO

Next, you need to ensure that your Windows 10 workstations have the Windows Credential Manager (VaultSvc). In order for Seamless SSO to work, it leverages the Windows Credential Manager to store the OAUTH tokens. If the service is not enabled and running, it will not perform Seamless SSO.

Finally, you absolutely cannot turn off MAPI over HTTP. If this is not enabled, you must make sure you’ve configured it. Since you will be doing authorization through Exchange Online, you need this to sustain any connection interruption. RCP is no where near as forgiving so Office 365 will not support RCP.

Enabling Modern Auth

Prepare the Configuration

To get modern auth in place for your on-premise Exchange environment, you need to configure SPN’s (Service Principal Names) with your on-premise web service URL’s.

To get your URL’s hop onto an Exchange server and open up an Exchange Management Shell console and run the following commands.

Get-MapiVirtualDirectory | FL server,*url*
Get-WebServicesVirtualDirectory | FL server,*url*
Get-ActiveSyncVirtualDirectory | FL server,*url*
Get-OABVirtualDirectory | FL server,*url*

Next, you’ll need to connect to Azure Active Directory in your tenant. If you have not installed the PowerShell modules, you’ll need them.

Run the following from a PowerShell module

Install-Module AzureAD

Connect and sign in by running


Once you’ve connected, run the following command.

Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames

Take note of the output.

You need to add SPN’s for MAPI, ActiveSync, EWS, and OAB. Ensure set each virtual directory for both your internal and external addresses. For this example, the external URL is" and the internal address is

To do so you can run the following:

$x= Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000
Set-MSOLServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 -ServicePrincipalNames $x.ServicePrincipalNames

To verify that the OAUTH object exists for each now, run the following:

Get-MapiVirtualDirectory | FL server,*url*,*auth*
Get-WebServicesVirtualDirectory | FL server,*url*,*oauth*
Get-OABVirtualDirectory | FL server,*url*,*oauth*
Get-AutoDiscoverVirtualDirectory | FL server,*oauth*

For example if you look at MAPI you’d see the following:

Server EX1
InternalUrl :
ExternalUrl :
IISAuthenticationMethods : {Ntlm, OAuth, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}

Now verify that your EvoSTS value is present by running the following from your exchange management shell:

Get-AuthServer | where {$_.Name -eq "EvoSts"}

Turning On Modern Authentication

Now onto the meat and potatoes of getting the Hybrid Modern Auth enabled. It’s simply two commands. I was extremely skeptical that this was all there was to it, but it’s really just these two.

Set-AuthServer -Identity EvoSTS -IsDefaultAuthorizationEndpoint $true
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Turn Off Modern Auth

In the event that you need to revert the settings encountered

Set-AuthServer -Identity EvoSTS -IsDefaultAuthorizationEndpoint $false
Set-OrganizationConfig -OAuth2ClientProfileEnabled $false

From my experience it will take about 15 minutes to propagate to your Exchange environment and sync up with Exchange Online to make the setting change and reflect in end users outlook clients.

To verify, you’ll close your outlook and re-open the client.

Then you need to hold down the CTRL key at the same time you right click the icon for the Outlook client (also in the Windows Notifications tray) and click 'Connection Status'. Look for the client's SMTP address against an 'Authn' type of 'Bearer*', which represents the bearer token used in OAuth.

The Aftermath

After you have enabled modern auth, there is a strong likelihood that your end users will call into your help desk. Make sure to have them armed with as much information as possible.

It might be beneficial to send a communication out to your business of the potential impacts to having this enabled

It would behoove you to have something like a batch file or SCCM package available that will apply the required registry settings

Having documentation, communications, and even training for your help desk of how to troubleshoot a user’s workstations will save you a lot of headache and arm your business for success

Make sure a user’s credential manager service is running. If it’s not, they will continue to get password prompts. If the service is running, you likely need to set the Autodiscover registry entry. Since the entry is under the HKCU hive, you will need to assist the end user while they are logged in.

That’s It!!!

I sincerely hope that this helps at least someone have better success and not go through some of the pain that I had. Please feel free to leave feedback if you find erroneous information!