Azure AD Application Proxy – Access internal applications securely

For applications that reside on-premises, Azure Active Directory Application Proxy can provide your business with secure remote access to those applications from anywhere in the world. Besides secure remote access, you have the option of configuring single sign-on.

Typically, your organisation will have internally deployed SharePoint sites, Outlook Web Access, Citrix Director (for those Citrix customers), and many other line-of-business web applications. Using Application Proxy (a feature of Azure AD), you integrate those applications with Azure AD, and the applications can be consumed externally in a secure manner.

Often the case when needing to present such applications out to the internet, you have to depend on VPN-type solutions for security, proxies, DMZ extensions of your applications, or else modify different firewalls to accept direct traffic to your internal resources. Using Application Proxy, a Proxy Connector is installed on a server in your internal network, which acts as the broker (reverse-proxy) to provide you with access to that application. No need to deal with VPNs or firewall rules, just allow ports 80 and 443 from the Connector out to the internet.

AAP diagram from Microsoft.

Contents:

• Who is entitled to Application Proxy?
• What applications work with Application Proxy?
• What are the Application Proxy requirements?
• Further information on the Application Proxy connector
• Updating the Application Proxy connector
• Estimated Connector machine sizing
• Tips and recommendations to reduce latency
  • Side-notes that impact latency
• How to access applications via Application Proxy
• Authentication options with Azure Application Proxy
  • Pre-authentication options
  • Single sign-on options
• Password-based sign-on – Requirements
• Kerberos Constrained Delegation – Requirements
• Specifying an external URL
• Set up and configure Application Proxy with password-based sign-on
• Configure Application Proxy with KCD single sign-on

Who is entitled to Application Proxy?

• Customers with an Azure AD Basic, Premium P1 or Premium P2 subscription.

What applications work with Application Proxy?

• Web applications that use Integrated Windows Authentication (IWA) for authentication.
• Web applications that use form-based or header-based access.
• Applications hosted behind a Remote Desktop Gateway.
• Rich client apps that are integrated with the Active Directory Authentication Library (ADAL).

What are the Application Proxy requirements?

• An Azure AD Basic or Premium subscription as noted above.
• Proxy Connector (piece of software) installed on Windows Server 2012 R2 or 2016, which has access to the internal web applications you are publishing and access to the Application Proxy services in Azure cloud.
• Proxy Connector servers must be domain joined to the same domain as the applications you are publishing if you plan to use SSO via Kerberos Constrained Delegation.
• The following ports must be open from the Proxy Connector (v1.5.132.0 and later) to Azure:
  • 80 – Used to download certificate revocation lists (CRLs) while validating SSL certificates.
  • 443 – Used for outbound communication with the Application Proxy service.
• Also allow the Connector to reach the following domain names:
  • msappproxy.net – For proxy communication.
  • servicebus.windows.net – For proxy communication.
  • mscrl.microsoft.com:80 – For verifying certificates.
  • crl.microsoft.com:80 – For verifying certificates.
  • ocsp.msocsp.com:80 – For verifying certificates.
  • www.microsoft.com:80 – For verifying certificates.
  • login.windows.net – For registration process purposes.
  • login.microsoftonline.com – For registration process purposes.

Further information on the Application Proxy connector:

When providing secure, external access to applications via Application Proxy, you must install a Proxy Connector on your internal network, ideally close to the applications you publish. A connector is a lightweight agent that is installed on Server 2012 R2 or 2016 as noted above. This component acts as a proxy, relaying the web application traffic between your web browser and the backend web servers that host the application.

For redundancy and load balancing, it is recommended to install pairs of connectors, keeping in mind that load balancing is handled automatically in a round-robin fashion between connectors that reside in the same Connector Group.

A Connector Group is optionally created by the administrator, and each group handles traffic to specific applications. When you are adding an application to Azure, you specify a Connector Group (other than the default) that you would like to use. Connector Groups allow you to manage deployments at scale. For example, it may be best to create a Connector Group containing only the connectors residing in your US datacentre and choosing that Connector Group to interact with web applications from the same region.

