Enhanced-security hybrid messaging infrastructure — web access

Azure Active Directory
Microsoft 365
Office 365

The solution in this article provides a way for you to help protect your messaging service (Outlook on the web or Exchange Control Panel) when mailboxes are hosted in Exchange Online or Exchange on-premises.


In this architecture, we divide the solution into two areas, describing security for:

  • Exchange Online, on the right side of the diagram.
  • Exchange on-premises in a hybrid or non-hybrid scenario, on the left side of the diagram.

Screenshot that shows an architecture for enhanced security in a web access scenario.

General notes

  • This architecture uses the federated Azure Active Directory (Azure AD) identity model. For the password hash synchronization and pass-through authentication models, the logic and the flow are the same. The only difference is related to the fact that Azure AD won't redirect the authentication request to on-premises Active Directory Federation Services (AD FS).
  • The diagram shows access to the Outlook on the web service that corresponds to an …/owa path. Exchange admin center (or Exchange Control Panel) user access that corresponds to an …/ecp path follows the same flow.
  • In the diagram, dashed lines show basic interactions between local Active Directory, Azure AD Connect, Azure AD, AD FS, and Web Application Proxy components. You can learn more about these interactions in Hybrid identity required ports and protocols.
  • By Exchange on-premises, we mean Exchange 2019 with the latest updates, Mailbox role. By Exchange Edge on-premises, we mean Exchange 2019 with the latest updates, Edge Transport role. We include Edge server in the diagram to highlight that you can use it in these scenarios. It's not involved in the work with client protocols that's discussed here.
  • 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.

Exchange Online user's flow

  1. A user tries to access Outlook on the web service via https://outlook.office.com/owa.

  2. Exchange Online redirects the user to Azure AD for authentication.

    If the domain is federated, Azure AD redirects the user to the local AD FS instance for authentication. If authentication succeeds, the user is redirected back to Azure AD. (To keep the diagram simple, we left out this federated scenario.)

  3. To enforce multi-factor authentication, Azure AD applies an Azure Conditional Access policy with a multi-factor authentication requirement for the browser client application. See the deployment section of this article for information about setting up that policy.

  4. The Conditional Access policy calls Azure AD Multi-Factor Authentication. The user gets a request to complete multi-factor authentication.

  5. The user completes multi-factor authentication.

  6. Azure AD redirects the authenticated web session to Exchange Online, and the user can access Outlook.

Exchange on-premises user's flow

  1. A user tries to access the Outlook on the web service via an https://mail.contoso.com/owa URL that points to an Exchange server for internal access or to a Web Application Proxy server for external access.

  2. Exchange on-premises (for internal access) or Web Application Proxy (for external access) redirects the user to AD FS for authentication.

  3. AD FS uses Integrated Windows authentication for internal access or provides a web form in which the user can enter credentials for external access.

  4. Responding to an AF DS access control policy, AD FS calls Azure AD Multi-Factor Authentication to complete authentication. Here's an example of that type of AD FS access control policy:

    Screenshot that shows an example of an AD FS access control policy.

    The user gets a request to complete multi-factor authentication.

  5. The user completes multi-factor authentication. AD FS redirects the authenticated web session to Exchange on-premises.

  6. The user can access Outlook.

To implement this scenario for an on-premises user, you need to configure Exchange and AD FS to set up AD FS to pre-authenticate web access requests. For more information, see Use AD FS claims-based authentication with Outlook on the web.

You also need to enable integration of AD FS and Azure AD Multi-Factor Authentication. For more information, see Configure Azure MFA as authentication provider with AD FS. (This integration requires AD FS 2016 or 2019.) Finally, you need to synchronize users to Azure AD and assign them licenses for Azure AD Multi-Factor Authentication.


  • Azure AD. Azure AD is a Microsoft cloud-based identity and access management service. It provides modern authentication that's based on EvoSTS (a Security Token Service used by Azure AD). It's used as an authentication server for Exchange Server on-premises.

  • Azure AD Multi-Factor Authentication. Multi-factor 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.

  • Azure AD Conditional Access. Conditional Access is the feature that Azure AD uses to enforce organizational policies like multi-factor 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 this architecture, 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.

  • Exchange Server. Exchange Server hosts user mailboxes on-premises. In this architecture, it uses tokens issued to the user by Azure AD to authorize access to mailboxes.

  • Active Directory services. Active Directory services stores information about members of a domain, including devices and users. In this architecture, user accounts belong to Active Directory services and are synchronized to Azure AD.


You can use Azure AD Application Proxy as an alternative to AD FS and Web Application Proxy for publishing the Exchange on-premises web access service. There are some disadvantages to this alternative approach:

  • Lack of documentation for publishing Exchange
  • Lack of Exchange-specific scalability figures
  • Vanity URL (owa-company.msappproxy.net)

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 multi-factor authentication requirements for messaging service access is one of the most effective ways to meet that challenge.

This article describes an architecture to enhance your security in a web access scenario by using Azure AD Multi-Factor Authentication.

The architectures here describe scenarios to help you protect your messaging service (Outlook on the web or Exchange Control Panel) when mailboxes are hosted in Exchange Online or Exchange on-premises.

For information about applying multi-factor authentication in other hybrid messaging scenarios, see these articles:

This article doesn't discuss other protocols, like IMAP or POP. We don't recommend that you use them to provide user access.

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.


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 ensures that your application can meet the commitments that you make to your customers. For more information, see Overview of the reliability pillar.


Overall availability depends on the availability of the components 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:


For information about the resiliency of the components in this architecture, see the following resources.


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 the security of the components in this architecture, see the following resources:

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 Azure AD 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.

The solution requires at least Azure AD Premium P1. For pricing details, see Azure AD pricing.

For information about Exchange, see Exchange Server pricing.

For information about AD FS and Web Application Proxy, see Pricing and licensing for Windows Server 2022.

Performance efficiency

Performance efficiency is the ability of your workload to scale in an efficient manner to meet the demands that users place on it. For more information, see Performance efficiency pillar overview.

Performance depends on the performance of the components 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:


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 deploy this scenario, complete these high-level steps:

  1. Start with the web access service. Improve its security by using an Azure Conditional Access policy for Exchange Online.
  2. Improve the security of web access for on-premises EMI by using AD FS claim-based authentication.

Set up a Conditional Access policy

To set up an Azure AD Conditional Access policy that enforces multi-factor authentication, as described in step 3 of the online user's flow earlier in this article:

  1. Configure Office 365 Exchange Online or Office 365 as a cloud app:

    Screenshot that shows how to configure Office as a cloud application.

  2. Configure the browser as a client app:

    Screenshot that shows applying the policy to the browser.

  3. Apply the multi-factor authentication requirement in the Grant window:

    Screenshot that shows applying the multi-factor authentication requirement.


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

Principal author:

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

Next steps