Azure AD Application Proxy (AAD-AP) is a type of reverse proxy solution that enables access to web-based applications that exist on a corporate LAN, secured behind a corporate firewall.

The benefits of using AAD-AP rather than using a traditional firewall to expose an application to external access are (1) the convenience of listing the application in the user’s Office 365 menu choices (see first screen shot below) or the Azure Access panel and (2) the enhanced security of preauthentication using Azure Active Directory and the option of enhancing security with Azure Multifactor Authentication. These later two security enhancements were previously provided by solutions such as Microsoft ISA or TMG.

The convenience that users benefit from is having one place to access all internal web-based corporate applications, as well as over 2,400 3rd party SaaS applications. In the screen shot below you will see that amongst the Office 365 applications list, I have also configured single sign on for Facebook, Google Docs, ADP, Salesforce, and more. It is very convenient to logon once to Azure Active Directory or Office 365, then launch other applications without having to logon to those applications individually.  This amounts to huge time savings and it is really nice not having to remember 10 separate usernames and passwords! This now puts Azure AD on par with other hosted identity providers such as Okta, Onelogin or PingFederate.

This blog post is a review of AAD-AP, a component of Azure AD Premium and Azure AD Basic.

AAD-AP exposed application ‘My Intranet’ in Office 365

If you don’t have Office 365 you can also use the Microsoft Azure access panel to achieve SSO (as shown below).

http://myapps.microsoft.com (this redirects you to https://account.activedirectory.windowsazure.com/profile/ )

