How to Enable Hybrid Modern Authentication on Exchange Server (Including ADFS as IDP)

What Is Hybrid Modern Authentication and Why Enable It?

In a standard on-premises Exchange Server deployment, Exchange handles authentication itself by talking to Active Directory. Clients send credentials, Exchange validates them against AD, and access is granted. This works, but it is inherently limited to whatever authentication methods Active Directory and Exchange natively support, which means no MFA, no Conditional Access, and no modern identity controls without third-party add-ons.

Hybrid Modern Authentication changes this by making Entra ID (Azure AD) the identity provider for on-premises Exchange. When a client connects, Exchange instructs it to authenticate against Azure AD's EvoSTS endpoint. Azure AD issues an OAuth 2.0 bearer token, which the client then presents to Exchange. Exchange validates the token cryptographically rather than checking a password. From that point, any capability that Azure AD has, MFA, Conditional Access, passwordless FIDO2 keys, sign-in risk policies, applies equally to on-premises Exchange mailboxes.

The practical benefits:

• MFA for on-premises mailboxes without moving them to Exchange Online
• Conditional Access, require compliant devices, block legacy auth, restrict by location, all for on-prem Exchange
• Passwordless, hardware keys, Windows Hello for Business, and Microsoft Authenticator phishing-resistant sign-in work for Exchange Server
• Sign-in logs in Entra ID, on-prem Exchange sign-ins appear in the Azure AD sign-in log, giving you the same diagnostic visibility you have for cloud apps
• App Protection Policies (Intune) apply to Outlook Mobile connections to on-prem mailboxes, enabling copy/paste restrictions, data loss prevention, and remote wipe
• Basic authentication can be disabled on Exchange 2019 after HMA is confirmed working

Prerequisites Checklist

Before running a single command, verify every item below. Some may already be in place if you have an existing Exchange hybrid deployment.

• Exchange Server version: Exchange 2013 CU19 or later, Exchange 2016 CU8 or later, or any Exchange 2019 CU. Exchange 2010 must be fully removed and all mailboxes migrated, HMA will not function in any organization that still has Exchange 2010 servers.
• Azure AD Connect (Entra Connect): Deployed and syncing all users to Entra ID. When HMA is enabled, every user authenticates via Entra ID regardless of where their mailbox sits. Users not in Entra ID cannot authenticate.
• Hybrid Configuration Wizard (HCW) has been run: HCW creates the OAuth trust objects (PartnerApplication, AuthServer) that HMA builds on. If you ran HCW several years ago on an old Exchange version, re-run it to refresh these objects before proceeding.
• MAPI over HTTP is enabled: HMA only works with MAPI over HTTP. It does not work with Outlook Anywhere (RPC over HTTP). Run Get-OrganizationConfig | Select MapiHttpEnabled and confirm True. If it is False, enable it with Set-OrganizationConfig -MapiHttpEnabled $True and allow a 30-minute propagation period.
• HTTPS end-to-end, no SSL offloading: SSL bridging (client → load balancer over HTTPS, load balancer → Exchange over HTTPS) is supported. SSL offloading (client → load balancer over HTTPS, load balancer → Exchange over plain HTTP) is not supported and will cause HMA to fail. If using a load balancer, ensure it presents the full certificate chain including intermediate and root certificates, not just the leaf certificate.
• All clients can reach Azure AD: After HMA is enabled, authentication requires a round trip to Microsoft's cloud for every sign-in. Clients with no internet connectivity, or environments with firewall rules that block login.microsoftonline.com and associated endpoints, will fail to authenticate. There is no fallback to basic auth once a client detects HMA.
• Modern auth capable clients: Outlook 2016 and later support modern auth by default. Outlook 2013 requires the EnableADAL = 1 registry key and must be fully patched. Outlook 2010 does not support modern auth and must be decommissioned. Outlook Mobile (iOS/Android), native iOS Mail, and the native Gmail app on Android all support modern auth on current versions.
• Modern authentication is enabled on the Entra ID tenant: Tenants created after 2017 have this on by default. To confirm: in the Entra ID portal, go to Identity > Overview > Properties, or check via Get-OrganizationConfig | Select OAuth2ClientProfileEnabled from Exchange Online PowerShell.

Step 1: Inventory Your Exchange URLs