Connectors can be added and removed easily from a group. If a connector becomes unavailable due to failure or maintenance, traffic is redirected to the next available connector.

Connector placement is interesting. Since they only initiate outbound traffic, it is not essential to place them within a DMZ. Also, in terms of captured data, connectors only store the required information needed to connect to the Application Proxy service. No application credentials, user information and so on is captured or stored.

Updating the Application Proxy connector:

The connectors are set to poll the Application Proxy service to find out if a newer version is available. This task is handled through the Microsoft AAD Application Proxy Connector Updater service. If an update is available, the connectors will update themselves. You can also manually update a connector if required.

If an update is performed during active traffic transactions with a client web browser, the transaction(s) would be lost. However, the client’s web browser should automatically retry the operation, or the user will refresh the page, at which stage the traffic is directed to another available connector.

Estimated Connector machine sizing:

The more an application is used, typically, the more resource you will assign to your connector servers. When it comes to sizing connectors, CPU and network capability is important. CPU is used to encrypt and decrypt traffic whilst a fast network will equate to fast access to your web applications and the Application Proxy service in Azure. Typically a connector can handle a couple of thousand requests per second for standard web traffic.

Maximum Transactions per second	RAM	CPU	Expected latency (ms)
586	8GB	2 cores	325
1150	16GB	4 cores	320
1190	32GB	8 cores	270
1200	64GB	16 cores	245

As you can see from the final three metrics, the maximum transactions per second does not differ greatly. The main difference is reduced latency.

Tips and recommendations to reduce latency:

• Group your Application Proxy Connector servers appropriately. For example, connectors should reside close to the applications they serve, such as in the same datacentre.
• Your connectors should have fast access to the web applications they proxy traffic to/from.
• Size your connector servers for peak traffic load. Monitoring tools should be used so that CPU or network constraints are brought to your attention for remediation before user experience is impacted.
• For fast connections between the Application Proxy service and connector server, dedicated VPN solutions such as ExpressRoute should be implemented.
• Domain Controllers should quickly issue Kerberos tickets if you are using Kerberos Constrained Delegation as an authentication method to provide single sign-on to your applications. Connectors have a cache of Kerberos tickets, but the responsiveness of domain controllers can affect performance when tickets are issued.

⮩ Side-notes that impact latency:

All proxy solutions will introduce a level of latency into your network connection. Application Proxy service instances for your Azure tenant are created in the same, or closest region as your Azure AD tenant. For example, if you sign up to Azure and specify your Azure AD region to be in the EU, all your Application Proxy service instances will be located in EU Azure datacentres. Keep this in mind, as when users access applications via Application Proxy, the connectors will route their traffic through service instances in this location.

When installing connectors, think about where the internal applications are located, where most of your users are located, and if you have dedicated VPN or ExpressRoute set up. It is possible to install the connector in Azure, for example if you have private peering between Azure and your corporate network, and low latency could still be achieved. Microsoft recommend making use of ExpressRoute if you have it, so communication between on-premises applications and Azure are going through a dedicated connection rather than out through the public internet.

How to access applications via Application Proxy:

• Visit the applications directly using the external URL that you provide in Azure.
• Visit the Azure AD access panel – https://myapps.microsoft.com
• If you are an Office 365 customer, you can also visit the Office 365 application launcher – https://portal.office.com/myapps

Authentication options with Azure Application Proxy:

⮩ Pre-authentication options:

• Azure Active Directory – Microsoft recommend keeping this option enabled. Doing so allows you to take advantage of Azure AD security features such as Conditional Access for multi-factor authentication. Before a user is granted access to their application, they must sign in to Azure AD first. This can be helpful in preventing anonymous attacks on your applications such as DDOS attacks, as you don’t get access to the application until authenticated.
• Passthrough – Users don’t have to authenticate against Azure AD to access the application. You can still set up authentication requirements on the backend.

⮩ Single sign-on options:

