ANAVEM
Reference
Languagefr
How to Configure Hybrid Modern Authentication in Exchange On-Premises

How to Configure Hybrid Modern Authentication in Exchange On-Premises

Secure your Exchange on-premises environment by implementing Hybrid Modern Authentication to replace basic authentication with OAuth 2.0 tokens and enable MFA for on-premises mailboxes.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
March 17, 2026 15 min 6
hardexchange 7 steps 15 min

Why Implement Hybrid Modern Authentication for Exchange On-Premises?

Hybrid Modern Authentication (HMA) represents a critical security upgrade for organizations running Exchange on-premises alongside Microsoft 365. Instead of relying on basic authentication protocols that transmit credentials in easily intercepted formats, HMA leverages OAuth 2.0 tokens issued by Microsoft Entra ID (formerly Azure AD). This architectural shift enables multi-factor authentication for on-premises mailboxes while maintaining seamless user experience across hybrid environments.

What Security Benefits Does HMA Provide?

The primary advantage of HMA is eliminating basic authentication vulnerabilities that have plagued Exchange environments for years. Basic authentication sends usernames and passwords in Base64 encoding with every request, making credentials susceptible to interception and replay attacks. HMA replaces this with time-limited OAuth tokens that cannot be reused maliciously. Additionally, HMA enables Conditional Access policies and MFA enforcement for on-premises Exchange access, bringing cloud-level security controls to your datacenter infrastructure.

Which Exchange Versions Support Modern Authentication?

HMA requires Exchange Server 2016 CU8 or later, with Exchange 2019 CU7+ recommended for the most streamlined configuration experience. Organizations running Exchange 2013 CU19+ can also implement HMA, though the configuration process involves additional manual steps. The September 2020 Hybrid Configuration Wizard automatically enables OAuth for supported versions, significantly simplifying the implementation process compared to earlier manual configurations.

How Does HMA Integration Work with Microsoft 365?

HMA creates a trust relationship between your on-premises Exchange organization and Microsoft Entra ID, allowing cloud-issued tokens to authenticate against on-premises services. This integration requires existing hybrid deployment with Entra Connect synchronizing user identities. The configuration involves registering your Exchange service URLs as Service Principal Names (SPNs) in Azure, enabling OAuth endpoints in Exchange, and configuring virtual directories to accept modern authentication tokens while blocking legacy protocols.

Related: How to Grant User Access to Another Mailbox in Microsoft 365

Related: How to Delegate Exchange Distribution List Management to End

Related: What is OAuth? Definition, How It Works & Use Cases

Implementation Guide

Full Procedure

01

Verify Exchange Hybrid Prerequisites and Modern Auth Status

Before configuring HMA, confirm your hybrid deployment is properly configured and check current authentication methods. This step ensures you have the foundation needed for modern authentication.

Get-HybridConfiguration | Select-Object Identity, OnPremisesSmartHost, Domains
Get-OrganizationConfig | Select-Object OAuth2ClientProfileEnabled, DefaultAuthenticationPolicy

Check your Exchange version and cumulative update level:

Get-ExchangeServer | Select-Object Name, AdminDisplayVersion, ServerRole

Verify external URLs are configured correctly:

Get-WebServicesVirtualDirectory | Select-Object Server, ExternalUrl
Get-AutodiscoverVirtualDirectory | Select-Object Server, ExternalUrl
Get-OwaVirtualDirectory | Select-Object Server, ExternalUrl
Warning: If OAuth2ClientProfileEnabled shows False or external URLs are missing, your hybrid configuration needs completion before proceeding with HMA.

Verification: All external URLs should use HTTPS and be accessible from the internet. Test by browsing to your Autodiscover URL externally.

02

Configure Service Principal Names in Microsoft Entra ID

HMA requires your on-premises Exchange URLs to be registered as Service Principal Names (SPNs) in Azure. This allows Microsoft Entra ID to issue tokens for your on-premises services.

First, identify your EvoSTS application in Azure:

Connect-AzureAD
Get-AzureADServicePrincipal -Filter "DisplayName eq 'Microsoft Exchange Online'"

Get your current Exchange virtual directory URLs:

