This article was originally published for Windows IT Pro Magazine, on March 19, 2013.

In How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 1, I provided an introduction to resource-based Kerberos constrained delegation, included in Windows Server 2012. I also described the targeted scenarios for which resource-based Kerberos constrained delegation is designed, and provided a brief overview of the technology. Now, in part 2, I want to expand on how resource-based Kerberos constrained delegation works by providing more technical depth as well as a message flow walk through.

Diving into the Technical Depths

Constrained delegation lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. To understand this behavior, it’s best to analyze authentication flow as two separate events: the client authenticating to the front-end service, and the front-end service authenticating to the back-end service.

Client to front-end authentication

Authentication from the Kerberos client to the front-end server doesn’t change when you use resource-based constrained delegation. The Kerberos client requests a service ticket from its local Key Distribution Center (KDC) for the target service principal name (SPN).

If the target service resides in the same domain, the KDC issues a service ticket and session key to the Kerberos client in a TGS-REP message. If the target service resides outside the current domain, the KDC issues a Ticket Granting Ticket (TGT) referral ticket using the inter-realm session key of the trust in a TGS-REP. The Kerberos client chases the referral as it normally does when authenticating to a resource outside of its domain (across a trust).

Front-end to back-end authentication

Authentication from the front end (Service-for-User—S4U—client) to the back end is different when using resource-based constrained delegation. Resource-based constrained delegation requires that the computer running the front-end service use Server 2012 because services running on versions of Windows earlier than Windows 8and Server 2012 don’t support resource-based constrained delegation; earlier versions of Windows don’t chase referrals from the Service-for-User-to-Proxy (S4U2Proxy) TGS-REQ across the domain boundary.

During front-end to back-end authentication, the front-end service asks a KDC for a service ticket on behalf of another user. This exchange uses the Kerberos extension S4U2Proxy (aka constrained delegation). The Kerberos client successfully presents a service ticket to the front-end service. The front-end service impersonates the identity presented in the service ticket and attempts to authenticate to the back-end service by way of SPN. This authentication attempt results in the front-end service creating an S4U2Proxy TGS-REQ to the KDC in the front-end server’s domain. This request includes the target SPN, which resides in another domain, and the service ticket used to authenticate to the front-end service. The TGS-REP returned depends on the answering KDC.

Front-End KDC Behavior

Constrained delegation, at the micro level, involves many decisions and exchanges of information, beginning with the client contacting the front-end KDC.

KDC earlier than Server 2012

A KDC earlier than Server 2012 receiving an S4U2Proxy TGS-REQ for a target SPN outside of its domain returns the Kerberos error KDC_ERR_BADOPTION (13) in a TGS-REP to the front-end service. This response results from an inability of a KDC earlier than Server 2012 to provide a TGT referral for an S4U2Proxy TGT_REQ for a target SPN residing outside its own domain. Constrained delegation prior to Server 2012 wasn’t supported across domain and forest trusts.

Windows Server 2012 KDC

A Server 2012 KDC receiving the S4U2Proxy TGS-REQ determines whether the target SPN resides in its domain. In this scenario, the target SPN resides in another domain. Therefore, the Server 2012 KDC—aware that it supports resource-based constrained delegation—provides a referral TGT to the front-end service in a TGS-REP.

Front-End Service TGS-REP Behavior

The front-end service receives a TGS-REP from the KDC. The next action the front-end service performs depends on the KDC response from the S4U2Proxy TGS-REP.

TGS-REP from KDC earlier than Server 2012

The front-end service receives a TGS-REP in response to the S4U2Proxy TGS-REQ. The response from the KDC is a Kerberos ERROR – KDC_ERR_BADOPTION (13). The front-end service runs on a Server 2012 member server. Server 2012 is a cross-domain constrained delegation–aware Kerberos client; therefore, when the front-end service receives an S4U2Proxy TGS-REP with KDC_ERR_BADOPTION (13), it knows that it might have contacted a KDC that doesn’t support constrained delegation across domains. In response, the Server 2012 member server running the front-end service attempts to locate a Server 2012 domain controller (DC). After locating a Server 2012 DC, the member server running the front-end service sends the same S4U2Proxy TGS-REQ to the Server 2012 DC.