When using single sign-on, the Application Proxy Connector handles authentication to your on-premises application. The backend application cannot tell the difference between a remote user signing in through Application Proxy or a regular user connecting internally from a domain-joined device.

To use Azure AD for single sign-on to your applications, you need to select Azure Active Directory as the pre-authentication method. If you select Passthrough, your users are directed straight to the application.

• Azure AD single sign-on disabled – If you don’t want to use Azure AD integration for single sign-on to your application, select this method. With this option selected, users authenticate initially with Azure AD, and then potentially a second time with the application itself. If the application does not require authentication, this option would be a good choice to implement as a layer of security for remote access workers.
• Password-based Sign-on – Using this method, Azure AD acts as a password vault for your on-premises applications. Many line-of-business applications don’t integrate with Active Directory and have separate credential systems. Using this option, users log on to the application for the first time and subsequent attempts trigger Azure AD to authenticate on behalf of the user, using the previously entered credentials which are stored in the vault.
• Linked Sign-on – If you already have a single sign-on solution for your on-premises identities, choose this method. This option enables Azure AD to leverage existing SSO solutions, but still gives your users remote access to the application.
• Integrated Windows Authentication – If your app uses IWA, or if you want to use Kerberos Constrained Delegation for single sign-on, choose this method. Using this option, users authenticate with Azure AD initially, and then the Proxy Connector impersonates the user to obtain a Kerberos ticket from Active Directory to complete authentication with the application.
• Header-based Sign-on – If your application uses headers for authentication, choose Header-based sign-on. Using this option, users only authenticate with Azure AD. Microsoft partners with a third-party authentication service named PingAccess, which translates Azure AD access tokens into a header format for the application to consume.

Password-based sign-on – Requirements:

Password-based sign-on requirements:

This method is intended for apps that use a username/password combination for authentication. When you configure this method, your users have to sign in to the on-premises application once. After that, Azure AD stores the sign-in information and automatically provides it to the application when your users access that application remotely. Passwords are stored in an encrypted state in the directory and are only passed over HTTPS during the automated sign-in process.

With this method, a web browser extension or mobile app is required. The browser extension is used to securely retrieve the application and user-specific information from Azure AD and apply it to the service. This authentication method works for any web application that has an HTML-based sign-in page.

The following web browsers are required:

• IE7 on W7+.
• Edge on W10 1607+
• Chrome on W7 or later, and on MacOS X or later
• Firefox 26.0 or later, on XP SP2 or later and on Max OS X 10.6 or later

Kerberos Constrained Delegation – Requirements:

Application Proxy must be given permission in AD to impersonate users.

As the user enters the URL to access the on-premises application via Application Proxy, they first authenticate with Azure AD. Azure AD creates a token and passes it to the user. The user passes it to Application Proxy. The Application Proxy validates the token, retrieves the UPN from it, and then sends the request, the UPN and the SPN to the connector. The Connector performs KCD negotiation with the on-premises Active Directory domain controller(s), impersonating the user to get a Kerberos token. Active Directory then sends the Kerberos token for the application to the connector. The connector sends the original request to the application server, using the Kerberos token it received from AD. The application sends a response to the connector, which is relayed to the Application Service and finally to the user.

Applications must be set to use IWA (Integrated Windows Authentication). You must also create a Service Principal Name for participating applications. The connector and server running the application must be domain joined to the same domain or trusting domains. The connector server must have access to read the TokenGroupsGlobalAndUniversal attribute for users. This permission is set by default but may have been impacted by security hardening in your environment.

If you have a different domain internally and externally, you can still use KCD for single sign-on. To do so, you just configure the delegated login identity for each application to specify which identity should be used when performing single sign-on. For example, the options are:

• User principal name.
• On-premises user principal name.
• Username part of user principal name.
• Username part of on-premises user principal name.
• On-premises SAM account name.

Single sign-on errors are captured in the connector machine event log.

Specifying an external URL:

