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 walkthrough.
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.
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 Walkthrough
Now that all the academic explanation is out of the way, here's a walkthrough 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.
- 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.
- 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.
- 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.
- 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.
- The front-end service sends a TGS-REQ, for itself, requesting a service ticket for the back-end service.
- 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.
- 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.
- 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)
- The front-end service presents the service ticket requested on behalf of the user to the back-end service by sending an AP-REQ.
- 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.
You Asked for It!
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.
