The article shows how to implement multifactor authentication for Outlook desktop clients that access Microsoft Exchange. There are four architectures that correspond to four different possibilities for the Microsoft Exchange that has the user mailbox:
Note
In the diagrams, black dashed lines show basic interactions between local Active Directory, Microsoft Entra Connect, Microsoft Entra ID, AD FS, and Web Application Proxy components. You can learn about these interactions in Hybrid identity required ports and protocols.
Architecture (Exchange Online)
Download a Visio file of all diagrams in this article.
In this scenario, users need to use the version of Outlook client that supports modern authentication. For more information, see How modern authentication works for Office 2013, Office 2016, and Office 2019 client apps. This architecture covers both Outlook for Windows and Outlook for Mac.
Workflow (Exchange Online)
- The user tries to access Exchange Online via Outlook.
- Exchange Online provides the URL of a Microsoft Entra endpoint for retrieving the access token to get access to the mailbox.
- Outlook connects to Microsoft Entra ID by using that URL.
- As soon as the domain is federated, Microsoft Entra ID redirects the request to on-premises AD FS.
- The user enters credentials on an AD FS sign-in page.
- AD FS redirects the session back to Microsoft Entra ID.
- Microsoft Entra ID applies an Azure Conditional Access policy with a multifactor authentication requirement for mobile apps and desktop clients. See the deployment section of this article for information about setting up that policy.
- The Conditional Access policy calls Microsoft Entra multifactor authentication. The user gets a request to complete multifactor authentication.
- The user completes multifactor authentication.
- Microsoft Entra ID issues access and refresh tokens and returns them to the client.
- By using the access token, the client connects to Exchange Online and retrieves the content.
Configuration (Exchange Online)
To block attempts to access Exchange Online via legacy authentication (the red dashed line in the diagram), you need to create an authentication policy that disables legacy authentication for protocols that the Outlook service uses. These are the specific protocols that you need to disable: Autodiscover, MAPI, Offline Address Books, and EWS. Here's the corresponding configuration:
AllowBasicAuthAutodiscover : False
AllowBasicAuthMapi : False
AllowBasicAuthOfflineAddressBook : False
AllowBasicAuthWebServices : False
AllowBasicAuthRpc : False
Remote procedure call (RPC) protocol is no longer supported for Office 365, so the last parameter doesn't affect clients.
Here's an example of a command for creating this authentication policy:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false
Note
By default, after you create the policy, legacy authentication for all other protocols (like IMAP, POP, and ActiveSync) is also disabled. To change this behavior, you can enable protocols by using a PowerShell command like this one:
Set-AuthenticationPolicy -Identity BlockOutlook -AllowBasicAuthImap:$true
After you create the authentication policy, you can first assign it to a pilot group of users by using the Set-User user01 -AuthenticationPolicy <name_of_policy> command. After testing, you can expand the policy to include to all users. To apply policy at the organization level, use the Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> command. You need to use Exchange Online PowerShell for this configuration.
Architecture (Exchange Online, AD FS)
Download a Visio file of all diagrams in this article.
This scenario is the same as the previous one, except that it uses a different trigger for multifactor authentication. In the previous scenario, we used local AD FS for authentication. We then redirected information about successful authentication to Microsoft Entra ID, where a Conditional Access policy enforced multifactor authentication. In this scenario, instead of using Conditional Access to enforce multifactor authentication, we create an access control policy on the AD FS level and enforce multifactor authentication there. The rest of the architecture is the same as the previous one.
Note
We recommend this scenario only if you're unable to use the previous one.
In this scenario, users need to use the version of Outlook client that supports modern authentication. For more information, see How modern authentication works for Office 2013, Office 2016, and Office 2019 client apps. This architecture covers both Outlook for Windows and Outlook for Mac.
Workflow (Exchange Online, AD FS)
The user tries to access Exchange Online via Outlook.
Exchange Online provides the URL of a Microsoft Entra endpoint for retrieving the access token to get access to the mailbox.
Outlook connects to Microsoft Entra ID by using that URL.
If the domain is federated, Microsoft Entra ID redirects the request to on-premises AD FS.
The user enters credentials on an AD FS sign-in page.
Responding to an AF DS access control policy, AD FS calls Microsoft Entra multifactor authentication to complete authentication. Here's an example of that type of AD FS access control policy:
The user gets a request to complete multifactor authentication.
The user completes multifactor authentication.
AD FS redirects the session back to Microsoft Entra ID.
Microsoft Entra ID issues access and refresh tokens and returns them to the client.
By using the access token, the client connects to Exchange Online and retrieves the content.
Configuration (Exchange Online, AD FS)
Note
The access control policy that's implemented in step 6 is applied on the relying-party-trust level, so it affects all authentication requests for all Office 365 services that go through AD FS. You can use AD FS authentication rules to apply additional filtering. However, we recommend that you use a Conditional Access policy (described in the previous architecture) rather than using an AD FS access control policy for Microsoft 365 services. The previous scenario is more common, and by using it you can achieve better flexibility.
To block attempts to access Exchange Online via legacy authentication (the red dashed line in the diagram), you need to create an authentication policy that disables legacy authentication for protocols that the Outlook service uses. These are the specific protocols that you need to disable: Autodiscover, MAPI, Offline Address Books, and EWS. Here's the corresponding configuration:
AllowBasicAuthAutodiscover : False
AllowBasicAuthMapi : False
AllowBasicAuthOfflineAddressBook : False
AllowBasicAuthWebServices : False
AllowBasicAuthRpc : False
RPC protocol is no longer supported for Office 365, so the last parameter doesn't affect clients.
Here's an example of a command for creating this authentication policy:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false
Architecture (Exchange on-premises)
Download a Visio file of all diagrams in this article.
This architecture covers both Outlook for Windows and Outlook for Mac.
Workflow (Exchange on-premises)
- A user with a mailbox on Exchange Server starts the Outlook client. The Outlook client connects to Exchange Server and specifies that it has modern authentication capabilities.
- Exchange Server sends a response to the client requesting that it get a token from Microsoft Entra ID.
- The Outlook client connects to a Microsoft Entra URL that's provided by Exchange Server.
- Azure identifies that the user's domain is federated, so it sends requests to AD FS (via Web Application Proxy).
- The user enters credentials on an AD FS sign-in page.
- AD FS redirects the session back to Microsoft Entra ID.
- Microsoft Entra ID applies an Azure Conditional Access policy with a multifactor authentication requirement for mobile apps and desktop clients. See the deployment section of this article for information about setting up that policy.
- The Conditional Access policy calls Microsoft Entra multifactor authentication. The user gets a request to complete multifactor authentication.
- The user completes multifactor authentication.
- Microsoft Entra ID issues access and refresh tokens and returns them to the client.
- The user presents the access token to Exchange Server, and Exchange authorizes access to the mailbox.
Configuration (Exchange on-premises)
To block attempts to access Exchange on-premises via legacy authentication (the red dashed line in the diagram), you need to create an authentication policy that disables legacy authentication for protocols that the Outlook service uses. These are the specific protocols that you need to disable: Autodiscover, MAPI, Offline Address Books, EWS, and RPC. Here's the corresponding configuration:
BlockLegacyAuthAutodiscover : True
BlockLegacyAuthMapi : True
BlockLegacyAuthOfflineAddressBook : True
BlockLegacyAuthRpc : True
BlockLegacyAuthWebServices : True
RPC protocol doesn't support modern authentication, so it doesn't support Microsoft Entra multifactor authentication. Microsoft recommends MAPI protocol for Outlook for Windows clients.
Here's an example of a command for creating this authentication policy:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc
After you create the authentication policy, you can first assign it to a pilot group of users by using the Set-User user01 -AuthenticationPolicy <name_of_policy> command. After testing, you can expand the policy to include all users. To apply policy at the organization level, use the Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> command. You need to use Exchange on-premises PowerShell for this configuration.
Architecture (Exchange on-premises, AD FS)
Download a Visio file of all diagrams in this article.
This scenario is similar to the previous one. However, in this scenario, multifactor authentication is triggered by AD FS. This architecture covers both Outlook for Windows and Outlook for Mac.
Note
We recommend this scenario only if you are unable to use the previous one.
Workflow (Exchange on-premises, AD FS)
The user starts the Outlook client. The client connects to Exchange Server and specifies that it has modern authentication capabilities.
Exchange Server sends a response to the client requesting that it get a token from Microsoft Entra ID. Exchange Server provides the client with a URL to Microsoft Entra ID.
The client uses the URL to access Microsoft Entra ID.
In this scenario, the domain is federated. Microsoft Entra ID redirects the client to AD FS via Web Application Proxy.
The user enters credentials on an AD FS sign-in page.
AD FS triggers multifactor authentication. Here's an example of that type of AD FS access control policy:
The user gets a request to complete multifactor authentication.
The user completes multifactor authentication.
AD FS redirects the session back to Microsoft Entra ID.
Microsoft Entra ID issues access and refresh tokens to the user.
The client presents the access token to the Exchange on-premises server. Exchange authorizes access to the user's mailbox.
Configuration (Exchange on-premises, AD FS)
Note
The access control policy implemented in step 6 is applied on the relying-party-trust level, so it affects all authentication requests for all Office 365 services that go through AD FS. You can use AD FS authentication rules to apply additional filtering. However, we recommend that you use a Conditional Access policy (described in the previous architecture) rather than using an AD FS access control policy for Microsoft 365 services. The previous scenario is more common, and by using it you can achieve better flexibility.
To block attempts to access Exchange on-premises via legacy authentication (the red dashed line in the diagram), you need to create an authentication policy that disables legacy authentication for protocols that the Outlook service uses. These are the specific protocols that you need to disable: Autodiscover, MAPI, Offline Address Books, EWS, and RPC. Here's the corresponding configuration:
BlockLegacyAuthAutodiscover : True
BlockLegacyAuthMapi : True
BlockLegacyAuthOfflineAddressBook : True
BlockLegacyAuthRpc : True
BlockLegacyAuthWebServices : True
RPC protocol doesn't support modern authentication, so it doesn't support Microsoft Entra multifactor authentication. Microsoft recommends MAPI protocol for Outlook for Windows clients.
Here's an example of a command for creating this authentication policy:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc
After you create the authentication policy, you can first assign it to a pilot group of users by using the Set-User user01 -AuthenticationPolicy <name_of_policy> command. After testing, you can expand the policy to include all users. To apply policy at the organization level, use the Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> command. You need to use Exchange on-premises PowerShell for this configuration.
Components
- Microsoft Entra ID. Microsoft Entra ID is a Microsoft cloud-based identity and access management service. It provides modern authentication that's essentially based on EvoSTS (a Security Token Service used by Microsoft Entra ID). It's used as an authentication server for Exchange Server on-premises.
- Microsoft Entra multifactor authentication. Multifactor authentication is a process in which users are prompted during the sign-in process for another form of identification, like a code on their cellphone or a fingerprint scan.
- Microsoft Entra Conditional Access. Conditional Access is the feature that Microsoft Entra ID uses to enforce organizational policies like multifactor authentication.
- AD FS. AD FS enables federated identity and access management by sharing digital identity and entitlements rights across security and enterprise boundaries with improved security. In these architectures, it's used to facilitate sign-in for users with federated identity.
- Web Application Proxy. Web Application Proxy pre-authenticates access to web applications by using AD FS. It also functions as an AD FS proxy.
- Microsoft Intune. Intune is our cloud-based unified endpoint management, managing endpoints across Windows, Android, Mac, iOS, and Linux operating systems.
- Exchange Server. Exchange Server hosts user mailboxes on-premises. In these architectures, it uses tokens issued to the user by Microsoft Entra ID to authorize access to mailboxes.
- Active Directory services. Active Directory services stores information about members of a domain, including devices and users. In these architectures, user accounts belong to Active Directory services and are synchronized to Microsoft Entra ID.
- Outlook for business. Outlook is a client application that supports modern authentication.
Scenario details
Enterprise messaging infrastructure (EMI) is a key service for organizations. Moving from older, less secure methods of authentication and authorization to modern authentication is a critical challenge in a world where remote work is common. Implementing multifactor authentication requirements for messaging service access is one of the most effective ways to meet that challenge.
This article describes four architectures to enhance your security in an Outlook desktop-client access scenario by using Microsoft Entra multifactor authentication.
These are four architectures according to four different possibilities for Microsoft Exchange:
All four architectures cover both Outlook for Windows and Outlook for Mac.
For information about applying multifactor authentication in other hybrid messaging scenarios, see these articles:
- Enhanced-security hybrid messaging infrastructure in a web access scenario
- Enhanced-security hybrid messaging infrastructure in a mobile access scenario
This article doesn't discuss other protocols, like IMAP or POP. Typically, these scenarios don't use these protocols.
General notes
- These architectures use the federated Microsoft Entra identity model. For the password hash synchronization and Pass-through Authentication models, the logic and flow are the same. The only difference is related to the fact that Microsoft Entra ID doesn't redirect the authentication request to on-premises Active Directory Federation Services (AD FS).
- By Exchange on-premises, we mean Exchange 2019 with the latest updates and a Mailbox role.
- In a real environment, you won't have just one server. You'll have a load-balanced array of Exchange servers for high availability. The scenarios described here are suited for that configuration.
Potential use cases
This architecture is relevant for the following scenarios:
- Enhance EMI security.
- Adopt a Zero Trust security strategy.
- Apply your standard high level of protection for your on-premises messaging service during transition to or coexistence with Exchange Online.
- Enforce strict security or compliance requirements in closed or highly secured organizations, like those in the finance sector.
Considerations
These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that can be used to improve the quality of a workload. For more information, see Microsoft Azure Well-Architected Framework.
Reliability
Reliability ensures that your application can meet the commitments that you make to your customers. For more information, see Overview of the reliability pillar.
Availability
Overall availability depends on the availability of the components that are involved. For information about availability, see these resources:
- Advancing Microsoft Entra availability
- Cloud services you can trust: Office 365 availability
- What is the Microsoft Entra architecture?
Availability of on-premises solution components depends on the implemented design, hardware availability, and your internal operations and maintenance routines. For availability information about some of these components, see the following resources:
- Setting up an AD FS deployment with Always On availability groups
- Deploying high availability and site resilience in Exchange Server
- Web Application Proxy in Windows Server
To use hybrid modern authentication, you need to ensure that all clients on your network can access Microsoft Entra ID. You also need to consistently maintain Office 365 firewall ports and IP-range openings.
For protocol and port requirements for Exchange Server, see "Exchange client and protocol requirements" in Hybrid modern authentication overview for use with on-premises Skype for Business and Exchange servers.
For Office 365 IP ranges and ports, see Office 365 URLs and IP address ranges.
For information about hybrid modern authentication and mobile devices, read about AutoDetect endpoint in Other endpoints not included in the Office 365 IP Address and URL Web service.
Resiliency
For information about the resiliency of the components in this architecture, see the following resources.
- For Microsoft Entra ID: Advancing Microsoft Entra availability
- For scenarios that use AD FS: High availability cross-geographic AD FS deployment in Azure with Azure Traffic Manager
- For the Exchange on-premises solution: Exchange high availability
Security
Security provides assurances against deliberate attacks and the abuse of your valuable data and systems. For more information, see Overview of the security pillar.
For information about security and hybrid modern authentication, see Deep Dive: How Hybrid Authentication Really Works.
For closed organizations that have traditional strong perimeter protection, there are security concerns related to Exchange Hybrid Classic configurations. The Exchange Hybrid Modern configuration doesn't support hybrid modern authentication.
For information about Microsoft Entra ID, see Microsoft Entra security operations guide.
For information about scenarios that use AD FS security, see these articles:
Cost optimization
Cost optimization is about looking at ways to reduce unnecessary expenses and improve operational efficiencies. For more information, see Overview of the cost optimization pillar.
The cost of your implementation depends on your Microsoft Entra ID and Microsoft 365 license costs. Total cost also includes costs for software and hardware for on-premises components, IT operations, training and education, and project implementation.
These solutions require at least Microsoft Entra ID P1. For pricing details, see Microsoft Entra pricing.
For information about AD FS and Web Application Proxy, see Pricing and licensing for Windows Server 2022.
For more pricing information, see these resources:
Performance efficiency
Performance efficiency is the ability of your workload to scale in an efficient manner to meet the demands that your users place on it. For more information, see Performance efficiency pillar overview.
Workload performance depends on the performance of the components that are involved and on network performance. For more information, see Office 365 performance tuning using baselines and performance history.
For information about on-premises factors that influence performance for scenarios that include AD FS services, see these resources:
For information about AD FS scalability, see Planning for AD FS server capacity.
For information about Exchange Server on-premises scalability, see Exchange 2019 preferred architecture.
Deploy this scenario
Here are the high-level steps:
- Protect Outlook desktop access by configuring Exchange Hybrid configuration and enabling hybrid modern authentication.
- Block all legacy authentication attempts at the Microsoft Entra ID level. Block legacy authentication attempts on a messaging-services level by using authentication policy.
Set up a Conditional Access policy
To set up a Microsoft Entra Conditional Access policy that enforces multifactor authentication, as described in some of the architectures in this article:
In the Clients apps window, select Mobile apps and desktop clients:
Apply the multifactor authentication requirement in the Grant window:
Contributors
This article is maintained by Microsoft. It was originally written by the following contributors.
Principal authors:
- Pavel Kondrashov | Cloud Solution Architect
- Ella Parkum | Principal Customer Solution Architect-Engineering
To see non-public LinkedIn profiles, sign in to LinkedIn.
Next steps
- Announcing Hybrid Modern Authentication for Exchange On-Premises
- Hybrid modern authentication overview and prerequisites for use with on-premises Exchange servers
- Use AD FS claims-based authentication with Outlook on the web
- How to configure Exchange Server on-premises to use Hybrid Modern Authentication
- Exchange 2019 preferred architecture
- High availability cross-geographic AD FS deployment in Azure with Azure Traffic Manager
- Using hybrid Modern Authentication with Outlook for iOS and Android
- Account setup with modern authentication in Exchange Online