How to secure Exchange 2016 with Azure AD – Part 2 – Hybrid Modern Authentication

As Microsoft continue to develop the functionality in Office 365 and Azure AD, the cloud becomes a more and more attractive proposition for organisations that previously would not have been able to move data away from their on-premises servers. And whereas Exchange Online has previously been the first entry point for many organisations, the ever-improving security offerings within Azure AD can now offer a better initial introduction to the cloud, in some instances without the need to migrate any data at all.

In this series of blogs I’m going to look at the end-to-end process of taking an organisation from not publishing any Exchange on-premises services to the internet, to publishing Autodiscover, Outlook and OWA/Outlook on the Web externally, secured with Azure AD Conditional Access, Hybrid Modern Authentication and the Azure Application Proxy.

In Part 1 I explained how to configure Kerberos authentication for Outlook Web App in Exchange 2016 to prepare for publishing via the Azure Application Proxy. This isn’t required for Autodiscover, MAPI, Outlook Anywhere or EWS because they are supported by Hybrid Modern Authentication. In this part I will explain how to configure Hybrid Modern Authentication with Exchange 2016.

Hybrid Modern Authentication

Hybrid Modern Authentication (HMA) allows you to secure your on-premises Exchange and Skype for Business estate using the benefits of Modern Authentication, such as Azure AD Conditional Access and Multi-Factor Authentication (MFA). In order to support HMA your Exchange servers must be patched to Exchange 2013 CU19 or later/Exchange 2016 CU8 or later. In addition all Exchange 2010 servers must be removed from the organisation or the ability to even configure HMA will not be available. In addition – whether you intend to migrate users to Exchange Online or not – you must run the Office 365 Hybrid Wizard to establish the Hybrid Configuration in your organisation.

Currently HMA only supports MAPI, Autodiscover, Exchange Web Services (EWS), ActiveSync and OAB, not OWA or ECP (more on this later), and the client access virtual directories in Exchange must be configured correctly. In this blog post I will be assuming that you have already configured CAS with an appropriate external DNS name, and certificates etc are all configured correctly, and Azure AD Connect is already configured for identity synchronisation and authentication.

To configure Azure AD to successfully authenticate on behalf of your on-premises Exchange organisation you need to add the Exchange on-premises CAS Virtual Directory URLs to the Exchange Online Service Principal. This will ensure that your Exchange on-premises authentication requests will get handled in the same way as Exchange Online requests. To collect the CAS URLs run the following commands against Exchange on-premises:

Get-MapiVirtualDirectory | FL server,*url*

Get-WebServicesVirtualDirectory | FL server,*url*

Get-ActiveSyncVirtualDirectory | FL server,*url*

Get-OABVirtualDirectory | FL server,*url*

In my example I am using a single URL, mail.mp365lab.co.uk, for Client Access, so this and Autodiscover.mp365lab.co.uk will be added to my Azure AD Service Principal using Azure AD PowerShell:

$x= Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000  

$x.ServicePrincipalnames.Add("https://mail.mp365lab.co.uk/")

$x.ServicePrincipalnames.Add("https://autodiscover.mp365lab.co.uk/")

Set-MSOLServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 -ServicePrincipalNames $x.ServicePrincipalNames

You should run the following commands to enable OAuth on each virtual directory in Exchange on-premises before enabling HMA:

Set-AutodiscoverVirtualDirectory -Identity 'ECH1\Autodiscover (Default Web Site)' -OAuthAuthentication $true

Set-OABVirtualDirectory -Identity "ECH1\OAB (Default Web Site)" -OAuthAuthentication $true

Set-WebServicesVirtualDirectory -Identity "EXCH1\EWS (Default Web Site)" -OAuthAuthentication $true

Set-MapiVirtualDirectory -Identity "EXCH1\MAPI (Default Web Site)" -IISAuthenticationMethods NTLM,Negotiate,OAuth

As I mentioned before, you need to run the Office 365 Hybrid Configuration Wizard before configuring HMA. This is to provision the necessary Auth Server to support the Azure AD authentication. You can validate whether or not the Auth Server object has been created by running the following command.

Get-AuthServer | where {$_.Name -eq "EvoSts"}

You can then run the following commands to enable HMA:

Set-AuthServer -Identity EvoSTS -IsDefaultAuthorizationEndpoint $true 

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

And that’s it – you now have HMA configured for Exchange 2016!

Hybrid Modern Auth Flow

Once you’ve completed the steps above your users will authenticate using HMA, so what does this look like?

HybridModernAuthFlow

  1. A user will open Outlook and it will connect to it’s CAS server using Autodiscover. When the user hits Exchange, it will be redirected to the evoSTS URI configured using Set-AuthServer and Set-OrganizationConfig.
  2. The client will then contact Azure AD to sign in, and will be prompted to provide username and password in the standard Azure AD Modern Auth flow. The users will be authenticated using the same Conditional Access policies assigned to the Exchange Online application in Azure AD.
  3. When the user successfully authenticates, they are given an Access Token and a Refresh Token for their authentication.
  4. The user provides the Access Token to Exchange 2016 CAS and accesses the mailbox.

Summary

We now have Kerberos configured for OWA (Part One) and HMA working to authenticate all other Exchange 2016 services. In the next and final part, we will configure the Azure App Proxy to act as a proxy for OWA/ECP, and provide the same Conditional Access Protection for all services.

If you have any questions or comments please either use the comments section below, Tweet me @MikeParker365 or via email blog@mikeparker365.co.uk.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s