The 3rd way of accessing internal applications through AAD-AP is a direct hyperlink. This is provided after configuring the application in the Azure management portal.
For example: https://myintranet-tctechnologist.msappproxy.net/ 
The convention is: (Application Name – Azure Tenant Name – MSAppProxy.net (similar in concept to the O365 tenant name “onmicrosoft.com”)
Custom domain names are coming soon, so you will be able to have the AAD-AP name in front of your own domain name, ex: https://myintranet.contoso.com 

 

Application Proxy Prerequisites

• You must have an Microsoft Azure administrator account. If you don’t’ have one, you can get a 30 day trial here.
• You must have an Azure AD Premium license. For more information, see Getting Started with Azure AD Premium. You can also get a 30 day trial to evaluate this as well.
• A server running Windows Server 2012 R2 or Windows 8.1 or higher on which you can install the Application Proxy Connector. The server must be able to send HTTPS requests to the Application Proxy services in the cloud, and it must have an HTTPS connection to the applications that you intend to publish.
• The server running the connector must be able to make outbound connections to this domain and subdomain: msappproxy.net on the following TCP/IP port ranges:
  443, 20200-20210, 9352, 10100-10120, 8080, 9090 and 9091. For a description of what these ports are used for, see : https://msdn.microsoft.com/en-us/library/dn768214.aspx
  • There are no inbound ports required, because Azure Application Proxy service (ApplicationProxyConnectorService.exe)  initiates a reverse tunnel from the VM out to Azure.
• If the web application requires windows integrated authentication, then the machine where the connector is installed must be joined to the domain.
• For windows integrated authentication, The UPNs in Azure Active Directory must be identical to the UPNs in your on-premises Active Directory in order for preauthentication to work. Make sure your Azure Active Directory is synchronized with your on-premises Active Directory.
• For accessing applications remotely, the application that you are proxying cannot send the user any 302 redirects otherwise those will most likely contain internal server names that are not accessible internally. See the scenario below that happens when I first tried to publish the Lync control panel. The fix for the Lync scenario was to publish the actual path to the CSCP virtual directory. This is thanks to the new Path Publishing feature that was announced on March 11th, 2015 on the Azure Application Proxy blog here.
• In my testing, AAD-AP worked with Windows machines running Internet Explorer or Chrome, iOS devices and Mac OSX (Safari and Chrome). The official support statement says that the Access Panel Extension is available for Internet Explorer 8 and later, Chrome, and Firefox browsers.

Microsoft AAD Application Proxy Connector

The connector is a small 4 MB file that can be downloaded from the Azure Management Portal when configuring a new application that relies on Application Proxy.

You should install the connector software on a VM that has HTTP/S access to the application that you want to publish, and outbound access to Azure.

Installing the connector is quick and painless. The only information you are prompted to provide is just the Azure tenant administrator username and password.

It installs two services, the main service runs under network service because it must be able to interact with other servers to perform the reverse proxy, and optionally to perform Kerberos delegation for web based applications that required windows authentication.

Configuring the Connector for Windows Integrated Authentication

Let’s say you want to publish the Lync Control Panel to through the Azure application proxy.

Since the Lync Control Panel requires Windows Integrated Authentication, we need to configure the Active Directory Computer object for delegation. For step by step details, see this Microsoft article, otherwise I will cover the high level steps here.

I did not have a service principal name (SPN) for my Lync simple URL for administration, I had to create it first. Before creating an SPN, it is good practice to check to see if it exists first. You can query to see if an SPN exists with the ‘setspn’ command that you run in a regular command shell on any server (domain admin privs are required).
setspn -Q http/admin.thecloudtechnologist.com
Note: The SPN format is a little odd because there is a single forward slash, whereas you would normally expect to see a colon followed by two slashes.

To create the SPN, I ran this command:
setspn –S http/admin.thecloudtechnologist.com tctfe01  
(Note: The Lync ‘standard edition’ front-end server name was TCTFE01. For Enterprise editions, you will use a service account rather than an individual computer name). You can use the –Q or –L parameters to verify that it registered correctly.

After the SPN has been created, the next step is to configure the Active Directory Computer object for delegation. Find the computer object for the machine where you installed the Connector software in Active Directory Users and Computers. In my case, my connector was installed on a server named “HV1” so I found that object and on the delegation tab, I added the computer name of my Lync standard edition front end server “TCTFE01.” For Enterprise Edition deployments, you would configure delegation on the relevant service account instead.

This allowed me to find the SPN I had created for the SPN record admin.thecloudtechnologist.com

Now you can add the SPN into the Azure Management portal:

You should now see the Lync Control panel in the Office 365 list of applications.

What I found out next helped me to understand more about the features and limitations of Azure Application Proxy.

When I published the simple URL for the Lync control panel (‘admin.thecloudtechnologist.com’) I found that it was working internally but it failed to work externally. After some fiddler analysis I discovered that it was working internally because Lync web services sent an HTTP 302 Redirect to the internal DNS host name of the Lync standard edition front-end server, along with the virtual directory of the control panel, ex: (‘tctfe01.thecloudtechnologist.com/cscp’). Since the internal host name is not published in external DNS, nor is there a firewall rule permitting this, it failed externally.
So Azure Application Services is faithfully sending the 302 redirect back to the external user, so there was nothing broken, per se. This shows one requirement to be aware of – check to make sure that the application you want to proxy does not use 302 redirects.

HTTP/1.1 302 Redirect
Content-Length: 168
Content-Type: text/html; charset=UTF-8
Location: https://tctfe01.thecloudtechnologist.com/Cscp
Server: Microsoft-IIS/8.0 Microsoft-HTTPAPI/2.0
X-Powered-By: ASP.NET

<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF=”https://tctfe01.thecloudtechnologist.com/Cscp”>here</a></body>

The workaround that I found was to use the new path publishing feature (Thanks Microsoft Application Proxy team!!). This enabled me to publish the full path where the 302 redirect was sending the user to (‘https://tctfe01.thecloudtechnologist.com/Cscp’). This can only be setup when the application is first configured, so if you forgot to add /cscp in the beginning, you will need to delete the app and start over.

In my case, I didn’t have /cscp/ from the beginning, so I had to delete my app and start over like this:

There was already an existing SPN record, so I did not have to create another SPN for tctfe01.thecloudtechnologist.com, but I did have to configure computer delegation on the HV1 computer account for http/tctfe01.thecloudtechnologist.com instead of http/admin.thecloudtechnologist.com.

So even though the internal dns name of my Lync server is not published externally, this shows the power and benefit of Azure Application Proxy because I can now access the Lync administrative control panel from anywhere.

 

Recommendations

1. The connector software is not highly available, so make sure to install it on a virtual machine that benefits from high availability at the hypervisor layer (ex: vmotion or live migration).

2. Since this is such a new service, I am not sure what the scalability and performance of the connector service would be in a production environment. So you would need to perform your own performance testing. Consider using Azure’s Visual Studio Cloud Load Testing. 

3. In the next blog post in this series, I describe the new conditional access feature using Azure’s multi-factor authentication. See Controlling Access to Application Proxy (Optional)