MSB365 - The Microsoft Blog

Implementing Hybrid Modern Authentication (HMA) with 100% Cloud Mailboxes

The Use Case: Why HMA if Mailboxes are in the Cloud?

A common misconception is that once all mailboxes are migrated to Exchange Online (EXO), the on-premises Exchange server is just a management tool. However, in a Hybrid Infrastructure with Centralized Mailflow, your on-premises servers still act as vital endpoints.

Even if the data sits in Microsoft 365, clients like Outlook often still hit your on-premises Autodiscover endpoints. Furthermore, if you haven't enabled Hybrid Modern Authentication (HMA), these connections might still rely on Basic Authentication (Legacy Auth).

The Goal: Force all authentication attempts—even those touching your local Exchange—to be handled by Microsoft Entra ID (formerly Azure AD). This allows you to enforce Multi-Factor Authentication (MFA) and Conditional Access policies for your entire environment.

Potential Roadblocks

Before moving to the technical steps, analyze these potential points of failure:

MAPI over HTTP Requirement: HMA does not support RPC over HTTP. If your organization is still using the older Outlook Anywhere (RPC/HTTP) protocol internally, HMA will break connectivity for those clients.
SSL Offloading: HMA is extremely sensitive to SSL certificates. If you terminate SSL at a Load Balancer, ensure the communication between the LB and Exchange is still encrypted and uses the correct namespace.
Namespace Consistency: Your internal and external URLs (Virtual Directories) should ideally be identical (Split-DNS). HMA requires that the service principal names (SPNs) match exactly what Entra ID expects.
Legacy Clients: Outlook 2013 requires specific registry keys to support Modern Auth. Outlook 2010 and older are completely incompatible and will stop working.
Public Folders: If you still have legacy Public Folders on-premises, they require additional configuration to work with OAuth/HMA, or users in the cloud may lose access.

Detailed Step-by-Step Implementation Guide

Phase 1: Pre-Flight Checks (On-Premises)

First, we must ensure the local Exchange is ready to handle OAuth requests.

Step 1.1: Verify MAPI over HTTP

Run this in the Exchange Management Shell (EMS):

Get-OrganizationConfig | fl MapiHttpEnabled

If it is False, enable it (Warning: this may cause a brief Outlook restart prompt for users):

Set-OrganizationConfig -MapiHttpEnabled $true

Step 1.2: Check Virtual Directory URLs

HMA requires all web service URLs to be HTTPS. Verify your URLs for MAPI, EWS, ActiveSync, and Autodiscover:

Get-MapiVirtualDirectory | fl InternalUrl, ExternalUrl
Get-WebServicesVirtualDirectory | fl InternalUrl, ExternalUrl
Get-ActiveSyncVirtualDirectory | fl InternalUrl, ExternalUrl

Ensure these match your public SSL certificate and are reachable.

Phase 2: Registering SPNs in Entra ID

You need to tell the cloud which on-premises URLs are allowed to use Entra ID for authentication.

Step 2.1: Identify your URLs

Write down your unique namespaces, for example: mail.contoso.com and autodiscover.contoso.com.

Step 2.2: Add SPNs to the Cloud Service Principal

Connect to Microsoft Graph PowerShell or Azure AD module and find the "Microsoft Exchange Online" service principal. Add your URLs as https://<yourdomain>.

Example logic: You are essentially whitelisting your local server in the cloud's identity provider.

Phase 3: The Exchange Configuration

Now we tell the on-premises Exchange to trust Microsoft Entra ID as an "Auth Server".

Step 3.1: Configure the EvoSTS Provider

The EvoSTS is the specific endpoint for Entra ID. Run this in EMS (replace the URL with your specific tenant ID if required, though the standard one usually works):

Set-AuthServer -Identity EvoSTS -IsDefaultAuthorizationEndpoint $true -RefreshThreshold 30

Step 3.2: Enable HMA

This is the "Point of No Return" command that flips the switch:

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Phase 4: Impact on Other Services

Service	Impact	Mitigation
Centralized Mailflow	Low	SMTP traffic between servers usually uses TLS certificates, not HMA. Mailflow should remain unaffected.
Mobile (ActiveSync)	Medium	Older "Native" mail apps might not support Modern Auth for On-Prem. Recommend users switch to the Outlook for iOS/Android app.
SMTP Auth (Apps)	High	If you have local scanners/applications using Basic Auth via SMTP to your local Exchange, they might break if you disable Basic Auth globally after HMA.

Pro-Tip: Monitoring
After enabling HMA, check the IIS Logs on your Exchange server. You should start seeing "Bearer" tokens in the authentication header instead of "Basic" or "NTLM" for modern clients.

Summary

Enabling HMA for a customer with cloud-only mailboxes and a centralized mailflow is a vital security hardening step. It closes the "backdoor" where attackers could brute-force passwords against on-premises Autodiscover endpoints. By following the steps above, you ensure that Microsoft Entra ID is the gatekeeper for every single connection, regardless of where the mailbox lives.

Securing the Hybrid Gap