$OwaUrl = (Get-OwaVirtualDirectory | Where-Object {$_.ExternalUrl}).ExternalUrl.AbsoluteUri
$EwsUrl = (Get-WebServicesVirtualDirectory | Where-Object {$_.ExternalUrl}).ExternalUrl.AbsoluteUri
$AutodiscoverUrl = (Get-AutodiscoverVirtualDirectory | Where-Object {$_.ExternalUrl}).ExternalUrl.AbsoluteUri

Write-Host "OWA URL: $OwaUrl"
Write-Host "EWS URL: $EwsUrl" 
Write-Host "Autodiscover URL: $AutodiscoverUrl"

Add these URLs as SPNs to the EvoSTS service principal in Azure portal:

  1. Navigate to Azure portal > Microsoft Entra ID > Enterprise applications
  2. Search for "Microsoft Exchange Online" or "EvoSTS"
  3. Select the application and go to Properties
  4. Add your Exchange URLs (OWA, EWS, Autodiscover) to the Service Principal Names list
Pro tip: Document all URLs you add as SPNs. Missing SPNs are the most common cause of HMA authentication failures.

Verification: Run Get-AzureADServicePrincipal -ObjectId [EvoSTS-ObjectId] | Select-Object ServicePrincipalNames to confirm your URLs are listed.

03

Enable OAuth 2.0 Client Profile in Exchange On-Premises

Configure Exchange to use OAuth 2.0 tokens from Microsoft Entra ID instead of basic authentication. This is the core HMA configuration step.

Set the authorization server as the default endpoint:

Get-AuthServer | Where-Object {$_.Name -like "EvoSts*"} | Set-AuthServer -IsDefaultAuthorizationEndpoint $true

Enable OAuth 2.0 client profile for the organization:

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

For Exchange 2016 CU18+ or Exchange 2019 CU7+, also configure the OAuth inbound proxy:

Set-OrganizationConfig -OAuth2OnPremisesInboundProxyEnabled $true

If you're using OWA, configure the download domains to include your external URL:

$ExternalDomain = ([System.Uri](Get-OwaVirtualDirectory | Where-Object {$_.ExternalUrl}).ExternalUrl).Host
Set-OrganizationConfig -DownloadDomains $ExternalDomain
Warning: These changes require an IIS reset on all Exchange servers. Plan for a brief service interruption.

Reset IIS on all Exchange servers:

Get-ExchangeServer | Where-Object {$_.ServerRole -match "ClientAccess|Mailbox"} | ForEach-Object {Invoke-Command -ComputerName $_.Name -ScriptBlock {iisreset}}

Verification: Run Get-OrganizationConfig | Select-Object OAuth2ClientProfileEnabled, OAuth2OnPremisesInboundProxyEnabled to confirm both settings show True.

04

Configure Virtual Directory Authentication Methods

Update your Exchange virtual directories to support modern authentication while disabling legacy authentication methods. This step ensures clients use OAuth tokens instead of basic authentication.

Configure OWA virtual directories for modern authentication:

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -LogonFormat Username -FormsAuthentication $false -BasicAuthEnabled $false -WindowsAuthentication $false -OAuthAuthentication $true

Configure EWS virtual directories:

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -BasicAuthEnabled $false -WindowsAuthentication $false -OAuthAuthentication $true

Configure ActiveSync virtual directories (if used):

Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -BasicAuthEnabled $false -WindowsAuthentication $false

Configure MAPI virtual directories:

Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -IISAuthenticationMethods @('OAuth')

For Autodiscover, ensure it supports both methods during transition:

Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -BasicAuthEnabled $true -WindowsAuthentication $true -OAuthAuthentication $true
Pro tip: Keep Autodiscover with multiple auth methods enabled initially. Disable basic auth on Autodiscover only after confirming all clients work with modern auth.

Verification: Check authentication methods on all virtual directories:

Get-OwaVirtualDirectory | Select-Object Server, BasicAuthEnabled, OAuthAuthentication
Get-WebServicesVirtualDirectory | Select-Object Server, BasicAuthEnabled, OAuthAuthentication
05

Test OAuth Connectivity and Authentication Flow

Verify that OAuth authentication is working correctly between your on-premises Exchange and Microsoft Entra ID. This step confirms the authentication flow before enabling for production users.

Test OAuth connectivity to EWS:

$TestMailbox = "testuser@yourdomain.com"
$EwsUrl = (Get-WebServicesVirtualDirectory | Where-Object {$_.ExternalUrl}).ExternalUrl.AbsoluteUri
Test-OAuthConnectivity -Service EWS -TargetUri $EwsUrl -Mailbox $TestMailbox -Verbose

Test OAuth connectivity to Autodiscover:

$AutodiscoverUrl = (Get-AutodiscoverVirtualDirectory | Where-Object {$_.ExternalUrl}).ExternalUrl.AbsoluteUri
Test-OAuthConnectivity -Service AutoDiscover -TargetUri $AutodiscoverUrl -Mailbox $TestMailbox -Verbose

Check the authentication server configuration:

Get-AuthServer | Where-Object {$_.Name -like "EvoSts*"} | Select-Object Name, Enabled, IsDefaultAuthorizationEndpoint, AuthMetadataUrl

Verify the organization's OAuth configuration:

Get-OrganizationConfig | Select-Object OAuth2ClientProfileEnabled, OAuth2OnPremisesInboundProxyEnabled, DownloadDomains
Warning: If Test-OAuthConnectivity fails, check that your SPNs are correctly configured in Azure and that external URLs are accessible. Common failures indicate SPN mismatches or firewall issues.

Test from a client machine using PowerShell with modern authentication:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://yourdomain.com/PowerShell/" -Authentication Basic -Credential $UserCredential -AllowRedirection
Import-PSSession $Session

Verification: Successful OAuth tests should show "PASS" status. Check Event Viewer on Exchange servers for authentication events (Event ID 1309 for successful OAuth).

06

Configure Conditional Access and Multi-Factor Authentication

With HMA enabled, configure Conditional Access policies in Microsoft Entra ID to enforce MFA for on-premises Exchange access. This provides the security benefits that motivated the HMA implementation.

Create a Conditional Access policy in Azure portal:

  1. Navigate to Microsoft Entra ID > Security > Conditional Access
  2. Click "New policy" and name it "Exchange On-Premises MFA"
  3. Under Assignments > Users, select the groups or users who access on-premises Exchange
  4. Under Cloud apps or actions > Select apps, choose "Office 365 Exchange Online"
  5. Under Conditions > Client apps, select "Exchange ActiveSync clients" and "Other clients"
  6. Under Access controls > Grant, select "Grant access" and check "Require multi-factor authentication"

Verify MFA methods are configured for users:

Connect-MsolService
Get-MsolUser -UserPrincipalName "testuser@yourdomain.com" | Select-Object UserPrincipalName, StrongAuthenticationMethods

Test MFA enforcement by connecting to OWA:

Start-Process "https://yourdomain.com/owa"

Configure application-specific passwords for legacy clients if needed:

Set-MsolUser -UserPrincipalName "user@yourdomain.com" -StrongPasswordRequired $true
Pro tip: Start with a pilot group in your Conditional Access policy. Monitor sign-in logs in Azure portal to identify any legacy authentication attempts that need addressing.

Monitor authentication in Azure sign-in logs:

  1. Go to Microsoft Entra ID > Sign-in logs
  2. Filter by Application: "Office 365 Exchange Online"
  3. Look for "Legacy authentication" in the Client app column

Verification: Users should be prompted for MFA when accessing OWA or configuring Outlook. Check Azure sign-in logs to confirm modern authentication is being used (Client app shows "Browser" or "Mobile Apps and Desktop clients" instead of "Legacy authentication").

07

Disable Legacy Authentication and Validate Security Posture

Complete the HMA implementation by fully disabling legacy authentication methods and validating that all clients are using modern authentication. This step maximizes security benefits.

Disable basic authentication on Autodiscover (final step):

Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -BasicAuthEnabled $false -WindowsAuthentication $false

Create an authentication policy to block legacy authentication:

New-AuthenticationPolicy -Name "Block Legacy Auth" -AllowBasicAuthActiveSync:$false -AllowBasicAuthAutodiscover:$false -AllowBasicAuthImap:$false -AllowBasicAuthMapi:$false -AllowBasicAuthOfflineAddressBook:$false -AllowBasicAuthOutlookService:$false -AllowBasicAuthPop:$false -AllowBasicAuthPowershell:$false -AllowBasicAuthReportingWebServices:$false -AllowBasicAuthRest:$false -AllowBasicAuthRpc:$false -AllowBasicAuthSmtp:$false -AllowBasicAuthWebServices:$false

