Edit

Enhanced-security hybrid messaging infrastructure — mobile access

Microsoft Entra ID
Microsoft 365
Office 365

The article shows how to implement multifactor authentication for Outlook mobile clients that access Microsoft Exchange. There are two architectures that correspond to two different possibilities for the Microsoft Exchange that has the user mailbox:

Architecture (Exchange Online)

Diagram that shows an architecture for enhanced security in an Outlook mobile access scenario. The user's mailbox is in Exchange Online.

In this scenario, users need to use a mobile client that supports modern authentication. We recommend Outlook mobile (Outlook for iOS / Outlook for Android), which is supported by Microsoft. The following workflow uses Outlook mobile.

Download a Visio file of all diagrams in this article.

Workflow (Exchange Online)

  1. The user starts Outlook profile configuration by entering an email address. Outlook mobile connects to the AutoDetect service.
  2. The AutoDetect service makes an anonymous AutoDiscover V2 request to Exchange Online to get the mailbox. Exchange Online replies with a 302 redirect response that contains the ActiveSync URL address for the mailbox, pointing to Exchange Online. You can see an example of this type of request here.
  3. Now that the AutoDetect service has information about the endpoint of the mailbox content, it can call ActiveSync without authentication.
  4. As described in the connection flow here, Exchange responds with a 401 challenge response. It includes an authorization URL that identifies the Microsoft Entra endpoint that the client needs to use to get an access token.
  5. The AutoDetect service returns the Microsoft Entra authorization endpoint to the client.
  6. The client connects to Microsoft Entra ID to complete authentication and enter sign-in information (email).
  7. If the domain is federated, the request is redirected to Web Application Proxy.
  8. Web Application Proxy proxies the authentication request to AD FS. The user sees a sign-in page.
  9. The user enters credentials to complete authentication.
  10. The user is redirected back to Microsoft Entra ID.
  11. Microsoft Entra ID applies an Azure Conditional Access policy.
  12. The policy can enforce restrictions based on the user's device state if the device is enrolled in Microsoft Endpoint Manager, enforce application protection policies, and/or enforce multifactor authentication. You can find a detailed example of this type of policy in the implementation steps described here.
  13. The user implements any policy requirements and completes the multifactor authentication request.
  14. Microsoft Entra ID returns access and refresh tokens to the client.
  15. The client uses the access token to connect to Exchange Online and retrieve the mailbox content.

Configuration (Exchange Online)

To block attempts to access Exchange Online ActiveSync 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 mobile service uses. Specifically, you need to disable AutoDiscover, ActiveSync, and Outlook Service. Here's the corresponding authentication policy configuration:

AllowBasicAuthAutodiscover : False

AllowBasicAuthActiveSync : False

AllowBasicAuthOutlookService : False

After you create the authentication policy, you can assign it to a pilot group of users. Then, after testing, you can expand the policy for all users. To apply the policy at the organization level, use the Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> command. You need to use Exchange Online PowerShell for this configuration.

For federated domains, you can configure AD FS to trigger multifactor authentication instead of using a Conditional Access policy. However, we recommend that you control the connection and apply restrictions at the Conditional Access policy level.

Architecture (Exchange on-premises)

Diagram that shows an architecture for enhanced security in an Outlook mobile access scenario. The user's mailbox is in Exchange on-premises.

Download a Visio file of all diagrams in this article.

In this scenario, users need to use a mobile client that supports modern authentication, as described in Using hybrid modern authentication. We recommend Outlook mobile (Outlook for iOS / Outlook for Android), which is supported by Microsoft. The following workflow uses Outlook mobile.