Azure AD needs to know which URLs belong to your Exchange organization so it can issue tokens for them. You must collect the internal and external URLs for every virtual directory across every Exchange server in your organization. In a multi-site environment, you may have several distinct URLs per service.

Run these commands from the Exchange Management Shell. Run them on each Exchange server or use the -ADPropertiesOnly switch to query all servers at once:

# Collect all Exchange virtual directory URLs
Get-MapiVirtualDirectory -ADPropertiesOnly | FL Server, InternalUrl, ExternalUrl
Get-WebServicesVirtualDirectory -ADPropertiesOnly | FL Server, InternalUrl, ExternalUrl
Get-OABVirtualDirectory -ADPropertiesOnly | FL Server, InternalUrl, ExternalUrl
Get-ActiveSyncVirtualDirectory -ADPropertiesOnly | FL Server, InternalUrl, ExternalUrl
Get-AutoDiscoverVirtualDirectory -ADPropertiesOnly | FL Server, InternalUrl, ExternalUrl
# Also capture the AutoDiscover SCP (service connection point)
Get-ClientAccessService | FL Name, AutoDiscoverServiceInternalUri

Write down every unique hostname that appears. For most organizations, this will be a single namespace (e.g., mail.contoso.com and autodiscover.contoso.com). Multi-site organizations may have several, mail-us.contoso.com, mail-uk.contoso.com, etc. You will need all of them in Step 2.

Step 2: Register Exchange URLs as Azure AD Service Principal Names

Azure AD has a service principal representing Exchange Online (AppId 00000002-0000-0ff1-ce00-000000000000). For HMA to work, your on-premises Exchange URLs must be added to that service principal's ServicePrincipalNames list. This tells Azure AD that tokens requested for those URLs are legitimate Exchange authentication requests.

Connect to MSOnline PowerShell and run the following. Add one line per unique URL collected in Step 1:

# Connect to MSOnline if not already connected
Connect-MsolService

# Retrieve the Exchange Online service principal
$sp = Get-MsolServicePrincipal -AppPrincipalId "00000002-0000-0ff1-ce00-000000000000"

# View the current list (do not lose these -- you are ADDING to them, not replacing)
$sp.ServicePrincipalNames

# Add your Exchange on-premises URLs (one line per URL)
$sp.ServicePrincipalNames += "https://mail.contoso.com/"
$sp.ServicePrincipalNames += "https://autodiscover.contoso.com/"

# Commit the updated list
Set-MsolServicePrincipal -AppPrincipalId "00000002-0000-0ff1-ce00-000000000000" `
    -ServicePrincipalNames $sp.ServicePrincipalNames

# Verify the new entries are present
(Get-MsolServicePrincipal -AppPrincipalId "00000002-0000-0ff1-ce00-000000000000").ServicePrincipalNames

Step 3: Verify OAuth on All Virtual Directories

All virtual directories must have OAuth authentication enabled. The Hybrid Configuration Wizard sets this by default, so this step is usually a verification rather than a change. Run this from the Exchange Management Shell:

# Verify OAuth is enabled on all virtual directories
Get-MapiVirtualDirectory | FL Server, IISAuthenticationMethods, InternalAuthenticationMethods, ExternalAuthenticationMethods
Get-WebServicesVirtualDirectory | FL Server, OAuthAuthentication
Get-OABVirtualDirectory | FL Server, OAuthAuthentication
Get-AutoDiscoverVirtualDirectory | FL Server, OAuthAuthentication

For the MAPI virtual directory, you should see OAuth in the IISAuthenticationMethods list. For EWS, OAB, and AutoDiscover, OAuthAuthentication should be True. If any are False, set them manually:

# Example: re-enable OAuth on EWS if it was disabled
Set-WebServicesVirtualDirectory -Identity "EXCH01\EWS (Default Web Site)" -OAuthAuthentication $True

# Run for each virtual directory type and each server where it is False

Step 4: Enable HMA: The Two PowerShell Commands

With the prerequisites verified and Azure AD updated, enabling HMA comes down to two Exchange Management Shell commands. These are organization-wide settings, they affect all users and all clients simultaneously.

# Command 1: Set EvoSTS as the default authorization endpoint
# EvoSTS is Azure AD's token-issuing endpoint for Exchange authentication
$evoSts = Get-AuthServer | Where-Object {$_.Name -like "EvoSts*"}
Set-AuthServer -Identity $evoSts.Name -IsDefaultAuthorizationEndpoint $True

# Command 2: Enable OAuth2 client profile (turns HMA on)
Set-OrganizationConfig -OAuth2ClientProfileEnabled $True

To reverse HMA and return to legacy authentication, run:

Set-OrganizationConfig -OAuth2ClientProfileEnabled $False

Because it is a single command to revert, it is safe to enable HMA during a maintenance window, test it, and roll back if needed before the window closes.

What happens on the client after enabling

Existing connected Outlook clients will not immediately switch. A client that already has an authenticated session will keep using it until the token expires or the client reconnects from scratch (usually within 24–48 hours, or on the next reboot). To force an immediate switch for testing, either reboot the test machine or add a new Outlook profile. You can tell which protocol a client is using by holding Ctrl and right-clicking the Outlook system tray icon, then choosing Connection Status. The Authn column will show Bearer for a modern auth session and Nego or Basic for a legacy session.

Step 5: Test and Validate

Use the Test-OAuthConnectivity cmdlet from the Exchange Management Shell to confirm that the on-premises Exchange server can successfully obtain and validate tokens from Azure AD:

# Test OAuth connectivity from Exchange on-premises to Exchange Online
Test-OAuthConnectivity -Service EWS `
    -TargetUri "https://outlook.office365.com/ews/exchange.asmx" `
    -Mailbox "testuser@contoso.com" `
    -Verbose | Format-List

