When you think about the value proposition for Azure Active Directory Premium, most of the features that are front and center revolve around self-service password reset, multi-factor authentication (MFA), SSO for SaaS-based applications, and enhanced reporting. These features are certainly all great examples of how the value of Azure Active Directory Premium can be demonstrated within the enterprise.
What about the on-premises components still hanging on within your datacenter? Does Azure Active Directory Premium provide any value for the last vestiges of on-premises applications?
Yes!
I’ve said this many times and feel rather strongly that Azure Active Directory Premium is one of the most undervalued features found within Office 365. There, I’ve said it. I’ve taken this position because this feature does indeed provide a tremendous value proposition for the enterprise with MFA, self-service password reset, timely reporting, SaaS-based SSO integration (2,600+ apps and counting) along with the hidden gem no one is talking about – Azure AD Application Proxy.
The Azure AD Application Proxy feature allows the administrator to securely publish on-premises applications to the cloud. You may quickly dismiss this feature (as I did initially) because you already have the network infrastructure setup to securely route application traffic through a series of firewall contexts and load balanced VIPs. Ah yes, I fondly remember my administration days and the care and feeding required for maintaining TMG, ISA and Proxy 2.0 in the DMZ network. I still recall just how proud I was of passing that Proxy 2.0 exam! The level of effort to get these proxy services up and running was always a difficult task but thankfully they worked wonderfully from that point forward!
Microsoft positions this Azure-based service as a “Remote Access as a Service” offering. The value proposition here is that you can now further extend Azure Active Directory as your central management point for all your on-premises web-based applications. Essentially, why worry about securing physical DMZ endpoints, maintaining a large infrastructure footprint in the DMZ (TMG arrays anyone?), or configuring VIPs and firewall ACLs for web-based applications anymore! One has to wonder (I certainly do) just how much TMG code was repurposed in providing this Azure offering?
After logging into the Azure portal you will navigate to your directory, select the applications tab, and then add an application. After selecting the option to “publish an application that will be accessible from outside your network,” you will be asked to provide a name, internal URL and the desired preauthentication method (Figure 1.).
Figure 1.
At this point you will need to install a piece of software (think agent) called a Connector locally on an on-premises server (Figure 2.).
Figure 2.
There is a link to download the connector software within the application dashboard (Figure 3.).
The server that will run the connector software will need to be a member of the same domain as the server running the published application. Additionally, there are some firewall considerations that need to made outside of port 80 and 443. Make note that you do have the ability to test connectivity back to the Application Proxy service through the use of a Connector Troubleshooter button once the application is successfully installed. Best practice would be to run the troubleshooter workflow to ensure the required firewall ports are open prior to production deployment.
This connector provides the secure conduit for internet-based clients to access the application along with facilitating communication back to Azure Active Directory for publishing and authentication. If this approach seems like a single point of failure - don’t worry; you can simply install the connector software on multiple servers for redundancy. If you have multiple connectors installed, they can be managed from the dashboard view of the published application. Now, you are able to control access to your on-premises application by leveraging Azure Active Directory as the authentication mechanism.
End users can access the published application through a special URL that Microsoft provides, although using a CNAME in your external DNS might be a better approach. You also have the option to customize the application URL by using one of the verified domains within your tenant. Another simple access method for end users would be through the access panel (Figure 4.) located at myapps.microsoft.com. All client communication to the publicly accessible URL is routed through the application proxy component in Azure and back to the on-premises application via the secured connector.
Figure 4.
The authentication story around how the Azure AD Application Proxy feature works is interesting and worth additional consideration. As the administrator, you have the opportunity to enable a SSO experience for your end users by leveraging Kerberos Constrained Delegation (KCD) for the published on-premises Windows Integrated Authentication enabled applications.
Let’s take a look at the authentication process in a bit more detail.
An end user goes to the published URL for the application, and Azure Active Directory immediately makes the first pass at pre-authentication. At this point, MFA and authorization rules will be invoked if they have been configured. Microsoft is using a token to essentially impersonate the end user that is trying to gain access to the published application using KCD. Azure Active Directory sends the token to the end user, which is then passed to the Azure AD Application Proxy service. The Azure AD Application Proxy component validates the token and finds the required UPN and SPN and routes this exchange through the connector to the on-premises Active Directory. The connector then facilitates KCD on-premises in order to obtain a token from Active Directory on behalf of the user and presents this to the published application. Access is then granted by the application and routed back to the connector, the Azure AD Application Proxy service, and finally the end user.
This means that the UPN of the user found in Azure AD must exist within the on-premises Active Directory structure so a Kerberos ticket can be properly obtained. Also, make sure that Azure AD password hash synchronization has been configured unless AD FS exists. Based on this workflow, you will need to understand that your web-based applications do need to support integrated authentication. Given this requirement, keep in mind that this feature does not support NTLM, as it relies on KCD for SSO, and Kerberos is the only protocol that supports this functionality. Each published application using SSO with the Azure AD Application Proxy service must also have an SPN, and the machines running the applications and connector must be domain members. I’ve seen the SPN component forgotten, so keep in mind that without a SPN, Kerberos and ultimately KCD will not work!
The assumption here is that Microsoft ensures the authentication endpoint is always securely managed and up-to-date. Now, in the real world, this does not mean you as the customer bear no further responsibility to position additional monitoring and to ensure end-to-end administration to achieve expected availability and compliance.
There are numerous benefits that I see with leveraging the Application Proxy component found within Azure Active Directory Premium, which causes me to maintain a bullish stance. Let me lay out my thesis on why the Azure AD Application Proxy feature provides a tremendous value and see if you agree.
First, you are able to layer the built-in reporting within Azure Active Directory Premium on top of your published applications — reports like irregular sign in activity and users whose accounts may be compromised! Does your on-premises DMZ/Firewall/Load Balancer/VIP infrastructure provide that? Probably not. Checkmark for Azure AD Application Proxy.
You are also able to provide a streamlined sign in experience for your end users accessing the on-premises application as Azure Active Directory accounts are being used (you are using Azure Active Directory Connect for synchronization right?) for authentication.
Another great feature is that you can turn on MFA (Figure 5.) for your end users and provide seamless multi-factor authentication for access to your on-premises applications published through Azure AD Application Proxy. Typically, enabling MFA for on-premises accounts in the past involved rather extensive implementations that required a full-on cross-team project with funding.
As the administrator, you can simply select several checkboxes to enable the MFA service for users by leveraging the Azure framework. Plus, you can choose to only require MFA based on the employee location, such as when they are out of the office. If you choose to enforce location-based rules, then the complete range of trusted IPs (representing the corporate network) will need to be added. Yet another extension of this feature is the ability to remember when an employee successfully authenticates through MFA on a trusted device and to not prompt again for a predefined number of days. Another key win for Azure AD Application Proxy.
Figure 5.
Here is the final contributing factor to the value around the Azure AD Application Proxy feature. The authentication for access to your on-premises application is maintained outside your internal firewall. Typically, this type of traffic is carefully contained within a highly secure DMZ network within your on-premises environment. This approach allows you to ensure that only authenticated traffic is passed into your network, thus removing the need to worry about attacks against the externally facing published application endpoint (TMG/WAP).
All the incoming traffic for your published applications hits Azure Active Directory, so Microsoft is responsible for maintaining the security posture of the endpoint, while only outgoing connections to the Azure AD Application Proxy service are made from your on-premises network. Since Azure Active Directory is now your externally facing endpoint for HTTPS traffic, vulnerabilities like Heartbleed, for instance, are not exploits that you need to worry about mitigating externally; they are now Microsoft’s responsibility in this context. Even with this realized advantage, you are not totally absolved of the responsibility to appropriately patch your on-premises and DMZ infrastructure!
By ensuring that only authenticated traffic is passed into your network, removing the need to configure and secure an externally accessible on-premises endpoint for the application, layering on additional authentication mechanisms like MFA, location based authentication, and obtaining reporting that provides current state on accounts that may be compromised or exhibit suspicious activity – the IT department gains a unique security advantage that will free up additional administrative time.
So there you have it – the Azure AD Application Proxy service provides a unique value for those web-based on-premises applications still running in your datacenter! The Azure Active Directory Premium feature provides incredible value for both cloud-based services and on-premises. Maybe all that free time the IT department has gained will provide the availability to test Surface Books for corporate use? One can hope!