> For the complete documentation index, see [llms.txt](https://breakpoint-journal.gitbook.io/breakpoint/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://breakpoint-journal.gitbook.io/breakpoint/windows/active-directory-abuse-kerberos-delegation-and-ad-cs/delegation-overview.md).

# Delegation Overview

Delegation lets one service act on behalf of a user to reach another service.

That is useful for applications. It is also a common source of lateral movement.

### The three delegation models

#### Unconstrained delegation

Unconstrained delegation is the broadest model.

If a user authenticates to a service trusted for unconstrained delegation, the service can receive material that lets it act widely as that user. If an attacker compromises that service, harvested tickets can become domain-level access.

#### Constrained delegation

Constrained delegation limits impersonation to an allowlist of target services.

That allowlist lives in `msDS-AllowedToDelegateTo`. This is safer than unconstrained delegation, but still dangerous when paired with a compromised service account.

#### Resource-based constrained delegation

RBCD flips the trust direction.

Instead of the caller maintaining the allowlist, the target resource decides which principals may act on behalf of other identities through `msDS-AllowedToActOnBehalfOfOtherIdentity`.

### S4U extensions

Delegation relies on two Kerberos extensions.

#### S4U2Self

S4U2Self lets a service request a ticket to itself on behalf of a user.

This supports protocol transition. It matters when the original client did not authenticate with Kerberos.

#### S4U2Proxy

S4U2Proxy lets a service take that delegated context and request a ticket to another service.

This is the step that turns local service control into lateral movement.

### Flags and properties that matter

A few fields drive most delegation behavior:

* `TrustedForDelegation`
* `TrustedToAuthForDelegation`
* `msDS-AllowedToDelegateTo`
* `msDS-AllowedToActOnBehalfOfOtherIdentity`
* `NotDelegated`

Protected users and accounts marked as non-delegable often break abuse chains, even when a service account is compromised.

### Why constrained delegation still fails safely only on paper

Constrained delegation sounds narrow.

In practice, the attacker only needs one useful service account, one reachable SPN, and one target that trusts the wrong principal. Service ticket substitution and protocol transition widen the blast radius.

### Service name substitution

Kerberos stores the service name in a form that can sometimes be changed without breaking the ticket for the owning account.

That means a ticket for one service on an account may become useful against another service owned by the same account.

### Defensive priorities

Start here:

* Eliminate unconstrained delegation where possible.
* Review principals with `TrustedToAuthForDelegation`.
* Audit RBCD permissions on critical servers.
* Mark sensitive identities as protected from delegation.

Delegation is not a fringe feature.

In many environments, it is one of the shortest paths from a single service compromise to full domain impact.