How to secure Exchange 2016 with Azure AD – Part 3 – Azure Application Proxy

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:


Kerberos Delegation

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


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 – 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!

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

6 thoughts on “How to secure Exchange 2016 with Azure AD – Part 3 – Azure Application Proxy

    1. Hi David – I think this connection would be proxied by the CAS Servers, so you wouldn’t need to publish the Office Online Servers additionally, but I haven’t tested it. One to try later on! Mike


  1. Great series Mike. Out of interest why wouldn’t you use App Proxy to also publish EWS etc, I get that HMA gives you the Azure AD integration but App Proxy does this and more including reducing the attack surface (no Inbound ports) and no need for load balancers. Perhaps it’s not supported? Theoretically if the SSO between these is problematic could you combine HMA & App Proxy setting it to PassThrough auth thereby enabling the network security & availability benefits of App Proxy + HMA?

    Liked by 1 person

    1. Hi Dave,
      Strangely enough this is something that came to mind yesterday whilst looking at putting HMA/AAP in for a customer. Theoretically I think this should work, however, particularly if you are in a hybrid scenario there are a lot of pitfalls to putting any sort of proxy in front of Exchange. I don’t think SSO would be a problem as we can set the other virtual directories up to use kerberos as well.

      As you mentioned, supportability would be something you would need to get clarified from Microsoft, and although I can’t see any reason why this wouldn’t work, it would obviously need testing.

      Maybe stay tuned for a surprise continuation of Part 4 (although it may end up being Part 5 as I am keen to use this scenario to demo the new Password-less sign in capabilities of Azure AD!).


      Liked by 1 person

      1. Great minds think alike 🙂 Look forward to parts 4 & 5 if they happen. If I happen to end up trying it I’ll let you know. The other use case is just to front MRS Proxy for Hybrid Lite scenarios, ie migration no coex. I wonder how well App Proxy would handle the load as it’s not your usual web traffic.


Leave a Reply

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

You are commenting using your 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