Introduction

As the topic suggests, the following post will be about the Azure AD Application Proxy feature – a feature within Azure Active Directory. I haven’t blogged specifically about this feature before, but I do think it deserves a mention here as well.

I will go into details on how to provide secure remote access to an internal IIS website, and give an example on how to add single sign-on to that experience while protecting everything with Conditional Access.

This post will be followed up with a continuation, where everything will be put to use on a mobile device with a Microsoft Intune managed Edge browser. Curious? Read on and stay tuned 🙂

Application Proxy Installation

First things first. The application proxy connector will need to be installed on at least 1 server in your on-premises AD. I’m not covering this part in details, but the installation and process here is pretty self explanatory.

• Log in to your favorite Azure portal: https://portal.azure.com
  • Browse your way into Azure Active Directory -> Enterprise Applications -> Application Proxy
  • Download and install the connector service on relevant servers
  • Note: This is based off my company’s tenant as we already have anything in place. I have obfuscated the server names and IP addresses for obvious reasons 🙂
  • If you are looking for more details on the connectors, see this: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-connectors

New enterprise application

• Next up is to create a new enterprise application for the internal website. This is also done when browsing Azure Active Directory -> Enterprise Applications -> Application Proxy
• Select to Configure an app

• In my test scenario, I have a simple website hosted on an internal IIS on http://imab/
  • For good measures, this is just a CNAME pointing to the actual server hosting the IIS.
  • Fill in a name and the internal URL and keep the defaults
  • Note: You have the option to use your own domain name. This is probably the recommended scenario, but requires some additional setup in terms of a certificate and additions to your public DNS. More details here: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-custom-domain

Single Sign-On

This website in particular uses Windows Authentication, which means we need to do some additional configuration if we want to provide our users with a Single Sign-On (SSO) experience when browsing the site from the Internet. This is a configuration I have made deliberately for this purpose to also cover the Windows Authentication SSO setup.

You can verify if your site runs Windows Authentication in the IIS Manager on the server:

• Browsing your newly created enterprise application. In this scenario, mine is called imab. Find Single sign-on in the menu and select Windows Integrated Authentication

• As you might have noticed from the IIS illustration above, the server hosting my internal website is called HAWAII (nothing secret here)
  • For IWA SSO, you will need to provide the Internal Application SPN (Service Principal Name). I will explain where and how this is obtained in the next section
  • Fill in with http/YourServerName

Connector AD objects

In order for above to have an effect, you will need to do some configurations on the computer objects of your Application Proxy in your Active Directory. This is required to allow the Application Proxy to impersonate users.

• Find and locate the computer object of the server hosting your Azure AD Application Proxy connector
  • Bring up the Properties -> Delegation tab and configure the settings as shown below
  • Hawaii is still the server hosting my website internally
  • Note: If you have more than 1 connector, you obviously need to do this for all servers hosting the Application Proxy connector

• For your convenience, I have included a illustration of the step following by clicking on Add. 

Assign to users and access the website

Now, before trying to access the website using the external URL, you will need to assign the new Enterprise Application to your users.

• Assign to whatever suits your needs and requirements:

• Find the external URL on the Properties of the new Enterprise Application: https://imab-kromannreumert.msappproxy.net/

• Accessing the external URL from a device where I’m already authenticated with Azure provides me with the complete SSO experience
  • If you skip the Windows Authentication SSO configuration we did previously, you will be presented with a prompt for credentials
  • If you try to reach the external URL from a private device, you will be asked to authenticate with Azure

Conditional Access

To put the icing on the cake, you can protect everything with Conditional Access. The requirement here from the organization might be, that the website is only accessible from compliant devices (and thus comply with your requirements for a secure device). This is something that a simple Conditional Access policy can do:

• Create a new Conditional Access policy, target the relevant users and select your newly created Enterprise Application in Cloud apps:

• For the simplicity, all you need to select is Grant access: Require device to be marked as compliant

End-user experience

Now, browsing the external URL from a completely private and thus non-compliant device:

More information

• https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy
• https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-single-sign-on-with-kcd