skip to Main Content

Configure Hybrid Modern Authentication in Exchange on-premises

How to enable Hybrid Modern Authentication (HMA) in Exchange Server on-premises? We want to secure the Exchange on-premises organization with modern authentication instead of basic authentication. This way, we can use MFA for on-premises user mailboxes and not only for user mailboxes in the cloud. In this article, you will learn how to configure Hybrid Modern Authentication step by step in Exchange on-premises.

Introduction

We have an Exchange hybrid deployment. Most of the mailboxes are in Exchange Online, but we do have mailboxes on-premises. It’s because of company policies. Now that we have mailboxes on-premises, we like the users to authenticate with modern authentication instead of the default basic authentication.

Hybrid Modern Authentication works great with a single Exchange Server or Exchange Server in high availability (load-balanced).

Amanda has a mailbox on-premises, and we can verify that she is connecting with basic authentication in the Outlook desktop application.

Start Outlook. Hold down the CTRL key and right-click on the Outlook client in the Windows system tray. Click Connection Status. In the Authn (authentication) column, you will see Nego* as the authentication scheme. It means you use basic authentication.

Hybrid modern authentication Outlook negotiate

The Authn column needs to show as Bearer*. That’s when you know that Modern Authentication is used.

Hybrid Modern Authentication prerequisites

Before you start to configure Hybrid Modern Authentication, ensure that you did go through these steps:

  1. Exchange Hybrid Configuration Wizard*
  2. Install and configure Azure AD Connect
  3. Exchange Server 2010 is not running in the organization
  4. Exchange Server 2013/2016/2019 with latest Cumulative Update installed

*Hybrid Modern Authentication is not supported with the Hybrid Agent. You will need to leverage the Classic Exchange Hybrid Topology and publish AutoDiscover, EWS, ActiveSync, MAPI, and OAB endpoints for Hybrid Modern Authentication to function with various Outlook clients.

Exchange OWA (Outlook Web Access) and ECP (Exchange Control Panel) do not work with modern authentication. To secure that, we will write another article.

We recommend you to:

  • Enable modern authentication in Exchange Server on-premises organization (this article)
  • Protect Exchange OWA and Exchange ECP (next article)

Hybrid Modern Authentication diagram

In the diagram below, you can see how the Hybrid Modern Authentication flow looks like after implementation.

  1. User with on-premises mailbox starts Outlook and connects with autodiscover to Exchange Server. The connection will redirect to the evoSTS URL which you set.
  2. The Outlook client contacts Azure AD, and the modern authentication sign-in prompt appears. The user will authenticate with the same Conditional Access policies set for the Exchange Online application (cloud app).
  3. After successful authentication, the user will get an Access Token and Refresh Token.
  4. The user provides the Access Token to the Exchange Server on-premises and gets access to the mailbox.
Hybrid modern authentication diagram

Advantages of modern authentication

The advantages for configuring modern authentication in Exchange Server on-premises are:

  • More secure than basic authentication (classic username and password)
  • Configure policies from Azure AD (central location)
  • Modern look and feel for end-user experience

How to configure Hybrid Modern Authentication

We will go through the steps below and make sure that everything is in place before we enable Hybrid Modern Authentication for the Exchange on-premises organization.

Please have a good look every time you are going to run the cmdlets. That’s because you need to perform the administrative tasks in:

  • Exchange Management Shell (Exchange Server on-premises)
  • PowerShell (Azure Active Directory PowerShell)

Step 1. Enable modern authentication in Exchange Online

Read more in the article Enable modern authentication.

To enable modern authentication in Exchange Online, sign in to Microsoft 365 admin center and follow these steps:

  1. Choose Settings in the menu
  2. Click on Services in the top bar
  3. Choose Modern authentication from the list
  4. Check the box Turn modern authentication for Outlook 2013 for Windows and later (recommended)
  5. Click Save

For tenants created before August 1, 2017, modern authentication is turned off by default for Exchange Online and Skype for Business Online.

Enable modern authentication in Exchange Online

Step 2. Get virtual directory URLs

Start Exchange Management Shell as administrator on your Exchange Server on-premises. Run the four cmdlets to retrieve the virtual directory URLs. After that, we get the results in the output. Make a note of all the internal and external URLs because you will need to add these URLs in one of the next steps.

In our example, we have the same name for internal and external URLs. We recommend configuring it like this as it will simplify a lot. If you didn’t, you would see internal addresses that end with .local or .lan in the output.