A successful result shows ResultType: Success. Errors here typically point to a misconfigured OAuth configuration, an incorrect EvoSTS entry, or clock skew between Exchange and the domain controllers.

Microsoft also provides a validation script, Test-HMAEAS.ps1, available from the Microsoft documentation, which tests the full Outlook Mobile flow including AutoDetect and AutoDiscover V2 resolution. This is particularly useful if Outlook Mobile connections are failing after enabling HMA.

# Verify the org config setting is active
Get-OrganizationConfig | FL OAuth2ClientProfileEnabled, MapiHttpEnabled

# Confirm EvoSTS is the default endpoint
Get-AuthServer | Where-Object {$_.Name -like "EvoSts*"} | FL Name, IsDefaultAuthorizationEndpoint, Enabled

Using ADFS as Your On-Premises Identity Provider

If your organization uses Active Directory Federation Services (ADFS) on-premises as the identity provider, meaning your Entra ID tenant's domain is federated rather than managed, HMA will work without any additional configuration on the Exchange side. The critical thing to understand is that from Exchange's perspective, it always points to Azure AD (EvoSTS). It never points directly to ADFS. Azure AD handles the redirect to ADFS automatically when it sees a sign-in request from a federated domain.

How the authentication flow changes with ADFS

ADFS prerequisites for HMA

Before enabling HMA, confirm the following ADFS-specific requirements are met:

• ADFS version: ADFS 3.0 (Windows Server 2012 R2) is the minimum. ADFS 4.0 (Windows Server 2016) or later is strongly recommended for its native OAuth 2.0 support, improved token-signing performance, and longer support lifecycle.
• Domain federation is active: Confirm with Get-MsolDomain | Where-Object {$_.Authentication -eq "Federated"}. The domain hosting your Exchange users' UPNs must be federated.
• Azure AD relying party trust exists and is healthy: HCW creates this. Verify with Get-AdfsRelyingPartyTrust -Identifier "urn:federation:MicrosoftOnline" on an ADFS server.
• Token signing certificate is valid: An expired token signing certificate is the most common ADFS-related HMA failure. Check with Get-AdfsCertificate -CertificateType Token-Signing and confirm the NotAfter date has not passed. Auto-renewal (auto-certificate-rollover) should be enabled.
• Clock synchronization: ADFS servers, domain controllers, and Exchange servers must have clocks within 5 minutes of each other. Token validation will fail if skew exceeds this threshold.
• ADFS endpoints for OAuth are enabled: Modern auth clients use the /adfs/oauth2/ endpoints. Verify they are enabled with Get-AdfsEndpoint | Where-Object {$_.Protocol -eq "OAuth" -and $_.Enabled -eq $true}.
• WAP (Web Application Proxy) for external clients: If any users authenticate from outside the corporate network, the ADFS login page must be reachable from the internet. This requires Web Application Proxy (WAP) servers in your DMZ publishing the ADFS /adfs/ls/ endpoint over HTTPS. The WAP certificate must be issued by a publicly trusted CA.

