Why You Need to Enable MFA?
Implementing MFA in Microsoft Exchange Server. Currently, Multi-Factor Authentication (MFA) is a security standard. By improving the credentials safety, it is recommended by both governmental agencies, such as Cybersecurity and Infrastructure Security Agency (CISA), and Microsoft and Google. MFA is a step forward beyond just a username and password. Key benefits of implementing MFA:
- Enhanced Security: extra layer of protection (users need to provide multiple forms of identification). Typically password and a temporary code from a mobile app or a hardware token. With All in all, it makes unauthorized access more challenging.
- Compliance Requirements: General Data Protection Regulation (GDPR) and Payment Card Industry Data Security Standard (PCI DSS), require MFA to further security measures.
- Secure Remote Access: MFA reduces the risk associated with unauthorized access from external locations.
- Adaptability and Flexibility: it uses various authentication factors to fit the combination to the best that fits their security requirements. Many MFA providers (such as Microsoft Entra MFA described in this article) allows users to choose the factors by themselves, improving the user experience.
By combining multiple factors, MFA significantly strengthens the overall security posture of systems, applications, and sensitive data, making it a crucial component of modern cybersecurity practices.
How MFA works in Exchange Server
Traditionally, Exchange Server uses Active Directory Domain Controller for authentication of users. This approach doesn’t support OAUTH 2.0 and can’t be used for multifactor authentication.
Modern authentication support was introduced with Exchange Online, which is a SaaS email solution, part of Office 365 offering. Later, it become available for on-premises Exchange Servers that were in a co-existence with Exchange Online (Exchange Hybrid). And finally, in 2023, modern authentication become available for on-premises Exchange Servers without hybrid infrastructure.
To implement MFA for Exchange Server, you need to use an external security token service (STS) that supports the integration with MFA providers. The most common STS is Active Directory Federation Services (ADFS).
After the Exchange Server is configured to use ADFS OAuth tokens, user authentication flows as shown on the below diagram.
User connects to their mailbox. If authentication is allowed, they are redirected to ADFS. Then, ADFS confirms the identity, using MFA and access to the mailbox is granted.
It the recommended approach of deployment of MFA for on-premises Exchange Server. But, if your existing infrastructure does not meet the prerequisites (e.g. Outlook 2019, or there are users with Mac computers). Or its restrictions (currently it doesn’t support mobile devices) don’t comply with the requirements in your company. In these cases, alternative solutions may be used, the most popular ones:
- Implementation of Hybrid Modern Authentication. Requires deployment of Microsoft Entra ID Hybrid and Exchange Hybrid.
- Migration to Exchange Online. Requires purchasing of Microsoft 365 subscription.
- Deployment of third-party solution.
Try our Active Directory & Office 365 Reporting & Auditing Tools
Try us out for Free. 100’s of report templates available. Easily customise your own reports on AD, Azure AD & Office 355.
Up next with Implementing MFA in Microsoft Exchange Server we learn the requirements.
MFA Deployment Prerequisites
Server Requirements
- The first and most important requirement – Cumulative Upgrade 13 or later should be installed on all servers used for client connections. Earlier versions of Exchange Server don’t support OAuth 2.0 and cannot be used in this scenario. If you have coexistence of Exchange Server 2019 and 2016, ensure that no client connection is forwarded to Exchange Server 2016 (by configuring the load balancers or virtual directory URLs).
- Exchange Server 2013 is not supported in this scenario, though technically it is possible to have Exchange Server 2013 in coexistence with 2019. Therefore, before the configuration of MFA, ensure that all servers running Exchange Server 2013 are decommissioned.
- The solution requires presence of ADFS infrastructure running Windows Server 2019 or later. If you plan to authorize both internal and external connections, the server farm should include both ADFS servers and Web Application Proxy (WAP) servers.
Description about deployment and config for ADFS is here AD FS Deployment section of Microsoft Learn portal.
- URL of ADFS federation metadata must be accessible from both Exchange Server and client machines. To verify it, open the URL https://<FederationServiceName>/federationmetadata/2007-06/federationmetadata.xml from the machine. If it is not accessible, check the network and firewall configuration.
- ADFS must be configured to use MFA provider during authentication. MFA prerequisites vary depending on the provider, for example, if you use Microsoft Entra multifactor authentication, you must have an appropriate subscription (Microsoft Entra ID P1 or P2) and your infrastructure must meet the requirements listed in Configure Microsoft Entra multifactor authentication as authentication provider using AD FS.
- As described in Certificate Requirements for Federation Servers, there are different certificate types in ADFS. For MFA deployment, ensure that the certificate used to secure web services traffic is trusted by the clients. Purchase it from the trusted third-party provider, such as Comodo, Digicert or Sectigo.
Client Requirements
Client computer must run Windows 11 22H2 or later, neither MacOS devices nor earlier versions of Windows are supported. Additionally, there is a requirement to have update KB5023706 installed (already included in Windows 11 23H2). According to Microsoft, support for MacOS and mobile operating systems will be added later.
Following email clients are supported:
- Outlook in Microsoft 365 Apps for Enterprise, excluding Semi-Annual Enterprise Channel .
- Microsoft Office Outlook 2021, excluding volume licenses.
More detailed information about Outlook requirements are here.
Deployment of MFA Through ADFS
The implementation of the solution includes the configuration of the federation service, proper preparation of the client machines and configuration of the Exchange itself.
ADFS Configuration
- First of all, create an Application Group for Outlook.
- Open ADFS Management Console, right click on the Application Groups and select Add Application Group.
- In the appeared Add Application Group Wizard, enter descriptive name (e.g. Outlook Application Group) and select the Native Application accessing a web API template and Next.
- On the next page, specify the properties of the native application. Client ID should be d3590ed6-52b3-4102-aeff-aad2292ab01c (which is ID of Microsoft Office applications), and the redirect URIs are urn:ietf:wg:oauth:2.0:oob and ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c
- In the Configure Web API page, specify all domain names used by client connections to the Exchange in the list of identifiers. Find these names in the config of virtual directories of your Exchange Servers, using PowerShell (example of the script is found here) or Exchange Control Panel. Typically, it is the same list of names you specify in the IIS certificate.
- In the next page of the wizard, specify who has permissions to use this group – in our case it should be everyone, and the MFA must be required.
- In the Configure Application Permissions page, select the application and add user_impersonation permission, then click Next and Close.
- Then, you need to add the Issuance Transform Rules for the created application group. To do it, right click on the group, and select Properties. Select Outlook Application Group – Web API and press Edit. Add the rules specified in the official article and press OK.
- Configure WAP server to perform the pre-authentication of external connections. To do it, run the following command in the WAP server PowerShell, once per each domain name used for external Exchange connections. Example, for name mail.domain.com for every Exchange service, you need to publish 2 domain names – mail.domain.com and Autodiscover.domain.com.
Add-WebApplicationProxyApplication `
-BackendServerURL 'https://Autodiscover.domain.com/'`
-ExternalCertificateThumbprint ''`
-ExternalURL 'https://Autodiscover.domain.com/'`
-Name 'Autodiscover WAP'`
-ExternalPreAuthentication ADFS`
-ADFSRelyingPartyName 'Outlook Application Group'`
-UseOAuthAuthentication
Add-WebApplicationProxyApplication `
-BackendServerURL 'https://Mail.domain.com/'`
-ExternalCertificateThumbprint ''`
-ExternalURL 'https://Mail.domain.com/'`
-Name 'MAPI WAP'`
-ExternalPreAuthentication ADFS`
-ADFSRelyingPartyName 'Outlook Application Group'`
-UseOAuthAuthentication
Where BackendServerURL and ExternalURL parameter should contain the URL of the service being published, ExternalCertificateThumbprint – thumbprint of the certificate that covers the published domain name (it should be installed in the WAP server), ADFSRelyingPartyName – name of the earlier configured Application Group. Name – friendly name of the published proxy, ExternalPreAuthentication – pre-authentication method, in our case should be ADFS.
- Next configure MFA for the client access. Configure any MFA provider that meets your needs and supports integration with ADFS. In this example, let’s see the deployment of Microsoft Entra multifactor authentication. Part of Microsoft cloud offering. Detailed description is here How it works: Microsoft Entra multifactor authentication.
- Change the anchor claim type for the Active Directory Claims Provider trust from windowsaccountname to user principal name (UPN). Open PowerShell on the ADFS server and run the following command:
Set-AdfsClaimsProviderTrust -AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -TargetName "Active Directory"
- Find and write down your Microsoft Entra tenant ID, as described in How to find your Microsoft Entra tenant ID
- Go back to your PowerShell consoled and generate a new certificate for the ADFS server using the defined tenant ID, and store it in the variable:
$MFACert = New-AdfsAzureMfaTenantCertificate -TenantID
- Connect to Microsoft Entra ID PowerShell as described in Get started with the Microsoft Graph PowerShell SDK, then run the following script from official Microsoft documentation:
$servicePrincipalId = (Get-MgServicePrincipal -Filter "appid eq '981f26a1-7f43-403b-a875-f8b09b8cd720'").Id
$keyCredentials = (Get-MgServicePrincipal -Filter "appid eq '981f26a1-7f43-403b-a875-f8b09b8cd720'").KeyCredentials
$certX509 = [System.Security.Cryptography.X509Certificates.X509Certificate2]([System.Convert]::FromBase64String($MFACert))
$newKey = @(@{
CustomKeyIdentifier = $null
DisplayName = $certX509.Subject
EndDateTime = $null
Key = [System.Text.Encoding]::ASCII.GetBytes($MFACert)
KeyId = [guid]::NewGuid()
StartDateTime = $null
Type = "AsymmetricX509Cert"
Usage = "Verify"
AdditionalProperties = $null
})
$keyCredentials += $newKey
Update-MgServicePrincipal -ServicePrincipalId $servicePrincipalId -KeyCredentials $keyCredentials
-
- Run the following command to configure the tenant in ADFS PowerShell:
Set-AdfsAzureMfaTenant -TenantId -ClientId 981f26a1-7f43-403b-a875-f8b09b8cd720
- Restart all ADFS servers in your farm.
- Next, you need to configure the Primary Authentication Methods. To do it, open the ADFS management console, and navigate to AD FS > Service > Authentication Methods. Here select newly appeared Azure MFA method.
- (Optional) There are some optional steps to improve the user experience. These steps reduce the number of authentication prompts made by Outlook.
- First of all, let’s configure SSO lifetime. Open ADFS management console, and in the panel to the right side select Edit Federation Service Properties.
- Specify the number of minutes for SSO lifetime and press OK.
- Next, enable device registration in AD FS. Follow the steps described in Configuring Device Registration. The article was written for Windows Server 2012, but works for the modern versions as well.
Email Infrastructure Configuration
Email Infrastructure configuration includes configuration of client machines and Exchange Servers. To prepare client machines to the usage of modern authentication, you need to add several registry entries. It can be done using any approach adopted in your company for management of the client machines, such as GPO or Microsoft Intune.
- Add ADFS URL as a trusted domain by creating the necessary registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https:///
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://
- Enable modern authentication by creating EnableExchangeOnPremModernAuth REG_DWORD entry and setting its value to 1. The path for the entry is HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\.
- Next, configure modern authentication for Exchange Server by creating the authentication policy and set as the default one. Run the following command in Exchange Server Management shell:
New-AuthenticationPolicy "AllowModernAuthentication"
Set-OrganizationConfig -DefaultAuthenticationPolicy "AllowModernAuthentication"
Note, if you want to allow modern authentication only for the part of users, create a policy that blocks it (as described here) and set it as default. Then create a new policy that allows modern authentication and assign it on user level using Set-User cmdlet.
- Enable OAuth authentication for the necessary virtual directories for each server:
Get-ExchangeServer | Set-WebServicesVirtualDirectory -OAuthAuthentication $True
Get-ExchangeServer | Set-OabVirtualDirectory -OAuthAuthentication $True
Get-ExchangeServer | Set-AutodiscoverVirtualDirectory -OAuthAuthentication $True
Get-ExchangeServer | Set-MapiVirtualDirectory -IISAuthenticationMethods NTLM,Negotiate,OAuth
For the Set-MapiVirtualDirectory cmdlet above, specify all authentication methods used for MAPI connections in your company in the IISAuthenticationMethods parameter.
- Create the new authentication server object in Exchange Server and set it as default.
New-AuthServer -Type ADFS -Name ADFSServer -AuthMetadataUrl https:///FederationMetadata/2007-06/FederationMetadata.xml
- Enable modern authentication for the whole company using the Set-OrganizationConfig cmdlet:
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
After this configuration, Exchange Server will delegate the connection authentication to ADFS, which will use Entra ID MFA to authenticate the users.
This is it. Thank you for reading Implementing MFA in Microsoft Exchange Server. We go to conclusion next. Thank you for your time.
Implementing MFA in Microsoft Exchange Server Conclusion
Despite all the security technology used in Exchange Server, it still was vulnerable for the credential leaks because of lack of MFA. Currently, because of the introduced support of modern authentication, this security gap no more exists, and the adoption of MFA allows organization aligning with recognized security standards.
In conclusion, the journey towards implementing MFA for on-premises Exchange Servers demands a comprehensive understanding of the intricacies involved, adherence to prerequisites, and a commitment to reinforcing the security posture of the organization. As cybersecurity threats continue to evolve, the deployment of Microsoft Entra MFA with ADFS (or any other security token service with supported MFA provider) emerges as a proactive and indispensable measure for safeguarding sensitive data and maintaining the integrity of communication systems.
Try InfraSOS for FREE
Try InfraSOS Active Directory, Azure AD & Office 365 Reporting & Auditing Tool
- Free 15-Days Trial
- SaaS AD Reporting & Auditing Solution