When adding an Enterprise Application to Azure to be used with Application Proxy, you might enter a URL such as http://mywebapp.com/homepage/ as this is the URL users browse to reach the home page of that web application. If your application loads images or uses other content located at mywebapp.com/media for example, you should publish the URL in Azure simply as http://mywebapp.com/. This internal URL doesn’t have to be the landing page your users see, as you can set a custom home page for published applications. Use the Azure AD PowerShell module to define custom home page URLs when you want users to land on a specific page within the application.

For example, when users are located on the corporate network, they may browse to http://mywebapp.com/homepage/login.aspx to log on to the web application. Because the web application has other assets like images that Application Proxy needs to access at the top level of the folder structure, you specify the internal URL as http://mywebapp.com. You then need to set http://mywebapp.com/homepage/login.aspx as the home page URL so that users are directed here when accessing the application externally. Also note that if you make a change to the published application, the change might reset the value of the home page URL. When you update the application in the future, you should recheck and if necessary update the home page URL.

Set up and configure Application Proxy with password-based sign-on:

Log on to the Azure portal and navigate to Enterprise applications.

Select On-premises application. The Azure portal will inform you that you have no Application Proxy Connector servers and that you must download and install the required software to a server. Click Download Application Proxy Connector.

Before installing the Application Proxy Connector software, turn off IE ESC (Internet Explorer Enhanced Security Configuration) via Server Manager. Click Accept terms & Download.

Run the installer from a supported server operating system, and click I agree to the license terms and conditions followed by Install.

Enter credentials of an Azure global administrator account.

Click Close to complete the install.

Two services are installed alongside the Proxy Connector:

• Microsoft AAD Application Proxy Connector – Enables connectivity.
• Microsoft AAD Application Proxy Connector Updater – Checks for new versions of the connector and updates the connector accordingly.

Return back to the Azure portal and click I’ve finished the installation.

Now you’ll be asked for details about the first on-premises application you want to add to Application Proxy. Enter details as below:

• Name – Specify a display name which you and users will see from the Azure portal, and from the Azure AD access panel etc.
• Internal Url – This is the URL you would use internally to reach the application.
• External Url – This is the external URL users will use to externally connect to the application. You can either use your own corporate external domain name that is verified with Azure AD, an .onmicrosoft.com or .msappproxy.net address. Note that using a custom domain name will require that you provide and upload a third-party certificate to Azure which has a Subject Name matching the external URL. You will also need to create the appropriate CNAME record on your public nameservers.
• Pre-Authentication – This can be set to Azure Active Directory or Passthrough. If set to Azure Active Directory, you challenge users with Azure AD authentication before allowing them access to the on-premises application. If set to Passthrough, users are passed through to the application itself and challenged for authentication there if required.
• Connector Group – As previously mentioned, you can create custom Connector Groups, allowing you to strategically tie together Application Proxy Connector servers with on-premises applications for best performance.
• Backend Application Timeout – Set this value to Long only if your application is slow to authenticate and connect. Microsoft recommends keeping this value as default.
• Headers – Keep this value set to Yes unless your application requires the original host header in the authentication request.
• Application Body – Keep this value set to No unless you have hardcoded HTML links to other on-premises applications and you do not use custom domain names.

Once all fields are complete, click Add.

Your application will show as below and is editable at any time. You can also add new applications from this screen. Click on Application proxy.

Here you can create new Connector Groups, download the connector service and view details about your active connectors etc. If a connector has been inactive for more than 10 days, it is removed from Azure.

To assign users to the application you just created, navigate to Enterprise applications -> All applications and click into your application. Now click Users and groups -> Add user.

You can assign access to individual users, or to groups (if using a paid version of Azure AD). Click on None Selected.

Select a user, or group, then click Select.

Click Assign.

From now on and by default, the application will appear under the Azure AD access panel etc. for users who have been assigned this application. Users can also browse to the application manually using the external URL configured when setting up the application.

Because pre-authentication was set to Azure Active Directory, we are challenged for authentication.

If authentication is successful, the application appears (traffic is routed through the Application Proxy Connector). Note the certificate error, because I haven’t added a third-party certificate to Azure that matches my custom domain name.

