At the end of 2014, Microsoft released some new Azure AD features. One of these features is the added support for Kerberos Constrained Delegation within the Azure AD Application Proxy. This introduces the capability to publish on premises Windows Integrated Applications for external access. This is extremely useful to publish applications like Outlook Web Access or any other application using Kerberos as the default (internal) authentication method.
Kerberos Constrained Delegation is used to give the Azure AD Application Proxy connector permission to request and receive tickets from AD on the user’s behalf. In other words, the connector impersonates the authenticating user to retrieve a ticket from AD. To get a better understanding, an overview is given which describes the steps in the process of authenticating the user.
1. User accesses the Application through the Application Proxy and will be directed to the Azure AD logon page to authenticate.
2. After a successful logon, a token is generated and send to the user.
3. The user will now send the token to the Application Proxy which will retrieve the UPN and SPN out of the token and direct the request to the connector.
4. The connector impersonates the user to request a Kerberos ticket which can be used for internal (Windows) authentication. (Kerberos Constrained Delegation)
5. A Kerberos ticket is retrieved from AD.
6. The retrieved ticket is send to the application server where it is being verified.
7. The response will be send through the Application Proxy to the end user.
In the rest of this blog I will go over the configuration to publish such an application including the steps to configure Kerberos Constrained Delegation.
The general steps to configure the Azure AD Application Proxy and installing the connector can be found in one of my earlier blogs. Also make sure the UPN of the user accounts in the local AD are equal to the ones in the Azure AD. You can accomplish this by syncing your identities to Azure AD using the Azure AD Sync tool. Do not forget to create a custom domain name within Azure AD, which is equal to the domain FQDN of your local domain environment, before you start configuring and syncing your identities.
When you have finished the default configuration it is time to configure an application using Kerberos Constrained Delegation.
First we configure the Azure AD application to make use of pre-authentication. In the configuration settings now select the new option Integrated Windows Authentication as the Internal Authentication Method.
After selecting this option, another property field will appear. This is the Service Principal Name (SPN), which is being used by the connector for delegation. Fill in the SPN using the following format: http/”nameoftheresourceserver”.
After this configuration has been saved, we now need to make sure the Kerberos Constrained Delegation is being set. For this we make use of Resource Based Constrained Delegation. This is a feature which comes with Windows Server 2012 and simplifies the configuration of KCD. Instead of registering multiple SPNs for resources that an impersonating account can access, a list of Active Directory accounts can be now be stored in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the resource server’s service account or computer account.
Resource Based Constrained Delegation can all be configured by using the standard Active Directory PowerShell cmdlets:
Set-ADComputer “resource computer” -PrincipalsAllowedToDelegateToAccount “cn=connectorserver, cn=computers, dc=contonso, dc=com”
Set-ADUser “resource service account” -PrincipalsAllowedToDelegateToAccount “cn=connectorserver, cn=computers, dc=contonso, dc=com
This last option is a requirement when you have your webserver instances configured in a cluster.
The final step is to check if your webserver has Windows Authentication configured as the authentication method for your website.
Afterwards, you can connect and login to your Windows Integrated Application by using Azure AD and the Application Proxy:
That’s it for now! Stay tuned for more Identity and Cloud news.