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 to the cloud. And whereas Exchange Online has previously been the entry point for organisations, the ever-improving security offerings within Azure AD now offer a better initial introduction to the cloud, in some instances without the need to migrate any data to the cloud at all.
In this series of blogs I’m going to look at the end to end process to take an organisation from not publishing any Exchange on-premises services to the internet, to publishing Outlook and OWA/Outlook on the Web, secured with Azure AD Conditional Access, Hybrid Modern Authentication and the Azure Application Proxy.
In Part 1 I configured my Exchange 2016 virtual directories for OWA and ECP to authenticate using Kerberos, more on this shortly. In Part 2 I configured Hybrid Modern Authentication to begin using Azure AD to authenticate Exchange on-premises services. Part 1 is a hard requirement for this to work, so if you haven’t already, check it out! In this final part I will now move on to publishing OWA and ECP using the Azure Application Proxy to also secure these final services with Azure AD.
Installing the Application Proxy Connector
The first stage is to install the Application Proxy Connector from Azure AD onto your connector server. The server must meet the following requirements:
Operating System either Windows Server 2012 R2 or Windows Server 2016
Make sure the network is configured as per the documented requirements.
The connector must have access to all on premises applications that you intend to publish.
You can download the proxy connector by going to the Azure Active Directory blade within Azure, Application Proxy and click download a connector.
You then accept the terms and download the file to your connector server. Installing the connector is as simple as running the MSI wizard, and signing into Azure AD with a Global Admin account.
You may also need to enable application proxy in your tenant if the option is available at the top of the Application Proxy blade:
Once the Application Proxy Connector is installed you need to delegate permissions to the Kerberos Alternate Service Account configured in Part 1 for the Azure Application Proxy Connector machine.
To do that you should open up the properties of the Azure Application Proxy Computer Account from ADUC, and go to the Delegation tab. From here, select “Trust this computer for delegation to specified services only” and “Use any authentication protocol” then select Add.
You should search for your ASA Computer Account created earlier
And then select it from the Add Services window (Make sure you select it before hitting OK!). You should notice that the User or Computer name shows the OWA FQDN not the machine name, in my case it is exchange.mp365lab.co.uk.
Once you have added the service here your Delegation tab should look like this:
Now you have completed the on-premises configuration you need to move on to configuring your application in Azure AD.
Configuring the Enterprise Application
Log in to the Azure AD Portal with an administrator account, and go to the Enterprise Application blade. From here select New application.
From the Add an application window select On-premises application.
You should then complete the add application form as appropriate for your app, however, be aware that the Internal Url must match the URL configured for OWA, Pre Authentication should be set to Azure Active Directory (this is what sets AAD as the authenticator for OWA, and once you successfully authenticate, the Application Proxy Connector server will pass the authentication to the ASA and authenticate on-premises using Kerberos) and Translate Urls in Headers should be set to No.
You should then repeat the above steps to create an application for the ECP URL.
At this point if the OWA URL has been added to the Exchange Online SPNs in Part 2 then your Exchange Online Conditional Access policies will now apply to Exchange On-premises as well, and you can direct users to the application proxy URL – in the case above https://owa-mp365lab.msappproxy.net/owa/ – to sign in to OWA in Exchange 2016. If you didn’t set the SPNs, or even if you did, you can set up custom CA policies to protect your on-premises infrastructure by targetting the newly created Enterprise Applications, and can even have a more restrictive policy to access ECP than OWA.
And that’s it, you’re done! You are now securing Exchange on-premises using the powerful security features of Azure AD! This blog series is obviously assuming that you are already using Azure AD Conditional Access and configured in the cloud correctly. If any blogs on other technologies such as Conditional Access would be helpful to complete the picture please let me know!