Kerberos Delegation Abuse: Unconstrained, Constrained, and RBCD

Kerberos delegation is one of Active Directory's most useful features and one of its most dangerous misconfigurations. It exists so a front-end service (a web app, an SQL gateway) can act on a user's behalf against a back-end service without re-prompting for credentials. When it works, it's invisible. When it's set up carelessly, it hands an attacker a straight line to Domain Admin. Delegation abuse has been behind some of the cleanest domain-takeover chains of the last decade, and most defenders still don't audit for it.

There are three flavors, and they escalate in subtlety. Understanding how each one is abused is the difference between fixing a real risk and chasing noise.

Unconstrained delegation: the loudest problem

A machine or account configured with unconstrained delegation is trusted to impersonate any user to any service. When such a user authenticates to that host, their full Ticket-Granting Ticket (TGT) is cached in the host's memory. Compromise the host, and you can extract every cached TGT — including that of a Domain Admin who happened to browse a share on it.

Attackers don't wait passively. Coercion techniques (PetitPotam, PrinterBug) force a Domain Controller to authenticate to an unconstrained-delegation host the attacker controls, capturing the DC's TGT and enabling a DCSync. The account flag to hunt for is TRUSTED_FOR_DELEGATION in userAccountControl.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
  Select-Object Name, DNSHostName

Rule of thumb: nothing except Domain Controllers should have unconstrained delegation. Every other hit is a finding, not a feature.

Constrained delegation: safer, but still abusable

Constrained delegation (S4U2Proxy) limits an account to impersonating users only to a specific list of services (msDS-AllowedToDelegateTo). That's a big improvement — but two gaps remain.

• Protocol transition (TRUSTED_TO_AUTH_FOR_DELEGATION) lets the account request a ticket for any user without that user ever authenticating — including highly privileged accounts.
• The service name in a ticket isn't cryptographically bound to the target service class. An attacker who controls a constrained-delegation account can swap the SPN suffix (e.g. request a time/ SPN then use it against cifs/ or host/), reaching services never listed in the delegation config.

The practical impact: compromise one over-permissioned service account and you can impersonate an administrator to the file system or WMI of the target host.

Resource-Based Constrained Delegation (RBCD): the quiet one

RBCD flips the trust direction. Instead of the front-end account listing who it can delegate to, the target resource lists who is allowed to delegate to it, via msDS-AllowedToActOnBehalfOfOtherIdentity. This attribute lives on the target object and is often writable by whoever created or manages it.

The classic abuse chain: an attacker with the ability to create a computer account (the default ms-DS-MachineAccountQuota of 10 lets any authenticated user do this) creates a machine, sets that machine as allowed-to-act on a target they can write to, then uses S4U to impersonate a Domain Admin to the target. No reboot, no malware — just three attribute writes.

# Detection: any non-empty allowed-to-act attribute is worth reviewing
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
  Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' } |
  Select-Object Name

Detecting and hardening delegation

Delegation risk is a configuration problem, which means it's auditable before it's ever exploited. The senior-engineer checklist:

1. Enumerate every account with TrustedForDelegation or TrustedToAuthForDelegation set, and every object with a populated msDS-AllowedToActOnBehalfOfOtherIdentity.
2. Mark sensitive accounts "Account is sensitive and cannot be delegated" (NOT_DELEGATED flag), and add Tier-0 accounts to the Protected Users group.
3. Set ms-DS-MachineAccountQuota to 0 so ordinary users can't spawn the computer account RBCD needs.
4. Retire unconstrained delegation entirely; migrate legacy dependencies to constrained delegation with explicit SPN lists.
5. Alert on writes to msDS-AllowedToActOnBehalfOfOtherIdentity — that attribute changing is a near-real-time attack signal.

Where WinSentinel fits

WinSentinel audits delegation posture on every machine it runs. On a single workstation or server — completely free, with all modules and no limits — it flags accounts trusted for delegation, sensitive accounts that aren't protected, and a non-zero machine account quota, mapping each finding to the concrete privilege-escalation path it enables. You get the same depth a red-teamer would look for, without running the attack.

For organizations, WinSentinel Pro rolls these findings up across the fleet from a central node: it surfaces which hosts carry dangerous delegation, tracks drift when a new allowed-to-act entry appears anywhere in the estate, and folds delegation hygiene into compliance rollups so a stale unconstrained-delegation server can't hide in a directory of thousands. Delegation abuse is a domain-wide problem; catching it demands a domain-wide view — but the audit that finds it on any one machine is free.