TGS-REP from Server 2012 KDC

The front-end service receives a TGS-REP in response to the S4U2Proxy TGS-REQ. The response from the KDC is a TGT referral to the domain that’s responsible for providing authentication for the target SPN. Server 2012 is a cross-domain constrained delegation–aware Kerberos client. The member server running the front-end service chases the referral to the domain listed in the TGT referral. (Important: When traversing trusts using resource-based constrained delegation, the computer must authenticate to traverse the trust. Therefore, it is expected for the computer to perform a TGS-REQ for a TGT in each domain as well as the first S4U2Proxy TGS-REQ performed by the front-end service.) The TGS-REQ referral process continues until it locates a Server 2012 DC in the domain that hosts the targeted SPN.

Back-End KDC Behavior

The back-end KDC receives an S4U2Proxy TGS-REQ from the front-end service. The TGS-REQ includes an evidentiary ticket, which is the service ticket from the initial authentication to the front-end service as well as the inter-realm referral TGT received from an earlier exchange with a KDC.

The KDC first determines whether the target SPN resides in its domain. If it doesn’t, the KDC creates a referral TGS-REP, as previously described. Alternatively, the target SPN might exist in the current domain. In this case, the KDC can provide a service ticket for the targeted service and can respond directly rather than with a referral to another domain. The KDC then reads the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the security principal registered for the targeted back-end SPN. If the attribute is empty, the Server 2012 DC will use traditional constrained delegation logic (msDS-AllowedToDelegateTo [A2D2]). If the msDS-AllowedToActOnBehalfOfOtherIdentity has a value, the KDC impersonates the security principal under which the front-end service runs and performs an access check using the security descriptor stored in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

An access check failure causes the KDC to use traditional constrained delegation logic (A2D2) to determine whether constrained delegation is allowed. A successful access check means the back-end service allows the front-end service to request tickets on behalf of other security principals that are used for authentication to the back-end service. The KDC builds a service ticket for the back-end service using the client name from the evidentiary ticket and returns the service ticket and session key for the front-end service to use to authenticate to the back-end service as the user.

KDC Behavior With and Without Traditional Constrained Delegation

If the back-end server is configured using traditional constrained delegation (msDS-AllowedToDelegateTo—A2D2), which must reside in the same domain, then a Server 2012 KDC or a KDC running an earlier version of Windows can be used for authentication.

Behavior for non-Server 2012 KDCs

KDCs running earlier versions of Windows behave the same with traditional constrained delegation. If A2D2 isn’t configured, and the back-end service resides in the current domain, the KDC returns KDC_ERR_BADOPTION with a sub status of STATUS_NOT_FOUND. If A2D2 isn’t configured, and the back-end service resides in another domain, the KDC returns KDC_ERR_BADOPTION with a sub status of STATUS_NOT_FOUND.

If A2D2 is configured, and the back-end service is not a value in the attribute, and the back-end service resides in the current domain, the KDC returns KDC_ERR_BADOPTION with a sub status of STATUS_NOT_FOUND. If the back-end service resides in another domain, the KDC returns KRB-ERR-POLICY with a sub status of STATUS_CROSSREALM_DELEGATION_FAILURE.

Behavior for Server 2012 KDCs

If A2D2 isn’t configured, and the back-end service resides in another domain, the Server 2012 KDC returns a referral TGT. If A2D2 isn’t configured, and the back-end service resides in the current domain, and resource-based constrained delegation isn’t configured on the principal object, the Server 2012 KDC returns KDC_ERR_BADOPTION with a sub status of STATUS_NOT_FOUND.

If A2D2 is configured, and the back-end SPN isn’t a value within the attribute, the back-end service resides in the current domain, and resource-based constrained delegation isn’t configured on the principal object, the Server 2012 KDC returns KDC_ERR_BADOPTION with a sub status of STATUS_NOT_FOUND. If the back-end SPN resides in another domain, the Server 2012 KDC returns a referral TGT.