Verify the ADFS federation relationship

Run these checks from an ADFS server to confirm the federation with Azure AD is intact before enabling HMA:

# Check the Azure AD relying party trust exists
Get-AdfsRelyingPartyTrust -Identifier "urn:federation:MicrosoftOnline" | FL Name, Enabled, IssuanceAuthorizationRules

# Check token signing certificate validity
Get-AdfsCertificate -CertificateType Token-Signing | FL CertificateType, Thumbprint, NotAfter, AutoRollover

# Confirm OAuth endpoints are enabled
Get-AdfsEndpoint | Where-Object {$_.Protocol -eq "OAuth"} | FL AddressPath, Protocol, Enabled, Proxy

# Run the built-in ADFS health check
Test-AdfsServerHealth

# From Azure AD (MSOnline) -- verify federation metadata for the domain
Get-MsolFederationProperty -DomainName "contoso.com"
Get-MsolDomain | FL Name, Authentication, Status

Claims rules for Exchange HMA with ADFS

The Azure AD relying party trust in ADFS must issue the claims that Azure AD expects when validating a federated sign-in. If you ran HCW or set up ADFS federation using the standard Microsoft documentation, these rules should already be in place. Confirm the following claims are being issued by running Get-AdfsRelyingPartyTrust -Identifier "urn:federation:MicrosoftOnline" | Select -ExpandProperty IssuanceTransformRules:

