How to Configure Exchange Server Hybrid Modern Authentication (HMA) with Microsoft Entra ID

For organizations operating Microsoft Exchange Server on-premises, securing client connectivity is paramount. Traditionally, on-premises Exchange relies on legacy authentication protocols (e.g., Basic Authentication over RPC/HTTP or MAPI/HTTP). These protocols do not natively support Multi-Factor Authentication (MFA), Conditional Access, or Zero Trust device compliance policies, making them highly susceptible to password spraying and credential stuffing attacks. To bridge this critical security gap without migrating mailboxes to the cloud, administrators must implement Hybrid Modern Authentication (HMA). HMA allows on-premises Exchange to seamlessly offload client authentication to Microsoft Entra ID (formerly Azure AD), extending enterprise-grade cloud security to legacy on-premises infrastructure.

The Architecture of Hybrid Modern Authentication

When HMA is enabled, the authentication flow for an on-premises mailbox fundamentally changes. An Outlook client attempting to connect to the local Exchange server no longer sends its username and password directly to the on-premises IIS virtual directory.

Instead, the local Exchange server responds with an HTTP 401 Unauthorized challenge containing a WWW-Authenticate: Bearer header, pointing the client to Microsoft Entra ID. The Outlook client authenticates directly against the cloud (triggering any configured MFA prompts, Windows Hello for Business flows, or Intune device compliance checks). Upon success, Entra ID issues an OAuth 2.0 Access Token. The client presents this token back to the on-premises Exchange server. The local server cryptographically validates the token’s signature against the public keys published by Entra ID, granting access without ever touching the user’s raw password.

Prerequisites for HMA Deployment

Deploying HMA requires a strict baseline infrastructure. Ensure your environment meets the following prerequisites before proceeding:

• All Exchange servers in the organization must be running Exchange 2016 (CU8 or later) or Exchange 2019 (CU1 or later). No Exchange 2013 or 2010 servers can remain in the topology.
• You must have a fully functional Exchange Hybrid configuration established via the Hybrid Configuration Wizard (HCW).
• Microsoft Entra Connect (Azure AD Connect) must be actively synchronizing your on-premises identities to the cloud.
• All external Exchange URLs (e.g., mail.contoso.com, autodiscover.contoso.com) must be published securely and accessible from the internet.

Configuring Entra ID Service Principals

To allow Entra ID to issue tokens for your on-premises URLs, you must mathematically bind your local Exchange namespaces to the cloud Service Principal Object (SPO). This is accomplished using the Azure AD PowerShell module.

First, connect to Entra ID and retrieve your local Exchange namespaces:

Connect-AzureAD
$x = Get-MapiVirtualDirectory | Select-Object -ExpandProperty InternalUrl
$y = Get-WebServicesVirtualDirectory | Select-Object -ExpandProperty InternalUrl
$z = Get-OabVirtualDirectory | Select-Object -ExpandProperty InternalUrl

Next, extract the hostnames from these URLs (e.g., mail.contoso.com) and append them as Service Principal Names (SPNs) to the standard Exchange Online Azure AD application (Application ID: 00000002-0000-0ff1-ce00-000000000000). This explicitly authorizes Entra ID to mint tokens destined for your on-premises hostnames.

$appId = "00000002-0000-0ff1-ce00-000000000000"
$sp = Get-AzureADServicePrincipal -Filter "AppId eq '$appId'"
$sp.ServicePrincipalNames.Add("https://mail.contoso.com/")
$sp.ServicePrincipalNames.Add("https://autodiscover.contoso.com/")
Set-AzureADServicePrincipal -ObjectId $sp.ObjectId -ServicePrincipalNames $sp.ServicePrincipalNames

Enabling OAuth on the On-Premises Organization

Once the cloud is prepared to issue tokens, you must instruct your local Exchange servers to accept them. Log into an on-premises Exchange Server and open the Exchange Management Shell (EMS).

First, verify that the OAuth configuration object has successfully synchronized from the cloud during your HCW setup:

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

If the EvoSts server exists and is marked as default, you can globally enable OAuth authentication across the entire Exchange organization. Warning: This command instructs all Exchange IIS virtual directories to begin issuing HTTP 401 challenges for Modern Authentication immediately.

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Client Behavior and Verification

Following the execution of the Set-OrganizationConfig command, you must restart the IIS worker processes (or simply execute iisreset) on all Client Access servers in the organization to flush the configuration cache.

When users subsequently launch Microsoft Outlook on Windows or macOS, they will no longer see the legacy Windows Security credential prompt. Instead, they will be presented with the modern, web-based Microsoft Entra ID login screen. They will complete MFA, conditional access checks, and token acquisition seamlessly.

To verify that clients are utilizing HMA, instruct a user to hold the CTRL key and right-click the Outlook icon in the Windows system tray. Select Connection Status. In the Authn column, the value should now display Bearer*, mathematically confirming that the client is successfully utilizing an OAuth 2.0 Access Token to communicate with the legacy on-premises infrastructure.