[PS] C:\>Get-MapiVirtualDirectory | FL server,*url*


Server      : EX01-2016
InternalUrl : https://mail.exoip.com/mapi
ExternalUrl : https://mail.exoip.com/mapi

Server      : EX02-2016
InternalUrl : https://mail.exoip.com/mapi
ExternalUrl : https://mail.exoip.com/mapi



[PS] C:\>Get-WebServicesVirtualDirectory | FL server,*url*


Server               : EX01-2016
InternalNLBBypassUrl :
InternalUrl          : https://mail.exoip.com/EWS/Exchange.asmx
ExternalUrl          : https://mail.exoip.com/EWS/Exchange.asmx

Server               : EX02-2016
InternalNLBBypassUrl :
InternalUrl          : https://mail.exoip.com/EWS/Exchange.asmx
ExternalUrl          : https://mail.exoip.com/EWS/Exchange.asmx



[PS] C:\>Get-ClientAccessServer | fl Name, AutodiscoverServiceInternalUri
WARNING:  The Get-ClientAccessServer cmdlet will be removed in a future version of Exchange. Use the
Get-ClientAccessService cmdlet instead. If you have any scripts that use the Get-ClientAccessServer cmdlet, update them
to use the Get-ClientAccessService cmdlet.  For more information, see http://go.microsoft.com/fwlink/p/?LinkId=254711.


Name                           : EX01-2016
AutoDiscoverServiceInternalUri : https://autodiscover.exoip.com/Autodiscover/Autodiscover.xml

Name                           : EX02-2016
AutoDiscoverServiceInternalUri : https://autodiscover.exoip.com/Autodiscover/Autodiscover.xml



[PS] C:\>Get-OABVirtualDirectory | FL server,*url*


Server      : EX01-2016
InternalUrl : https://mail.exoip.com/OAB
ExternalUrl : https://mail.exoip.com/OAB

Server      : EX02-2016
InternalUrl : https://mail.exoip.com/OAB
ExternalUrl : https://mail.exoip.com/OAB

Run PowerShell as administrator and connect to Azure AD. Sign in with your Microsoft 365 global administrator credentials.

PS C:\> Connect-MsolService

Run the Get-MsolServicePrincipal cmdlet to get the Exchange related URLs in the cloud for the application 00000002-0000-0ff1-ce00-000000000000.

Take note of (and screenshot for later comparison) the output of this command, which should include an https:// autodiscover.yourdomain.com and https://mail.yourdomain.com URL, but mostly consist of SPNs that begin with 00000002-0000-0ff1-ce00-000000000000/.

PS C:\> Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames

00000002-0000-0ff1-ce00-000000000000/mail.exoip.com
00000002-0000-0ff1-ce00-000000000000/autodiscover.M365x877334.mail.onmicrosoft.com
00000002-0000-0ff1-ce00-000000000000/M365x877334.mail.onmicrosoft.com
00000002-0000-0ff1-ce00-000000000000/autodiscover.exoip.com
00000002-0000-0ff1-ce00-000000000000/exoip.com
00000002-0000-0ff1-ce00-000000000000/autodiscover.exoip.local
00000002-0000-0ff1-ce00-000000000000/exoip.local
00000002-0000-0ff1-ce00-000000000000/outlook.office365.com
00000002-0000-0ff1-ce00-000000000000/mail.office365.com
00000002-0000-0ff1-ce00-000000000000/outlook.com
00000002-0000-0ff1-ce00-000000000000/*.outlook.com
00000002-0000-0ff1-ce00-000000000000
https://ps.compliance.protection.outlook.com
https://outlook-sdf.office.com/
https://outlook-sdf.office365.com/
https://outlook.office365.com:443/
https://outlook.office.com/
https://outlook.office365.com/
https://outlook.com/
https://ps.protection.outlook.com/
https://outlook-tdf.office.com/
https://outlook-tdf-2.office.com/
https://ps.outlook.com

Most likely, the https:// URLs from your on-premises (step 2) are missing. Therefore, we will need to add those specific records to this list in the next step.

Step 4. Add on-premises web service URLs as SPNs

If you don’t see your internal and external MAPI/HTTP, EWS, ActiveSync, OAB, and Autodiscover records in this list, you must add them using the command below.

In this example, the URLs are https://mail.exoip.com/ and https://autodiscover.exoip.com/. Replace the URLs with your own.

PS C:\> $x= Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000
PS C:\> $x.ServicePrincipalnames.Add("https://mail.exoip.com/")
PS C:\> $x.ServicePrincipalnames.Add("https://autodiscover.exoip.com/")
PS C:\> Set-MSOLServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 -ServicePrincipalNames $x.ServicePrincipalNames

Verify that you added the new records by running the Get-MsolServicePrincipal cmdlet. Look through the output. Compare the before list/screenshot against the new list of SPNs. You might also take a screenshot of the new list for your records. If you were successful, you would see the two new URLs in the list.

Going by our example, the list of SPNs will now include the specific URLs https://mail.exoip.com/ and https://autodiscover.exoip.com/. See it at the top of the list.

PS C:\> Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames

https://autodiscover.exoip.com/
https://mail.exoip.com/
00000002-0000-0ff1-ce00-000000000000/mail.exoip.com
00000002-0000-0ff1-ce00-000000000000/autodiscover.M365x877334.mail.onmicrosoft.com
00000002-0000-0ff1-ce00-000000000000/M365x877334.mail.onmicrosoft.com
00000002-0000-0ff1-ce00-000000000000/autodiscover.exoip.com
00000002-0000-0ff1-ce00-000000000000/exoip.com
00000002-0000-0ff1-ce00-000000000000/autodiscover.exoip.local
00000002-0000-0ff1-ce00-000000000000/exoip.local
00000002-0000-0ff1-ce00-000000000000/outlook.office365.com
00000002-0000-0ff1-ce00-000000000000/mail.office365.com
00000002-0000-0ff1-ce00-000000000000/outlook.com
00000002-0000-0ff1-ce00-000000000000/*.outlook.com
00000002-0000-0ff1-ce00-000000000000
https://ps.compliance.protection.outlook.com
https://outlook-sdf.office.com/
https://outlook-sdf.office365.com/
https://outlook.office365.com:443/
https://outlook.office.com/
https://outlook.office365.com/
https://outlook.com/
https://ps.protection.outlook.com/
https://outlook-tdf.office.com/
https://outlook-tdf-2.office.com/
https://ps.outlook.com

Step 6. Verify OAuth virtual directories

Now verify OAuth (modern authentication) is correctly enabled in Exchange on-premises on all virtual directories that Outlook might use. Run the cmdlets in Exchange Management Shell.

If OAuth is missing from any server and any of the four virtual directories, you need to add it using the relevant commands before proceeding (Set-MapiVirtualDirectory, Set-WebServicesVirtualDirectory, Set-OABVirtualDirectory, and Set-AutodiscoverVirtualDirectory).

[PS] C:\>Get-MapiVirtualDirectory | FL server,*url*,*auth*


Server                        : EX01-2016
InternalUrl                   : https://mail.exoip.com/mapi
ExternalUrl                   : https://mail.exoip.com/mapi
IISAuthenticationMethods      : {Ntlm, OAuth, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}

Server                        : EX02-2016
InternalUrl                   : https://mail.exoip.com/mapi
ExternalUrl                   : https://mail.exoip.com/mapi
IISAuthenticationMethods      : {Ntlm, OAuth, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}



[PS] C:\>Get-WebServicesVirtualDirectory | FL server,*url*,*oauth*


Server               : EX01-2016
InternalNLBBypassUrl :
InternalUrl          : https://mail.exoip.com/EWS/Exchange.asmx
ExternalUrl          : https://mail.exoip.com/EWS/Exchange.asmx
OAuthAuthentication  : True

Server               : EX02-2016
InternalNLBBypassUrl :
InternalUrl          : https://mail.exoip.com/EWS/Exchange.asmx
ExternalUrl          : https://mail.exoip.com/EWS/Exchange.asmx
OAuthAuthentication  : True



[PS] C:\>Get-OABVirtualDirectory | FL server,*url*,*oauth*


Server              : EX01-2016
InternalUrl         : https://mail.exoip.com/OAB
ExternalUrl         : https://mail.exoip.com/OAB
OAuthAuthentication : True

Server              : EX02-2016
InternalUrl         : https://mail.exoip.com/OAB
ExternalUrl         : https://mail.exoip.com/OAB
OAuthAuthentication : True



[PS] C:\>Get-AutoDiscoverVirtualDirectory | FL server,*oauth*


Server              : EX01-2016
OAuthAuthentication : True

Server              : EX02-2016
OAuthAuthentication : True

Step 7. Confirm EvoSTS auth server object is present

Return to the on-premises Exchange Management Shell. Run the cmdlet and validate that your on-premises has an entry for the evoSTS (a Security Token Service used by Azure AD) authentication provider.

Your output should show an AuthServer with a Name that starts with EvoSts, and the Enabled state value should be True. If you don’t see this, you should download and run the most recent version of the Hybrid Configuration Wizard.

In our output, we have two evoSts authentication servers. That’s because we have our on-premises configured with two tenants.

[PS] C:\>Get-AuthServer | where {$_.Name -like "EvoSts*"} | fl Name,DomainName,IssuerIdentifier,Realm,TokenIssuingEndpoint,Enabled,IsDefault*


Name                           : EvoSts - 5af53ad5-4ce1-4406-bf3f-b8c796cf17b8
DomainName                     : {exoip365.onmicrosoft.com}
IssuerIdentifier               : https://sts.windows.net/fe15bfe6-36b2-4c9d-bf42-51b995f8e9af/
Realm                          : fe15bfe6-36b2-4c9d-bf42-51b995f8e9af
TokenIssuingEndpoint           : https://login.windows.net/common/oauth2/token
Enabled                        : True
IsDefaultAuthorizationEndpoint : False

Name                           : EvoSts - d1c9beac-0655-48e7-9949-5e497af1d38d
DomainName                     : {exoip.com}
IssuerIdentifier               : https://sts.windows.net/d032a20d-16c9-4e5b-87c3-30b055ded8cc/
Realm                          : d032a20d-16c9-4e5b-87c3-30b055ded8cc
TokenIssuingEndpoint           : https://login.windows.net/common/oauth2/token
Enabled                        : True
IsDefaultAuthorizationEndpoint : False

Step 8. Enable Hybrid Modern Authentication

If you have more than one evoSts authentication server, you need to know which one you want to set as default. In Azure AD PowerShell, run the cmdlet to retrieve the tenant ID.

In our example, the tenant ID ends with d8cc. We need to set EvoSts – d1c9beac-0655-48e7-9949-5e497af1d38d as default authorization endpoint.

PS C:\> Get-MsolCompanyInformation | select DisplayName,ObjectId

DisplayName ObjectId                            
----------- --------                            
EXOIP       d032a20d-16c9-4e5b-87c3-30b055ded8cc

In Exchange Management Shell, run the two cmdlets to enable modern authentication on the Exchange on-premises organization.

[PS] C:\>Set-AuthServer -Identity "EvoSts - d1c9beac-0655-48e7-9949-5e497af1d38d" -IsDefaultAuthorizationEndpoint $true
[PS] C:\>Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

If the Exchange on-premises version is Exchange 2016 (CU18 or higher) or Exchange 2019 (CU7 or higher) and hybrid was configured with HCW downloaded after September 2020, run the following command in the Exchange Management Shell on-premises.

Change the identity (copy from step 7) and domain name to your own.

[PS] C:\>Set-AuthServer -Identity "EvoSts - d1c9beac-0655-48e7-9949-5e497af1d38d" -DomainName "exoip.com" -IsDefaultAuthorizationEndpoint $true
[PS] C:\>Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Step 9. Restart Internet Information Services

You can restart the Internet Information Services (IIS) on the Exchange Servers to speed the process.

[PS] C:\>iisreset

Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted

Step 10. Outlook registry requirements

Make sure that you have one of the below Outlook clients running that support modern authentication. Outlook 2010 is not supported, and it will not work. Upgrade your Outlook client to a version that supports modern authentication.

Outlook versionModern auth supportEnableADAL reg key requiredAlwaysUseMSOAuthForAutodiscover reg key required
Outlook 2010NoNot availableNot available
Outlook 2013YesYesYes
Outlook 2016YesNoYes
Outlook 2019YesNoYes
Outlook 365YesNoYes

Microsoft recommends that users force Outlook to use modern authentication by setting the DWORD value of the following registry key to 1.

HKEY_CURRENT_USER\Software\Microsoft\Exchange\AlwaysUseMSOAuthForAutoDiscover
Add registry AlwaysUseMSOAuthForAutoDiscover

If you have Outlook 2013, you need to add two more DWORD values. Add the DWORD value to 1 in the following registry subkeys:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version

Verify your work

Once you enable Hybrid Modern Authentication, a client’s next login will use the new auth flow. Note that just turning on Hybrid Modern Authentication won’t trigger a reauthentication for any client, and it might take a while for Exchange to pick up the new settings. That’s why an iisreset on the Exchange Server(s) in the previous step will speed it up.

You can hold down the CTRL key and right-click the Outlook client in the Windows system tray. Click Connection Status. Look for the client’s SMTP address against an Authn type of Bearer*, representing the bearer token used in OAuth.

Hybrid modern authentication Outlook bearer

You did successfully configure Hybrid Modern Authentication in the Exchange on-premises organization.

Read more: Hybrid Configuration Wizard fails to connect »

Conclusion

In this article, you learned how to configure Hybrid Modern Authentication in Exchange on-premises. Follow the steps to configure OAuth between Exchange Online and Exchange on-premises.

Did you enjoy this article? You may also like Outlook prompts for password after migration to Office 365. Don’t forget to follow us and share this article.

ALI TAJRAN

ALI TAJRAN

ALI TAJRAN is a passionate IT Architect, IT Consultant, and Microsoft Certified Trainer. He started Information Technology at a very young age, and his goal is to teach and inspire others. Read more »

This Post Has 11 Comments

  1. Ali,

    Thank you for the leg work here! Good work! Exciting prospect for those who cannot move mailboxes to the cloud. I just want to confirm that this pattern can work when Azure is delegating to an external IdP like Okta for authentication. Note, we are hoping to delauth to Okta and naturally delauth to AD and apply a sign on policy that prompts for MFA.

    Thoughts?

    Best Regards,
    Bryan

  2. we do have skype for business on-prem and UM role enabled on the exchange 2016 on-prem . Do we need to enable skype for business on-prem for HMA in-order to ensure functionality doesn’t break

    Our initial requirement is to set up conditional access policies for mobile devices via intune, we only have exchange on-prem at moment and we don’t intend to make changes on the skype for business

    1. It’s recommended that the HMA state be the same across Skype for Business and Exchange (and their online counterparts) to reduce the number of prompts. That’s because Skype for Business and Exchange work close with each other.

      Configure HMA for both Exchange and Skype for Business. You have to set it in four places:

      -EX (Exchange Server on-premises)
      -EXO (Exchange Online)
      -SFB (Skype for Business)
      -SFBO (Skype for Business Online)

  3. Hi ALI TAJRAN,
    Thanks for the great article.

    I have 2 questions.
    In on-premises Exchange with basic authentication, could you please explain how it works, authenticating user’s AD credentials, when users open Outlook without them entering their AD credentials how Outlook validates their credentials auto? Also explaining the traffic flow for basic authentication.

    Second question was when modern authentication was enabled for on-premises users there was an issue observed where users were prompted with Microsoft sign-in option when they opened Outlook so modern authentication change was rolled back. Why this could occur?

    Appreciate your feedback for these questions.

    Thanks.
    Dinesh

  4. Hello,
    Thanks you for such a great article.
    Question.
    If my company still uses activesync clients in office 365 and on-premise, will we harm them because they still have to use basic authentication with their mobile devices?

    1. No, it will not affect the users.

      When you enable modern authentication, you allow its use. It doesn’t mean that basic authentication doesn’t work anymore. Your existing basic authentication client will continue to work.

      From there, you can start to identify the basic authentication clients and start moving them to modern authentication.

  5. Hello, thank you for this great guide. I have one question: Does it affect user when i activate Modern Authentication in Exchange Online? (In your guide the Step 1.) Because i would first activate it and see what happens for some time before continuing. And already disable some legacy protocols.

    Thanks a lot!

    1. Hi Edmund,

      No, it will not affect the users.

      When you enable modern authentication, you allow its use. It doesn’t mean that basic authentication doesn’t work anymore. Your existing basic authentication client will continue to work.

      From there, you can start to identify the basic authentication clients and start moving them to modern authentication.

      1. Great to hear that, thank you very much for this information. You have a really great site with great guides just perfect for people like me who starts to work more with O365. Keep on going 🙂

  6. For this to work properly, do I have to point the AutoDiscover DNS record to the on-premise Exchange instead of Office 365?

    1. If you have mailboxes in Office 365 only, you don’t need to enable Hybrid Modern Authentication on-premises. You might want to verify that modern authentication is enabled in the tenant.

      Do you have:

      -Mailboxes on-premises? Autodiscover needs to point to the on-premises Exchange Server.
      -Mailboxes in Office 365 only? Autodiscover needs to point to Office 365.
      -Mailboxes on-premises and in Office 365? Autodiscover needs to point to the on-premises Exchange Server.

      Read more: Autodiscover URL in Exchange hybrid.

Leave a Reply

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