• UPN claim (http://schemas.xmlsoap.org/claims/UPN), the user's UPN from Active Directory
• ImmutableID claim (http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID), the user's objectGUID Base64-encoded, or the mS-DS-ConsistencyGuid if you have configured that as the source anchor in Entra Connect. This is the attribute that links the on-prem AD user to their Entra ID object.
• Anchor claim, passes the immutable identifier Azure AD uses to locate the synced object

Missing or malformed claims rules are the second most common cause of ADFS-related HMA failures after expired token signing certificates. If users are redirected to ADFS, authenticate successfully, but then receive an error from Azure AD, claims rules are the first thing to check.

Web Application Proxy for external clients

When a client is outside the corporate network, it cannot reach the internal ADFS farm directly. WAP servers in the DMZ proxy the authentication request inbound to ADFS and return the response. For HMA with ADFS to work for external clients:

• Port 443 must be open inbound from the internet to the WAP servers
• Port 443 must be open from WAP to the ADFS farm on the internal network
• The WAP servers must have a valid publicly trusted SSL certificate covering the ADFS service name (e.g., adfs.contoso.com)
• The ADFS /adfs/ls/ endpoint must be published through WAP

# On a WAP server -- verify published applications
Get-WebApplicationProxyApplication | FL Name, ExternalUrl, BackendServerUrl, ExternalCertificateThumbprint

ADFS-specific troubleshooting

If HMA is enabled but users on federated domains cannot authenticate, work through these in order:

• Expired token signing certificate: Check Get-AdfsCertificate -CertificateType Token-Signing. If expired, the fix is to force a certificate rollover: Update-AdfsCertificate -Urgent, then update the federation metadata in Azure AD with Update-MsolFederatedDomain -DomainName contoso.com.
• ADFS service account issues: If the ADFS service is running under an account whose password has expired, authentication will fail silently. Check the ADFS Event Log (Applications and Services Logs > AD FS > Admin) for service account errors.
• Clock skew: Check w32tm /query /status on ADFS servers and compare against DCs and Exchange servers. All should be within 5 minutes of UTC.
• WAP connectivity: Test from outside the network that https://adfs.contoso.com/adfs/ls/IdpInitiatedSignon.aspx loads correctly. If it does not, the problem is WAP or firewall, not ADFS itself.
• Azure AD sign-in logs: Even with ADFS as the IDP, failed authentications appear in the Entra ID sign-in log with an error code and description. Check Identity > Monitoring & health > Sign-in logs and filter by the user. Error codes like 50126 (bad credentials on ADFS), 70011 (invalid scope), or AADSTS50076 (MFA required) each point to a specific layer of the stack.

What HMA Does Not Change: OWA and ECP

Enabling Hybrid Modern Authentication has no effect on Outlook on the Web (OWA) or Exchange Control Panel (ECP). These browser-based interfaces continue to use forms-based authentication regardless of HMA status. This is intentional and has a practical benefit: if cloud connectivity to Azure AD is disrupted, users can still access their mailboxes via OWA even though Outlook Desktop and Outlook Mobile would fail to authenticate.

If you want to bring OWA under modern, token-based authentication, for example, to enforce MFA on browser access to on-premises mailboxes, you have two options that are configured separately from HMA:

• Azure AD Application Proxy: Publishes OWA as a cloud-managed application, handling authentication via Entra ID before the request ever reaches the on-premises Exchange server
• ADFS Claims-Based Authentication for OWA: Configures Exchange OWA to delegate authentication to ADFS, issuing ADFS tokens for browser sessions. This requires publishing OWA through ADFS relying party rules rather than directly from Exchange

Both approaches are separate projects from HMA and are documented in Microsoft's Exchange hybrid documentation.

Post-Enablement: Blocking Basic Authentication (Exchange 2019)

Once HMA is enabled and confirmed working, Exchange Server 2019 allows you to block basic authentication entirely using authentication policies. This is not available on Exchange 2016 or earlier, on those versions, you can limit basic auth but not block it outright.

Before blocking basic auth, identify any clients still using it. Outlook Mobile is the most likely source of lingering basic auth sessions, profiles created before HMA was enabled will continue using basic auth until the profile is deleted and recreated. You can check for basic auth ActiveSync connections with:

# Find ActiveSync devices still using basic authentication
Get-MobileDeviceStatistics -Mailbox "user@contoso.com" | FL DeviceFriendlyName, ClientType, LastSyncAttemptTime

# ClientType "OutlookService" = modern auth (correct)
# ClientType "Outlook for iOS and Android" = basic auth profile (needs to be recreated)

Once you have confirmed no remaining basic auth clients, block it with an authentication policy:

# Create a policy that blocks all basic authentication protocols
New-AuthenticationPolicy -Name "Block Basic Auth" `
    -BlockLegacyAuthActiveSync `
    -BlockLegacyAuthAutodiscover `
    -BlockLegacyAuthImap `
    -BlockLegacyAuthMapi `
    -BlockLegacyAuthOfflineAddressBook `
    -BlockLegacyAuthOutlookService `
    -BlockLegacyAuthPop `
    -BlockLegacyAuthSmtp `
    -BlockLegacyAuthWebServices

# Apply org-wide
Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Basic Auth"

Troubleshooting Common Issues

Outlook connects but Authn column still shows Nego or Basic

The existing session is being reused. Restart Outlook after rebooting the machine, or create a new Outlook profile. The client will not switch protocols mid-session.

Outlook prompts for credentials repeatedly after enabling HMA

Check that the EnableADAL registry key is set correctly. On Outlook 2013: HKCU\Software\Microsoft\Office\15.0\Common\Identity\EnableADAL = 1. On Outlook 2016 and later: ensure EnableADAL is not set to 0, remove the value if it exists. A value of 0 disables modern auth in Outlook regardless of server configuration.

Outlook Mobile fails to configure a new profile after HMA is enabled

This is usually AutoDetect or AutoDiscover V2 not resolving correctly. AutoDiscover V2 (used by Outlook Mobile's AutoDetect service to locate the mailbox) is not site-aware and may return URLs that are not reachable from the phone. Run the Test-HMAEAS.ps1 validation script. Ensure that your AutoDiscover endpoint is externally reachable and that the load balancer is presenting the full certificate chain.

Test-OAuthConnectivity returns an error

Common causes: the EvoSTS auth server is not set as the default authorization endpoint, the OAuth configuration was not properly established by HCW (re-run HCW to refresh it), or there is a clock skew greater than 5 minutes between the Exchange server and the domain controller handling time sync. Run Get-AuthConfig | FL CurrentCertificateThumbprint and confirm the OAuth certificate is present and not expired.

Conditional Access policies unexpectedly apply to on-premises mailboxes

This is by design. In Entra ID, Exchange Server and Exchange Online are the same application (Office 365 Exchange Online). Any Conditional Access policy that targets this application or uses "All cloud apps" applies to HMA-enabled Exchange on-premises as well. If you had an existing policy requiring MFA for Exchange Online and you enable HMA, that policy immediately applies to on-premises mailboxes too. Review your Conditional Access policies before enabling HMA and plan accordingly, for example, by scoping existing policies to a group containing only cloud mailbox users.