S4U2Self and S4U2Proxy

S4U2Self

A service (any SPN-bearing account) obtains a ticket to itself for a specified, eligible user. The ticket is forwardable only if TrustedToAuthForDelegation is set on the service account.

“Use any authentication protocol” = TrustedToAuthForDelegation

Context: It’s common to list SPNs in msDS-AllowedToDelegateTo without setting TrustedToAuthForDelegation. When a user authenticates with Kerberos, their ticket to the service is usually already forwardable, so you don’t need S4U2Self to get a forwardable ticket before delegating. If a user authenticates with NTLM (or other non-Kerberos methods), the TrustedToAuthForDelegation flag is needed so the S4U2Self ticket is forwardable and usable as S4U2Proxy evidence.

S4U2Proxy

Using a user's service ticket as an evidence ticket (from S4U2Self or from the user’s Kerberos logon), the service requests a ticket to a back-end SPN.

A service ticket is issued if: - Classic constrained delegation: The back-end SPN is listed exactly in the requesting service account’s msDS-AllowedToDelegateTo. The evidence ticket must be forwardable. - Unconstrained Delegation Abuse (KUD) - Resource-based constrained delegation (RBCD): The requesting service account is allowed by the target service account’s msDS-AllowedToActOnBehalfOfOtherIdentity. This permits proxy tickets to any SPN hosted by that target account (e.g., cifs/DC, ldap/DC), and the evidence ticket does not need to be forwardable. - Resource Based Constrained Delegation Abuse (RBCD)