If you want to upload a certificate, when editing the properties of the application and under Application proxy you will find a Click here to upload a certificate option.

If you want to challenge users with multi-factor authentication. This is made easy using Conditional Access policies. I have already created a Conditional Access policy which enforces MFA, and during the creation, you are given the option of assigning that policy to an application.

The next time your users sign on to the application, they will be prompted to register with Azure MFA if they haven’t already.

Future authentication attempts will be challenged with a push notification, or phone call etc. depending on user preference.

After authenticating with Azure AD and MFA, access to the on-premises application is granted.

To achieve single sign-on to the Citrix Director application and other applications, we can turn Azure AD into a password vault using the Password-based Sign-on single sign-on method. When you configure this method, users have to sign in to the on-premises application once. After that, Azure AD stores the sign-in information and automatically provides it to the application when your users access it remotely. Azure AD best estimates the username and password fields of your HTML web application from where it captures sign-in information, however you may need to manually help Azure detect the correct field names. To help you do this, install the My Apps Secure Sign-in Extension to Firefox, or your preferred browser (IE, Edge, Chrome).

Now on the Azure portal temporarily set the application pre-authentication method to Passthrough.

Click on the Single sign-on tab and set Single Sign-on Mode to Password-based Sign-on.

Scroll to the bottom and click Configure Password Single Sign-on Settings.

Click Manually detect sign-in fields -> Capture sign-in fields.

A new tab will open, and then another tab will open and direct you to your on-premises application. As you enter your username and password, the fields should be surrounded with a red outline.

Upon successful authentication, a pop-up box will appear. Click OK.

The on-premises application window will disappear, and you will be returned to the metadata capture is currently in progress page which will show a result of Metadata has been updated for the application.

Return to the Azure portal, check Ok, I was able to sign-in to the app successfully and click OK.

By clicking on Advanced: View and edit sign in field labels you will see the updated names of the captured sign-in fields. You are now ready to test the solution.

If Edge is your corporate remote browser of choice, for example maybe you issue corporate laptops to be used remotely, your users can download the My Apps Secure Sign-in Extension from the Microsoft Store.

The next time they launch Edge, the browser will ask do you want to turn on the My Apps extension. Click Turn it on.

The extension will show as a blue and white box icon to the top right of the browser window. Click it, then click Sign in to get started to sign in to the Azure AD access panel.

Enter Azure credentials of a user account that has been assigned the right to access the on-premises application via Application Proxy.

Upon successful sign in, click My apps.

Click the vertical ellipsis next to the on-premises application and click Update credentials.

Enter your credentials used to authenticate with the application and click Sign in.

On future visits to the application, Azure passes the saved credentials to the application for single sign-on. Using this method is helpful for applications that for example do not use Integrated Windows Authentication, and we do not want our users to authenticate twice, firstly with Azure AD and secondly with the on-premises application.

Configure Application Proxy with KCD single sign-on:

If your applications do use Integrated Windows Authentication, we can apply single sign-on to our sessions using the Integrated Windows Authentication single sign-on method.

Return to the Azure portal and edit the application we have been working on previously. Click on the Application proxy tab and make sure Pre-Authentication is set to Azure Active Directory.

Switch to the Single sign-on tab and set

• Single Sign-on Mode to Integrated Windows Authentication.
• Internal Application SPN to the SPN you will create in Active Directory for your web application.
• Delegation Login Identity to On-premises SAM account name.

Click Save.

Create an SPN for your web application as below. The value you specify here matches the same one you have specified in Azure.

Open Active Directory, locate and double-click on your Application Proxy Connector server. Click on the Delegation tab. Click Trust this computer for delegation to specified services only -> Use any authentication protocol -> Add and add the SPN you just created to the list. Click OK.

Browse to the application via the external URL. Authenticate with Azure AD first (pre-authentication).

The Application Proxy Connector server will then impersonate you to obtain a Kerberos ticket on your behalf and use that to authenticate you with the on-premises application.