Delegation is the act of doing something on behalf of another. Microsoft implements this in their implementation of kerberos since kerberos authentication isn’t inherently transitive. This is sometimes referred to as the double-hop issue

Example:

User A- A standard user

Service A - The authentication context of some application within Active Directory; eg: a service account.

Service B - The authentication context of another application within Active Directory; eg: a service account.

• User A authenticates to Service A via a service ticket.
• From Service A, they try to access Service B
  • User A is denied access;
  • User A must reauthenticate to the KDC to get a service ticket for Service B. Then they can access Service B.

User A’s authentication to Service A didn’t authorize them to access Service B.

Delegation Example:

• User A authenticates to Service A via a service ticket.
• From Service A, they try to access Service B
  • Service A impersonates User A and grabs a service ticket with User A’s identity
  • Service A authenticates to Service B with this.
  • User A seamlessly accesses Service B.

Services impersonate their clients for a smoother end-user experience.

Unconstrained (TGT Forwarding)

A service can use client’s TGT to request a ticket for delegation. The computer the service is run on must be configured to do so via having TrustedForDelegation enabled. With this configuration, TGTs are cached in the computer’s memory so the service account can authenticate on behalf of users.

Operator considerations

Constrained with Protocol Transition

A computer or service account with TrustedToAuth may impersonate any user for the service specified by the msds-allowedtodelegateto property. This is a property that can be set by users with the SeEnableDelegation privilege; typically only Domain Admins have this.