Message Flow Walk through

Now that all the academic explanation is out of the way, here’s a walk through of the message flow to help you visualize how all of this works together. Don’t worry if you don’t understand all of it the first time! It’s a lot to take in, and the changes are a shift in thinking from how delegation used to work to how it can work in Server 2012. When teaching this material, I explain to engineers that if they think it’s too simple, then they’re catching on! The management of it is simple, but the inner workings require a little more thought before they make sense.

To reduce the number of visible steps to those included in the resource-based constrained delegation message exchange, successful client-to-front-end authentication is assumed in Figure 1.

Figure 1.

1. The front-end service sends an S4U2Proxy TGS-REQ to the KDC in root.fabrikam.com, requesting a service ticket for the back-end service on behalf of the user. The TGS-REQ includes the front-end service TGT; a forwardable client service ticket for the front-end service, or an evidentiary ticket; and the KDC option cname-in-addl-tkt. If the KDC in root.fabrikam.com returns KRB-ERR-BADOPTION, the front-end service locates a Server 2012 DC and retries the TGS-REQ.
2. The KDC in root.fabrikam.com determines that the back-end service doesn’t reside in root.fabrikam.com and returns a referral TGT for corp.contoso.com to the front-end service on behalf of the user. The cname field in the ticket uses the name of the front-end service, and the crealm field uses the name of the front-end service domain.
3. The front-end service must authenticate to the back-end domain to chase the referral on behalf of the user. The front-end service sends a TGS-REQ, as itself, to the KDC in the root.fabrikam.com to request a service ticket for the back-end service.
4. The KDC in root.fabrikam.com determines that the back-end service isn’t in root.fabrikam.com and returns a TGS-REP that includes a referral TGT to corp.contoso.com.
5. The front-end service sends a TGS-REQ, for itself, requesting a service ticket for the back-end service.
6. The KDC in corp.contoso.com sends a TGS-REP that includes a service ticket for the back-end service that is used by the front-end service.
7. The front-end service locates a Server 2012 DC in corp.contoso.com and sends an S4U2Proxy TGS-REQ to the KDC in corp.contoso.com, requesting a service ticket for the back-end service on behalf of the user present in the evidentiary ticket. The request includes a front-end service referral TGT, additional tickets (S4U referral TGT), and the KDC option cname-in-addl-tkt.
8. The KDC in corp.contoso.com retrieves account information from AD using SamIGetUserLogonInformation, impersonates the front-end service, and performs an access check using the security descriptor in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. If the access check fails, the KDC returns KRB-ERR-BADOPTION; otherwise, the KDC returns a service ticket in a TGS-REP)
9. The front-end service presents the service ticket requested on behalf of the user to the back-end service by sending an AP-REQ.
10. The back-end service returns an AP-REP if mutual authentication is required.

Protocol Transition (S4U2Self)

The protocol transition extension to Kerberos doesn’t require a Server 2012 DC. Therefore, Windows 8 and Server 2012 S4U clients don’t attempt to locate a Server 2012 DC to service these requests.

Front-end servers need to locate Server 2012 DCs when the initial S4U2Proxy TGS-REQ returns a KRB-ERR-BADOPTION or KRB-ERR-POLICY. To accomplish this, the S4U client uses the public directory service API DsGetDCName, which makes an RPC call to a DC. The specific call includes the DS_DIRECTORY_SERVICE_8_REQUIRED flag, which indicates the API need only return Server 2012 DCs.

This wraps up resource-based constrained delegation, and now you can see how it eases the administrative pains of constrained delegation. Server 2012 simplifies its configuration. It removes the appearance of registering duplicate SPNs on multiple front-end computers, returns the point management to the resource owner rather than the owner of the front-end service and the domain administrator. Also, with resource-based constrained delegation, you can now use constrained delegation across trusted domains and trusted forests—a feature that has been a huge request from customers for a long time.

–Mike Stephens

