What you need to be successful:

1. A valid Azure subscription.

2. An Azure AD directory - either synchronized with an on-premises directory or a cloud-only directory.

3. An Azure AD Basic or Premium license is required to use the Azure AD Application Proxy.

4. Azure AD Domain Services must be enabled for the Azure AD directory. See the Getting Started guide if you need to enable and configure Azure ADDS.

What is the Azure Active Directory (AD) Application Proxy?

Azure Active Directory (AD) Application Proxy helps you support remote workers by publishing on-premises applications to be accessed over the internet. The Azure AD Application Proxy provides single sign-on (SSO) and secure remote access for web applications hosted on-premises.

What kind of applications work with Application Proxy?

With Azure AD Application Proxy you can access different types of on-premise/internal applications:

• Web applications that use Integrated Windows Authentication for authentication

• Web applications that use form-based or header-based access

• Web APIs that you want to expose to applications on different devices

• Applications hosted behind a Remote Desktop Gateway

• Client apps that are integrated with the Active Directory Authentication Library (ADAL)

How does Application Proxy work?

There are two components that you need to configure to make Application Proxy work: a connector and an external endpoint.

The connector is a lightweight agent that sits on a Windows Server inside your network. It only uses outbound connections, so you do not have to open any inbound ports or put anything in the DMZ.

The connectors are stateless and pull information from the cloud as necessary.

The external endpoint is how your users reach your applications while outside of your network. They can either go directly to an external URL that you determine, or they can access the application through the MyApps portal. When users go to one of these endpoints, they authenticate in Azure AD and then are routed through the connector to the on-premises application.

So, you want to get down to it… :

Task 1 - Enable Azure AD Application Proxy for your Azure AD directory

1. Sign in as an administrator in the Azure portal.

2. Click Azure Active Directory to bring up the directory overview. Click Enterprise applications.

3. Click Application proxy. If you do not have an Azure AD Basic or Azure AD Premium subscription, you see an option to enable a trial. To download the connector, click the Download Connector button. To enable the application proxy, click the Enable application proxy button and click Yes.

4. On the download page, accept the license terms and privacy agreement and click the Download button.

5. When you click the Enable the application proxy button, click ‘Yes’ after reading the message.

Task 2 - Setup domain-joined Windows servers to deploy the Azure AD Application Proxy connector to

You need domain-joined Windows Server virtual machines on which you can install the Azure AD Application Proxy connector. Depending on the authentication workload associated with the applications, you may choose to provision multiple servers on which the connector is installed.

Provision the connector servers on the same virtual network (or a connected/peered virtual network), in which you have enabled your Azure AD Domain Services managed domain. The servers hosting the applications you publish via the Application Proxy need to be installed on the same Azure virtual network as well.

To setup connector servers, follow the tasks outlined in this article: Join a Windows virtual machine to a managed domain. Task 3 - Install and register the Azure AD Application Proxy Connector

1. Copy the connector installation package to the VM on which you install the Azure AD Web Application Proxy connector.

2. Run AADApplicationProxyConnectorInstaller.exe on the virtual machine. Accept the software license terms.

During installation, you are prompted to register the connector with the Application Proxy of your Azure AD directory.

• Provide your Azure AD global administrator credentials. Your global administrator tenant may be different from your Microsoft Azure credentials.

• The administrator account used to register the connector must belong to the same directory where you enabled the Application Proxy service. For example, if the tenant domain is itprotvlab.onmicrosoft.com, the admin should be admin@ itprotvlab.onmicrosoft.com or any other valid alias on that domain.

• If IE Enhanced Security Configuration is turned on for the server where you are installing the connector, the registration screen might be blocked. To allow access, follow the instructions in the error message. Make sure that Internet Explorer Enhanced Security is off.

• If connector registration does not succeed, see Troubleshoot Application Proxy.

You should see the newly installed connector listed on the Application proxy page in your Azure AD directory.

“But wait, there’s more … you still need to handle Kerberos Constrained Delegation (KCD). KCD you say? What the heck is KCD?”

KCD is used when an application needs to access resources in the context of the user.

Kerberos delegation enables an account to impersonate another security principal (such as a user) to access resources. Consider a web application that accesses a back-end web API in the context of a user. In this example, the web application (running in the context of a service account or a computer/machine account) impersonates the user when accessing the resource (back-end web API). Kerberos delegation is insecure since it does not restrict the resources the impersonating account can access in the context of the user.

Kerberos constrained delegation (KCD) restricts the services/resources to which the specified server can act on the behalf of a user. Traditional KCD requires domain administrator privileges to configure a domain account for a service and it restricts the account to a single domain.

There is only one problem…

On an Azure AD Domain Services managed domain, you do not have domain administrator privileges. Therefore, traditional KCD cannot be configured on a managed domain. This is where Resource-based KCD comes in.

Resource-based KCD

Resource-based KCD is configured using PowerShell. You use the Set-AD Computer or Set-ADUsercmdlets, depending on whether the impersonating account is a computer account or a user account/service account.Task 4 - Enable resource-based Kerberos constrained delegation for the Azure AD Application Proxy connector

Note: You need to be a member of the 'AAD DC Administrators' group, to administer the managed domain using AD PowerShell cmdlets. Make sure that you are logged in as a user in this group when running PowerShell to use the commands below:

Use the Get-ADComputer PowerShell cmdlet to retrieve the settings for the computer on which the Azure AD Application Proxy connector is installed.

$ConnectorComputerAccount = Get-ADComputer -Identity

Then use the Set-ADComputercmdlet to set up resource-based KCD for the resource server.

Set-ADComputer -PrincipalsAllowedToDelegateToAccount $ConnectorComputerAccount

If you have deployed multiple Application Proxy connectors on your managed domain, you need to configure resource-based KCD for all connector instances.

You should be all set, and ready to start using your Azure Application Proxy to allow access to your applications.