A quick intro to Azure AD Application Proxy

One of the features in the premium license of Azure AD is the Application Proxy (AAD AP). This feature can be compared with the Web Application Proxy (WAP) role which you can install on top of Windows Server 2012 R2. In this post we will go over most of its features which are now available in the preview release.
AAD AP can be used to publish applications inside your private on premise or cloud network. The AAD AP can be configured as an out of the box service within Azure AD which, at this point, is the main difference and a huge benefit compared to WAP. As the WAP role does require a dedicated server and a trust connection with an ADFS server, the AAD AP now only requires you to install an Application Proxy connector on a server within your environment. There is only one requirement for publishing a web application: The web application in your private network must be accessible by the server where the connector is being installed. In other words, you can either install the connector on the application servers itself or on any other server within your environment. It’s all fine as long the connector is able to access the web application.
















Will the new connector cause a single point failure? This was one of the first things I was wondering about. Microsoft does clarifies this and their explanation is simple. Every single connector you install and connect with your Azure AD tenant will become a failover connector for the other installed connector(s) within your network. In other words, when the AAD AP does not receive a response of one of the connectors it will automatically send the request to one of the other connectors. The connector will now access the requested resource on behalf of the user and direct the response back to the client device.

For publishing applications, the AAD AP supports two methods:
-Pass through

Especially this last option gives us some huge benefits as we are now able to authenticate with Azure AD. In this case there is now extra trust related configuration required, this all is automatically configured by Azure AD itself. This option becomes even better if you combine this with the Azure AD Sync functionality. It will offers users the ability to authenticate at Azure AD with their on-premises credentials and access applications in your private network from any location in the world.
After this global introduction of AAD AP, it is time to start configuring this thing! As noted, the only requirement, to make use of the Application Proxy feature, is an Azure AD premium license. First I will give you a quick overview of the test scenario:














First of all, we enable the Azure AD Application Proxy on the configure tab in Azure AD:


The next thing we do is download the Application Proxy connector and install it on one of the servers within the private environment. You can either choose to install it directly on the application server or on a separate machine.


After the installation has been finished, we can register our connector with Azure AD. Afterwards we can start configuring the Azure AD Application Proxy.

We do this by adding an application to the Azure AD configuration. When adding an application to Azure AD you have three options:


The first option gives you the ability to add an application to Azure AD based on protocols like OpenID connect or WS-Federation. The second option lets you make a choice of all the already “preconfigured” SaaS applications which are available in the Azure AD store. The third option will add an application to Azure AD which is published by Application Proxy.
After selecting the third option, you can give the application a unique name. In the next screen you can configure how the application is published.


At this moment the external URL is fixed and related to the name of the application you have just entered. The protocol to publish the application is only thing you may tweak related to the URL.
The pre-authentication method can be either set to pass-through or Azure Active Directory. In the test scenario we pick Azure Active Directory.
The Internal URL is the address which the Application Proxy connector will access in the environment. When this configuration is being set you have successful published the application.

After the configuration is done, you can start assigning users or groups which are granted access to application.


You can either login on https://myapps.microsoft.com or directly access the URL. The user experience in both situations is similar: You will get redirected to an authentication page:



After logging in you will directly see the web page of the application or you can click on the App icon in the portal. A nice addition to this guide might be my earlier post on Azure AD Sync. This gives you the ability to login with your on premise credentials. Enjoy!