Big changes have occurred in the Kerberos authentication space with the introduction of Windows Server 2012. For this blog I’ll focus on Kerberos Constrained Delegation and Protocol Transition, highlighting what Server 2012 brings to the table, and how the changes can be used to improve security in a typical deployment scenario.
Kerberos Delegation Explained
To start, a high level explanation of Kerberos delegation – it enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account.
Kerberos Constrained Delegation
Kerberos Delegation, whilst useful, is inherently unsecure as there are no constraints applied to what services can be accessed via the impersonating account. The impersonating account could access multiple services under the context of the impersonated account and not just nominated services on specific servers. Enter Kerberos Constrained Delegation (KCD). Introduced in Windows Server 2003, KCD provides a mechanism to restrict what can be accessed by the impersonating account.
KCD operates at the service level, so that selected services on a server can be granted for access by the impersonating account, whilst other services on the same server, or services on other servers are denied for access.
Before Windows Server 2012, when configuring KCD, the Service Principal Name (SPN) of the account hosting the resource to be accessed via delegation was registered to the msDS-AllowedToDelegateTo attribute of the impersonating account. The SPN contains a reference to a service on the resource server (service type) and the host name of the resource server. For a full list of service types, see the TechNet Reference. This provided a listing of services on servers that an impersonating account was allowed to access whilst performing delegation.
The use of KCD before Windows Server 2012 presented three major issues:
-
Delegation is controlled via modification of the impersonating (service) account and not the account of the resource server. This potentially creates a scenario where the resource owner has no control or knowledge of accounts that have been configured for delegation to services on his or her server.
-
Registration of KCD SPNs requires Domain Admin rights, often preventing delegation of KCD configuration to resource administrators.
- KCD cannot cross an Active Directory domain or forest boundary. This limitation required that the impersonating (service) account, the impersonated (user) account and the account of the resource server all resided in the same domain. This precluded the use of KCD for typical extranet scenarios where a web server would reside in an extranet or DMZ domain, with a SQL or other resource server residing in an internal domain. Using Kerberos Protocol Transition (KPT) in conjunction with KCD helped to address this issue somewhat. See “KCD Across Domain Boundaries” later in this blog post for info on KPT.
Kerberos Constrained Delegation in Windows Server 2012
Resource Based Constrained Delegation
So now that the background is covered, on to the star of the show – Windows Server 2012. New in Server 2012 is Resource Based Constrained Delegation. As the name suggests, KCD can now be configured by modification of the account of the resource that the impersonating account will access and not the impersonating account itself.
This is a fundamental change in the way KCD is configured. Under Windows Server 2012 instead of registering SPNs for resources that an impersonating account can access against the msDS-AllowedToDelegateTo attribute of the impersonating account, a list of Active Directory accounts allowed for delegation can now be stored against the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the resource server’s computer account or in the service account under which services run on the resource server. Standard SPN KCD can still be used under Server 2012, but new functionality introduced with Resource Based Constrained Delegation will not be available – more on that later.
This change empowers administrators of resource servers with control over what accounts are allowed to impersonate other accounts when accessing their resources, and also provides for easy confirmation of all accounts configured for impersonation.
Resource Based Constrained Delegation is configured by using PowerShell. For resources running under the context of a computer account, use Set-ADComputer. Use Set-ADUser in instances where a resource is running under a service account, which is preferable. The command sets a list of security principals (accounts) that the resource account will trust for delegation.
For example, a solution consists of a front end web site on a server called Webserver1 with a web site running under the context of a service account named SVC_Web. A back end server called ResourceServer1 hosts a database hosting data consumed by the web site via Kerberos Delegation, the database is running under the context of a service account called SVC_Resource. To configure Resource Based Constrained Delegation you would assign the SVC_Web as an account permitted to delegate to SVC_Resource. This is done as follows:
$user1 = Get-ADUser -Identity SVC_Web
Set-ADUser SVC_Resource -PrincipalsAllowedToDelegateToAccount $user1
If the front end web site and the database is running under the context of the computer account (not recommended) then use Get-ADComputer and Set-ADComputer as follows:
$computer1 = Get-ADComputer -Identity WebServer1
Set-ADComputer ResourceServer1 -PrincipalsAllowedToDelegateToAccount $computer1
To query the existing set of principals configured for delegation for a specific resource account, use the following PowerShell command:
Get-ADUser SVC_Web -Properties PrincipalsAllowedToDelegateToAccount
Or, for the computer context:
Get-ADComputer ResourceServer1 -Properties PrincipalsAllowedToDelegateToAccount
KCD Across Domain Boundaries
Also changed in Windows Server 2012 is that KCD now has the ability to function across domain and forest boundaries. Before Windows Server 2012 KCD would only function if the impersonating account, the impersonated account, and the resource being accessed all resided within a domain boundary. To explain what has changed and why it is such a big deal we’ll need to dig under the hood of the Kerberos protocol.
The Kerberos extension that enables KCD is the Service for User to Proxy (S4U2Proxy) extension. To function across domain boundaries a Kerberos referral is used. These referrals point Kerberos ticket requests for accounts in other domains to the domain controllers hosting those accounts. Previous to Server 2012, Domain Controllers were unable to issue referrals for S4U2Proxy ticket requests.
Previous to Server 2012, combining KCD (S4U2Proxy) with another Kerberos extension called Kerberos Protocol Transition or Service for User to Self (S4U2Self) removed the requirement for the impersonated (user) account to reside in the same domain or forest as the impersonating (service) account and the resource being accessed. The impersonating (service) account and the resource being accessed must still have resided in the same domain however. Also two-way trust was required between the domain/forest containing the resource and the account domain/forest containing the impersonated account.
S4U2Self functioned across domain and forest boundaries for pre-Server 2012 servers because S4U2Self ticket referrals requests were supported. Below shows how S4U2Self and S4U2Proxy combined provided limited KCD functionality for accounts across a domain boundary.
Notice that the S4U2Proxy (Constrained Delegation) ticket request, issuance and use to access the resource all occur within the confines of a domain boundary. The S4U2Self extension (Protocol Transition) is used initially for the impersonating (service) account to retrieve a service ticket for the impersonated (user) account. S4U2Proxy referral between domains is not required.
Implementing Resource Based Constrained Delegation
Under Server 2012, to support KCD (S4U2Proxy) across a domain or forest boundary, Resource Based Constrained Delegation must be used. As previous Windows Server versions do not take into consideration the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, both the front end and back end servers for the service must be Server 2012. Also there must be at least one Server 2012 domain controller in each domain to process S4U2Proxy referral. If Server 2008 or Server 2008 R2 Domain Controllers exist in the referral path Hotfix 2665790 must be deployed to those Domain Controllers.
When configuring Resource Based Constrained Delegation across the domain boundary Set-ADComputer or Set-ADUser must reference the fully qualified domain name of a Domain Controller hosting the impersonating account. Example below with a Domain Controller called ExtranetDC in the Extranet.Local domain hosting the SVC_Web account for a front end web server:
$user1 = Get-ADUser -identity SVC_Web -server ExtranetDC.Extranet.Local
Set-ADUser SVC_Resource -PrincipalsAllowedToDelegateToAccount $user1
Note, it is not possible to configure both user and computer accounts for delegation as shown below:
$user1 = Get-ADuser -Identity SVC_Web
$computer1 = Get-ADComputer -Identity WebServer1
Set-ADUser SVC_Resource -PrincipalsAllowedToDelegateToAccount $user1, $computer1
The result of the above is an error of “An AD Property Value Collection may only contain values of the same type”.
TIP: You can add both user and computer accounts by using Get-ADObject instead of Get-ADUser and Get-ADComputer, like so:
$user1 = get-adobject -filter {(cn -eq “Excel Services”) -and (ObjectClass -eq “user”)}
$comp = get-adobject -filter {(cn -eq “MYSERVER”) -and (ObjectClass -eq “computer”)}
then run your set-aduser
source: https://blog.kloud.com.au/2013/07/11/kerberos-constrained-delegation/