Hybrid Modern Authentication: Should I Care or Not?
Michael Van Horenbeeck MVP, MCSM
In this blog post, Microsoft recently announced support for Hybrid Modern Authentication for Exchange Server 2013/2016 on-premises. What is this Hybrid Modern Authentication, and is it something you should tinker about? As with most questions in IT, the answer is less straightforward and leans towards what most consultants would say: “it depends”.
What is Hybrid Modern Authentication (HMA)?
For as long as I can remember, people have always complained about the authentication options (or lack thereof) for Exchange. Although a lot of authentication options already exist today, some can be cumbersome and not always provide a good user experience. This is especially true in a mobile-first, cloud-first era, where Exchange server on-premises is lacking behind of the options available to e.g. Office 365. Hybrid Modern Authentication is, in a way, Microsoft’s answer to close that gap once and for all.
In short, once you enable Hybrid Modern Authentication, your Exchange servers will rely on Azure Active Directory for authentication client connections. In turn, you get access to all the cool features such as Azure Multi-Factor Authentication, Conditional Access, etc.
In a bit longer version, HMA enables Exchange to consume tokens issued by Azure AD. In turn, authentication is either performed by Azure AD or another federated solution (like an on-premises AD FS server farm). This means you can leverage AD FS to authenticate users to Exchange for all workloads and protocols: MAPI/HTTP, OWA, EWS etc. To use Outlook mobile with Exchange on-premises, you’ll have to wait a little longer though. For other mobile clients, you will have to make sure they support OAuth, like in IOS's latest release. This doesn't mean you cannot use basic authentication with EAS anymore. But why would you? If you are serious about providing a good user experience, you will have to factor in the experience on mobile devices as well. Of course, using an MDM solution to obscure some of the drawbacks of e.g. basic authentication is also an option, but outside the scope for this article.
What’s the caveat, I hear you say? Well....It’s an all-or-nothing solution. Either everyone in your organization uses HMA, or none does. You cannot granularly roll out HMA. If you are already using Office 365 for other workloads, that isn't necessarily a bad thing. However, if you have yet to deploy an Office 365 tenant, you have some more work ahead.
From a high-level perspective, you need to do the following to make HMA work:
Synchronize all your (Exchange) users to Azure AD; and have Exchange Hybrid write-back enabled.
Deploy a full hybrid Exchange configuration. You must run the Hybrid Configuration Wizard, enable the full hybrid experience and make sure that OAuth is properly configured and working correctly.
Use MAPI/HTTP for (Outlook) connectivity to Exchange
Bear in mind this is super high level. There is just a little more to it than these few bullets. Covering the setup is for a future article…
So, what will prevent you from rolling out HMA?
Failure to comply with the above requirements (e.g. using RPC/HTTP instead of MAPI/HTTP)
Coexistence with a previous version of Exchange (Exchange 2010 or 2007)
Using SSL offloading for Exchange (this will invalidate the OAuth authentication requests)
Have mobile clients that do not support OAuth/Modern Authentication.
How does it work?
Again, from a high-level perspective, here's what happens when a user attempts to connect to Exchange once HMA is enabled:
Your client (e.g. Outlook) connects to Exchange and is prompted for authentication. This prompt is merely a redirection to Azure AD.
The client now connects to Azure AD, and is prompted to provide credentials.
Depending on how you have configured authentication in Azure AD, one of several things can happen:
The client is redirected back to an on-premises AD FS server farm, or third-party solution for authentication
The client is authenticated against Azure AD (e.g. when using Password Sync)
The client is authenticated using another way (e.g. Pass-Through Authentication, SSO)
If the authentication was successful, the user receives Access and Refresh tokens from Azure AD and is redirected back to Exchange
The client presents the Access token to Exchange and can now connect.
Do I need HMA?
Of course, you do...! Seriously though. It depends. It can go a long way to streamline the end user experience when moving to Office 365. By doing so, you minimize the "impact" when a user is 'moved' to Office 365, therefore increasing user happiness (and perception of the service you are offering). On the other hand, why change something if it works well? If, today, you have a working on-premises solution and no need for any of the additional capabilities Azure AD has to offer, you aren't planning to move to Office 365, or you have had no complaints about the different end user experience between on-premises and Office 365, there is no real incentive for you to deploy HMA.
I like to look at it as an opportunity, low-hanging fruit if you will. If you already have an Office 365 tenant or possibly even a hybrid deployment already in place, it only requires little effort to introduce HMA.
What's your take on HMA? I'd love to hear from you!
Looking to get ultimate visibility into you Hybrid Office 365 environment? Mailscape 365 helps you manage the cloud like you own IT. Get started with a free trial now:
Michael Van Horenbeeck MVP, MCSM
Michael Van Horenbeeck is a Microsoft Certified Solutions Master (MCSM) and Exchange Server MVP from Belgium, with a strong focus on Microsoft Exchange, Office 365, Active Directory, and a bit of Lync. Michael has been active in the industry for about 12 years and developed a love for Exchange back in 2000. He is a frequent blogger and a member of the Belgian Unified Communications User Group Pro-Exchange. Besides writing about technology, Michael is a regular contributor to The UC Architects podcast and speaker at various conferences around the world. You can follow Michael via twitter (@mvanhorenbeeck) or his blog michaelvh.wordpress.com.