Originally published for Windows IT Pro Magazine, February 22, 2013

Let’s talk authentication—specifically, Kerberos constrained delegation. But first, if you’re new to Kerberos or need a quick refresher, I would suggest that you read the Ask the Directory Services Team blog posts “Kerberos for the Busy Admin” and “Understanding Kerberos Double Hop” to get up to speed on the terminology and concepts contained throughout this article. Part 1 of this article describes the benefits of using Kerberos constrained delegation with Windows Server 2012 over earlier versions of Windows Server. Part 2 will provide a technical walk through of how Kerberos constrained delegation works in Server 2012.

What Is Constrained Delegation?

Constrained delegation lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. A common example of constrained delegation is the web-browser-to-IIS-to-SQL-Server scenario. In this scenario, a user navigates to a web-based reports server hosted on Microsoft IIS, which retrieves data using an authenticated connection to a Microsoft SQL Server system. The IIS server needs to authenticate to the SQL Server system on behalf of the user. Through Kerberos delegation, the IIS server (i.e., the front-end service) can request a service ticket for any service (i.e., back-end service)—not just SQL Server—on behalf of the user. This means that the IIS server can essentially authenticate on behalf of the user to SQL Server, a file share, or a web service. Using constrained delegation, you can limit the IIS server (the front end) so that it can authenticate the user only to SQL Server (the back end) and no other service or application.

Kerberos constrained delegation has been a part of the OS since Windows Server 2003. It requires you to configure an allow list of service principal names (SPNs) on user or computer objects in Active Directory (AD). You add the list of SPNs that represent the back-end services to which a front-end service is allowed to request tickets on behalf of the user to the ms-DS-Allowed-To-Delegate-To attribute of the principal under which the application or service on the front-end server runs. In the previous example, the front-end service is IIS and the back-end service is SQL Server. To constrain the delegation for IIS, you would add SPNs for the SQL Server instances running on the SQL Server system to the ms-DS-Allowed-To-Delegate-To attribute on the IIS computer account in AD—or the user account running the IIS application pool. This model constrains the front-end service to only request service tickets that are listed in the ms-DS-Allowed-To-Delegate-To attribute. The downside of this delegation model is that it relies heavily on SPNs.

Service Principal Names

SPNs are difficult to manage. Although they’re simple in concept, SPNs can cause a significant amount of frustration, stemming from unique constraints associated with using them.  Kerberos uses SPNs to identify the security principal responsible for running an application or service. This enables the Key Distribution Center (KDC) to encrypt tickets and keys with the correct hash so that the security principal (running the service or application) can decrypt the service ticket upon receiving the AP_REQ. This design requires that SPNs registered on security principals be unique for the AD forest. An SPN registered on multiple security principals will cause authentication to fail.

Constrained delegation appears to contradict the basic rule of registering a duplicate SPN; however, this is only in appearance. The KDC doesn’t look at the ms-DS-Allowed-To-Delegate-To attribute when trying to map an SPN to a security principal. Therefore, the unique SPN requirement is limited only to values in the servicePrincipalName attribute. To constrain the delegation of a service or application, you must list the service’s SPNs on the security principal that runs the application on the front-end server.  Managing the number of SPNs, knowing when and where to register them, and avoiding duplicates is cumbersome. This makes constrained delegation difficult to implement, maintain, and troubleshoot

Point of Delegation

Constrained delegation is a model that controls delegation on the front-end server. Most delegation models manage the point of delegation closest to the resource (i.e., on the back end). Implementing delegation on the front end removes control from the resource administrator and places it on the administrator of the front-end server (and application). This model prevents the resource administrator from managing access to the resource. The current model requires domain administrative privileges to modify the ms-DS-Allowed-To-Delegate-To attribute, thus adding more administrative overhead to the management of constrained delegation.

Scope of Delegation

Scope of delegation refers to the limit to which the delegation extends from the front-end server to the back-end server. The current constrained delegation model scope is limited to the domain, meaning that the security principal under which the application or service runs can forward constrained delegated tickets only to an application or service running under a security principal in the same domain. You can’t use constrained delegation across domain or forest trusts.

