Azure AD Application Proxy: Kerberos Constrained Delegation

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.

13-1-2015 20-17-15

 

 

 

 

 

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.

13-1-2015 17-41-45
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”

Or

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:

13-1-2015 18-25-52

That’s it for now! Stay tuned for more Identity and Cloud news.

  • Guy Horn

    Beautiful drawing. I also love the use of set-AdUser above the ADUC GUI. Ten explanation of SPN’s, Delegation and the relationship between them is always difficult. Especially when delegating to service account in the case of web farms.

  • soyroberto

    I have a question, what are the values corresponding to:

    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”

    resource computer is the server where the IIS/onpremise APP is ? and the cn=connectorserver is where the azure proxy connector sits, correct?

    What happens if the connector sits on the same box where the web app is?

    • JurgenvdBroek

      Delegation does not happen when the connector is installed on the resource computer because you are accessing the resource directly. I have not tested this but in theory you would have to install the connector on the resource and the computer must able to retrieve a ticket from the AD.

  • soyroberto

    Also, in my testing the UPN had to match the external URL name, when they were different I got errors saying the Kerberos ticket was empty, only the name not the FQDN in full, so in your example would be, HTTP/claimapp-tsogeti. My federation env was for a Dynamics CRM box and it worked just perfectly

  • BatmanAMA

    Is there a way to configure this to convert the UPN sent into something else? Everything else is leveraging our email attribute from AD, but this doesn’t seem to have any configuration for that.

    • JurgenvdBroek

      At this point in time you are not able to tweak this. Microsoft is working on that feature.

  • Tyler Bithell

    Does this solution require server 2012? Looks like based on your description that 2012 makes it easier to set up KCD, but it doesn’t sound like 2012 is a must. Just want to confirm that.

  • http://techontip.wordpress.com Brajesh Panda

    what I need to do if I have two connector servers, let suppose PROXY01and PROXY02. And I want to publish the a web services running out of IIS01 (http://internal.abc.com). I can add proxy01 and 02’s http/ to delegation tab on IIS01’s computer account. But how do I define both http/proxy01 and http/proxy02 in Azure portal? Or is there something else I have to do?

  • Ramesh Kumar Saini

    76658077