S4U_DELEGATION_INFO and Constrained Delegation
Background
The constrained delegation extension, also called S4Uproxy, is one of the Service for User (S4U) extensions to Kerberos protocol. It allows a service to obtain service tickets to a subset of other services on behalf of the user. The service can then present the tickets to the other service as if the user has obtained the service ticket and sends it to the back end service directly. The details of this extension are documented in [MS-SFU].
S4U_DELEGATION_INFO is an optional data element in PAC, which is embedded in a Kerberos ticket and contains authorization data. It shows the services that have been delegated through for this Kerberos client. For the definition of the structure, see section 2.9 of [MS-PAC]. This structure is mainly used for Kerberos auditing.
In this blog, we will examine the entire process of how this structure is populated and propagated through Kerberos TGS exchanges.
S4U_DELEGATION_INFO in S4UProxy Extension
The following diagram shows the process for a service to obtain a service ticket for another back end service on behalf of the client. This can normally happen when the service is processing the request from the client and it is found that the service needs to access another service on behalf of the client in order to complete the processing.
The entire process can be divided into three phases for better illustration. Please note that Service A and Service B MUST belong to the same realm.
Phase 1:
Before the service A can send out TGS request with S4Uproxy extension, it needs to have the following information on hand.
· The client’s service ticket to service A
This ticket can be obtained using one of the following ways
o The client will send the service ticket to Service A as a part of AP-REQ to Service A. In this way, client has been authenticated to the Service A.
o The Service A can request a service ticket to itself on behalf of the user, using the other S4U extension, S4Uself.
The service ticket must have the forwardable flag set.
· TGT ticket of Service A
The service A has to use AS-REQ to request a TGT ticket for itself. Without TGT ticket, Service A cannot request any service ticket.
Within the PAC of the service ticket, S4U_DELEGATION _INFO may or may not already exist. If the service ticket is for the client itself, then PAC doesn’t contain this structure. Otherwise the structure contains the name of services that the delegation already goes through.
Phase 2:
This is the phase when S4Uproxy extension comes to action. TGS/KDC will process TGS_REQ request with S4Uproxy enabled.
· Server A sends TGS_REQ with the following settings:
o cname-in-addl-tkt (bit 15) is enabled in KdcOptions
o The service ticket acquired in phase 1 is placed in additonal-options field.
o Sname = name of Service B
o Realm = realm of Service B
· TGS/KDC checks AD attribute Allowed-to-Delegate-To of Service A’s account object to see if Service B is in the list of services to which Service A can act as a proxy. If not, the request is rejected.
· TGS creates a new service ticket to be returned (for Service B) with the following settings:
o cName,crealm = cName and cRealm in service ticket in additional-options field(also the same as the original service ticket for Service A)
o Copy the existing S4U_DELEGATION_INFO structure in PAC in service ticket in additional-options field to the PAC of new service ticket.
o Set S4U2ProxyTarget of S4U_DELEGATION_INFO in new PAC to Service B.
o Add Service A to the S4U2TransitedService list of S4U_DELEGATION_INFO, and increment TransListSize by 1.
o The new service ticket for Service B is returned to Service A in KRB_TGS_REP message.
Please note only Service A possesses the session key to access the service ticket, even the service has the cname and crealm of the user.
Phase 3:
Since the Service A has the service ticket for Service B on behalf of the client user, Service A can request the service from Service B as if it is from the user directly in Kerberos AP exchanges.
S4U_DELEGATION_INFO with multiple proxies
The S4UProxy extension could be used through multiple proxy services. The following example shows that Service A request a ticket for Service B on behalf of the user, then in turn, service B request a ticket for Service C on behalf of user and so far so on.
In the service ticket for Service D that Service C receives from KDC/TGS, S4U_DELEGATION_INFO structure in PAC will have the data as follows.
_S4U_DELEGATION_INFO
{ S4U2proxyTarget = Service D
TransitListSize = 3
S4UTransitedServices = {Service A, Service B, Service C}
}
S4U_DELEGATION_INFO and Kerberos Auditing
The constrained delegation is widely used in services such as SQL server, IIS and SharePoint service. Kerberos security auditing for transited services is very important. This is made possible by the S4U_DELEGATION_INFO structure in PAC within service ticket. The following is the information for audit events using S4U_DELEGATION_INFO.
Category : Account Logon
Event Type: Success Audit (Windows Server2000, 2003 and 2008)
Failure Audit (Windows Server 2003 and 2008)
Audit Event ID: 673 TGS_TICKET_REQUEST
Event Info:
· User Name
· User Domain
· Service Name
· Service ID
· Ticket Options
· Ticket Encryption Type
· Client Address
· Failure Code: Kerberos Error Code
· Logon GUID
· Transited Services <--equivilent to S4U_DELEGATION_INFO
Reference
1. Constrained Delegation
https://technet.microsoft.com/en-us/library/cc739587(WS.10).aspx
2. Microsoft Kerberos Tech Reference https://technet2.microsoft.com/windowsserver/en/library/b748fb3f-dbf0-4b01-9b22-be14a8b4ae101033.mspx?mfr=true
3. Document “Troubleshooting Kerberos Errors” https://www.microsoft.com/downloads/details.aspx?FamilyID=7DFEB015-6043-47DB-8238-DC7AF89C93F1