What Server 2012 Brings

Windows Server 2012 introduces a new kind of Kerberos constrained delegation that addresses many of the shortcomings that exist with the previous constrained delegation model. The new implementation of constrained delegation removes the dependencies on SPNs for delegation configuration, removes the need for domain administrative privileges, enables the resource administrator to own the delegation experience, and increases the scope of delegation.

Constrained delegation in Server 2012 introduces the concept of controlling delegation of service tickets using a security descriptor rather than an allow list of SPNs. This change simplifies delegation by enabling the resource to determine which security principals are allowed to request tickets on behalf of another user.

Figure 1 shows a sample scenario. A server in Domain A runs an IIS application. The security principal under which the IIS application’s AppPool runs has the SPNs registered for the front-end service or application (HTTP/app1.contoso.com). These SPNs allow the user to authenticate to the front-end server using normal Kerberos authentication.

Figure 1.

The application retrieves data from a back-end server in Domain B running SQL Server. The security principal running the SQL Server service has the SPNs registered for SQL Server and SQL Server instances. Again, this configuration is normal to enable Kerberos authentication. The KDC in the domain hosting the security principal running SQL Server receives a Service-for-User-to-Proxy (S4U2Proxy) Ticket Granting Service (TGS) request from the IIS server on behalf of another user. The KDC reads the security descriptor stored in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the security principal running the SQL Server service and performs an access check using the identity under which the IIS Application Pool runs. A successful access check allows the authentication process to continue, whereas an unsuccessful access check fails the authentication attempt.

Resource-based constrained delegation functions correctly regardless of domain functional level and number of domain controllers (DCs) running a version of Windows Server prior to Server 2012, provided you have at least one Server 2012 DC in the same domain as the front-end server and one Server 2012 DC in the domain hosting the back-end server. When the domain is a hybrid domain (both Server 2012 DCs and DCs running an earlier version of Windows Server), then Windows 8 and Windows 2012 computers ensure they use a Server 2012 DC to use resource-based constrained delegation by deliberately locating a Server 2012 DC.

Requirements

The new implementation of Kerberos constrained delegation has the following requirements:

•  Server 2012 KDCs must reside in the front-end account domain
•  Server 2012 KDCs must reside in the back-end account domain
•  The front-end server must run Server 2012

Server 2012 KDCs are required for this feature because these are the only KDCs that know how to return referred S4U2Proxy requests and use the new msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the service account. The front-end server requires Server 2012 because the version of Kerberos on these servers understands that it must chase S4U2Proxy referrals to trusted domains and forests.

Management

You manage Server 2012 Kerberos constrained delegation using Windows PowerShell. Use the following Windows PowerShell cmdlets to manage constrained delegation. Typically, you’ll want to use the Get-ADUser, Get-ADComputer, or Get-ADServiceAccount of the principal running the front-end service and pass that principal object as the argument value to the -PrincipalsAllowedToDelegateToAccount argument.

Set-ADComputer computerName -PrincipalsAllowedToDelegateToAccount principal1, principal2, ...
Set-ADUser userName -PrincipalsAllowedToDelegateToAccount principal1, principal2, ...
Set-ADServiceAccount serviceAccountName -PrincipalsAllowedToDelegateToAccount principal1, principal2, ...
Get-ADComputer computerName -Property PrincipalsAllowedToDelegateToAccount
Get-ADUser userName -Property PrincipalsAllowedToDelegateToAccount
Get-ADServiceAccount serviceName -Property PrincipalsAllowedToDelegateToAccount

Stay Tuned for More

This article identifies the challenges IT pros face when implementing Kerberos constrained delegation. Server 2012 provides a compelling answer to these problems by introducing resource-based Kerberos constrained delegation. In Part 2 of this series, I’ll provide a more in-depth analysis of how resource-based constrained delegation works and look at the flow of authentication that’s exchanged between computers running Server 2012.

–Mike Stephens