Constrained Delegation when enabled on a service account, allows access only to specified services on specified computers as a user. A typical scenario where constrained delegation is used:

user authenticates to a webservice without using Kerberos and the webservice makes requests to a database server to fetch results based on the user's authorization.

Constraint Delegation can be of 2 types:

• with Kerberos authentication only: Kerberos is used in both Hops
• with protocol transition (also without Kerberos authentication): in this Kerberos is used for authentication only in the second Hop not in the first as it may be that the frontend does not use Kerberos as it is not domain

Constraint Delegation with Protocol Transition

To impersonate the user, Service for User (S4U) extension is used which provides two extensions:

• Service for User to Self (S4U2self) - Allows a service (webservice in the example) to obtain a forwardable TGS to itself on behalf of a user with just the user principal name without supplying a password. The first hop needs to impersonate the user to delegate, so this extension allow a service to obtain a TGS forwardable to himself on behalf of a user. The service account must have the TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION (T2A4D) UserAccountControl attribute.

• Service for User to Proxy (S4U2proxy) - Allows a service (webservice in the example) to obtain a TGS to a second service on behalf of a user. Which second service? This is controlled by msDS-AllowedToDelegateTo attribute. This attribute contains a list of SPNs to which the user tokens can be forwarded.

  

  <aside> ⚠️ The two attributes TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION and msDS-AllowedToDelegateTo are sensitive attributes writable only by Domain Admins therefore the Domain Controller during its audits uses them as absolute references to know what each service account can access. The problem is that if the Domain Admin account is hacked the whole castle collapses!

  </aside>

1. A user (outside domain or internal) authenticates to a service (e.g., webservice) using an authentication other than kerberos (e.g., form-based authentication)
2. The webservice (first-hop) requests a forwardable TGS (for itself) from the KDC on behalf of the user without sending passwords (so there is no verification by the KDC on the user and it can be anyone!!)
3. The KDC checks whether the webservice is allowed to do this (by checking the TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION attribute) and verifies that the user for whom TGS is requested does not have the delegation blocked (TRUSTED_FOR_DELEGATION enabled). If everything is okay, the KDC issues the TGS with the S4U2Self extension that works on any account that has an SPN.
4. The webservice presents the TGS received from the KDC and requests a new TGS for another service in the network (second hop) e.g., DB server.
5. The KDC checks if the target service (DB server) is listed among the allowed SPNs in the msDS-allowedToDelegateTo attribute of the webservice and if it is listed it issues the TGS to access the target service of the DB server with the second extension S4UProxy.
6. If all conditions are validated, the webservice can authenticate to the DB server on behalf of the (impersonated) user using the received TGS.

How to abuse

To abuse constrained delegation in above scenario, we need to have access to the first hop service account. If we have access to that account, it is possible to access the services listed in msDS-AllowedToDelegateTo of the first hop service account as ANY user in the target machine (second hop).