Apply the authentication policy to all mailboxes:

Get-Mailbox -ResultSize Unlimited | Set-Mailbox -AuthenticationPolicy "Block Legacy Auth"

Verify no legacy authentication methods are enabled:

Get-OwaVirtualDirectory | Select-Object Server, BasicAuthEnabled, WindowsAuthentication, OAuthAuthentication
Get-WebServicesVirtualDirectory | Select-Object Server, BasicAuthEnabled, WindowsAuthentication, OAuthAuthentication
Get-ActiveSyncVirtualDirectory | Select-Object Server, BasicAuthEnabled, WindowsAuthentication

Run a comprehensive connectivity test:

$TestUsers = @("user1@yourdomain.com", "user2@yourdomain.com")
foreach ($User in $TestUsers) {
    Write-Host "Testing $User" -ForegroundColor Green
    Test-OAuthConnectivity -Service EWS -TargetUri $EwsUrl -Mailbox $User
    Test-OAuthConnectivity -Service AutoDiscover -TargetUri $AutodiscoverUrl -Mailbox $User
}
Warning: Monitor your environment closely for 48-72 hours after disabling legacy authentication. Some legacy applications or devices may stop working and require modern authentication configuration or app-specific passwords.

Generate a security report showing authentication methods:

Get-Mailbox -ResultSize Unlimited | Select-Object DisplayName, AuthenticationPolicy | Export-Csv "C:\Temp\HMA-Status.csv" -NoTypeInformation

Verification: All virtual directories should show BasicAuthEnabled:False and OAuthAuthentication:True. Azure sign-in logs should show no "Legacy authentication" entries for Exchange access. Test with multiple client types (Outlook desktop, mobile, OWA) to ensure modern authentication works across all scenarios.

Frequently Asked Questions

What happens to existing Outlook clients after enabling Hybrid Modern Authentication?+
Modern Outlook clients (2016 with updates, 2019, 2021, Microsoft 365 Apps) automatically detect and use modern authentication without user intervention. Older Outlook versions may require manual configuration or app-specific passwords. Users might see a Microsoft sign-in prompt initially, but subsequent access is seamless. Mobile devices using ActiveSync will need reconfiguration to support modern authentication protocols.
Can I roll back Hybrid Modern Authentication if issues occur?+
Yes, HMA can be reversed by disabling OAuth settings and re-enabling basic authentication on virtual directories. Run Set-OrganizationConfig -OAuth2ClientProfileEnabled $false and restore basic authentication on OWA, EWS, and other virtual directories. However, plan rollback carefully as users may need to reconfigure clients. Keep detailed documentation of original settings before implementing HMA.
Why does Test-OAuthConnectivity fail with SPN errors?+
SPN (Service Principal Name) errors occur when Exchange URLs aren't properly registered in Microsoft Entra ID's EvoSTS application. This happens if the Hybrid Configuration Wizard didn't automatically add your external URLs, or if you've changed URLs post-configuration. Manually add missing URLs to the EvoSTS service principal in Azure portal under Enterprise Applications. Verify all external URLs for OWA, EWS, and Autodiscover are listed as SPNs.
How do third-party applications work with Hybrid Modern Authentication?+
Third-party applications must support OAuth 2.0 or use app-specific passwords for continued access. Applications using basic authentication will fail after HMA implementation unless they're updated to support modern authentication. Register applications in Azure AD with appropriate Exchange permissions. Some legacy applications may require exemption policies or dedicated service accounts with app-specific passwords until they can be modernized.
What's the difference between HMA and Exchange Online modern authentication?+
HMA extends cloud-based modern authentication to on-premises Exchange servers, while Exchange Online modern authentication is native to the cloud service. HMA requires hybrid deployment and uses Microsoft Entra ID tokens to authenticate against on-premises services. The user experience is identical, but HMA involves additional configuration steps including SPN registration, virtual directory updates, and OAuth endpoint configuration that aren't needed for pure cloud deployments.
Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...