Workflow (Exchange on-premises)

  1. The user starts Outlook profile configuration by entering an email address. Outlook mobile connects to the AutoDetect service.
  2. The AutoDetect service makes an anonymous AutoDiscover V2 request to Exchange Online to get the mailbox.
  3. After the mailbox is located on-premises, Exchange Online replies with a 302 redirect response that contains an on-premises AutoDiscover URL that AutoDetect can use to retrieve the ActiveSync URL address for the mailbox.
  4. AutoDetect uses the on-premises URL that it received in the previous step to make an anonymous AutoDiscover v2 request to Exchange on-premises to get the mailbox. Exchange on-premises returns an ActiveSync URL address for the mailbox, pointing to Exchange on-premises. You can see an example of this type of request here.
  5. Now that the AutoDetect service has information about the endpoint of the mailbox content, it can call the on-premises ActiveSync endpoint without authentication. As described in the connection flow here, Exchange responds with a 401 challenge response. It includes an authorization URL that identifies the Microsoft Entra endpoint that the client needs to use to get an access token.
  6. The AutoDetect service returns the Microsoft Entra authorization endpoint to the client.
  7. The client connects to Microsoft Entra ID to complete authentication and enter sign-in information (email).
  8. If the domain is federated, the request is redirected to Web Application Proxy.
  9. Web Application Proxy proxies the authentication request to AD FS. The user sees a sign-in page.
  10. The user enters credentials to complete authentication.
  11. The user is redirected back to Microsoft Entra ID.
  12. Microsoft Entra ID applies an Azure Conditional Access policy.
  13. The policy can enforce restrictions based on the user's device state if the device is enrolled in Microsoft Endpoint Manager, enforce application protection policies, and/or enforce multifactor authentication. You can find a detailed example of this type of policy in the implementation steps described here.
  14. The user implements any policy requirements and completes the multifactor authentication request.
  15. Microsoft Entra ID returns access and refresh tokens to the client.
  16. The client uses the access token to connect to Exchange Online and retrieve the on-premises mailbox content. The content should be provided from the cache, as described here. To achieve that, the client issues a provisioning request that includes the user's access token and the on-premises ActiveSync endpoint.
  17. The provisioning API in Exchange Online takes the provided token as an input. The API obtains a second access-and-refresh token pair to access the on-premises mailbox via an on-behalf-of call to Active Directory. This second access token is scoped with the client as Exchange Online and an audience of the on-premises ActiveSync namespace endpoint.
  18. If the mailbox isn't provisioned, the provisioning API creates a mailbox.
  19. The provisioning API establishes a secure connection to the on-premises ActiveSync endpoint. The API synchronizes the user's messaging data by using the second access token as the authentication mechanism. The refresh token is used periodically to generate a new access token so that data can synchronize in the background without user intervention.
  20. Data is returned to the client.

Configuration (Exchange on-premises)

To block attempts to access Exchange on-premises ActiveSync via legacy authentication (the red dashed lines in the diagram), you need to create an authentication policy that disables legacy authentication for protocols that the Outlook mobile service uses. Specifically, you need to disable AutoDiscover and ActiveSync. Here's the corresponding authentication policy configuration:

BlockLegacyAuthAutodiscover: True

BlockLegacyAuthActiveSync: True

Here's an example of a command for creating this authentication policy:

New-AuthenticationPolicy -Name BlockLegacyActiveSyncAuth -BlockLegacyAuthActiveSync -BlockLegacyAuthAutodiscover

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 the 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.

You also need to take steps to achieve consistency and allow access only from the Outlook client. To allow Outlook mobile as the only approved client in the organization, you need to block connection attempts from clients that aren't Outlook mobile clients that support modern authentication. You need to block these attempts on the Exchange on-premises level by completing these steps:

  • Block other mobile device clients:

    Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Block

  • Allow Exchange Online to connect to on-premises:

    If ((Get-ActiveSyncOrganizationSettings).DefaultAccessLevel -ne "Allow") {New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "OutlookService" -AccessLevel Allow}

  • Block basic authentication for Outlook for iOS and Android:

    New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Block

For more information about these steps, see Using hybrid Modern Authentication with Outlook for iOS and Android.

For federated domains, you can configure AD FS to trigger multifactor authentication instead of using a Conditional Access policy. However, we recommend that you control the connection and apply restrictions at the Conditional Access policy level.

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.

Alternatives

You can use third-party mobile clients that support modern authentication as an alternative to Outlook mobile. If you choose this alternative, the third-party vendor is responsible for the clients' support.

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 two architectures to help you enhance your security in an Outlook mobile access scenario by using Microsoft Entra multifactor authentication.

These scenarios are described in this article:

  • Outlook mobile access when the user's mailbox is in Exchange Online
  • Outlook mobile access when the user's mailbox is in Exchange on-premises

Both architectures cover both Outlook for iOS and Outlook for Android.

For information about applying multifactor authentication in other hybrid messaging scenarios, see these articles:

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 won't redirect the authentication request to on-premises Active Directory Federation Services (AD FS).
  • 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.
  • 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 your application can meet the commitments 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:

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:

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.

Security

For general guidance about security on mobile devices, see Protect data and devices with Microsoft Intune.

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

The cost of your implementation depends on your Microsoft Entra ID and Microsoft 365 license costs. The 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 depends on the performance of the components that are involved and your company's 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:

Scalability

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

To implement this infrastructure, you need to complete the steps outlined in the guidance included in the following articles. Here are the high-level steps:

  1. Secure Outlook mobile access as described in these implementation steps for modern authentication.
  2. Block all other legacy authentication attempts at the Microsoft Entra ID level.
  3. Block legacy authentication attempts at the messaging services level by using authentication policy.

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors.

Principal authors:

To see non-public LinkedIn profiles, sign in to LinkedIn.

Next steps