Kerberos Delegations: Unconstrained, Constrained, and RBCD

Most Potent Active Directory Escalation Vector

Kerberos delegation permits an intermediary service to impersonate a client identity to access downstream back-end services.

If a privileged principal (or a domain controller) authenticates to an Unconstrained Delegation host, its full, reusable TGT is stored in memory (LSASS) and can be extracted by an adversary.

Concept

In multi-tier enterprise applications (e.g., Frontend Web Server $\rightarrow$ Backend SQL Database), the frontend server must frequently query the database under the security context of the authenticated end user to enforce database-level access controls. This is the role of Kerberos Delegation.

Active Directory implements three successive architectures of delegation:

1. Unconstrained Delegation (Windows 2000): The client forwards a full, reusable copy of its TGT to the frontend service. The frontend can subsequently impersonate that client against any service across the entire forest.
2. Constrained Delegation with S4U (Windows Server 2003): The frontend account is restricted by a domain administrator to a predefined whitelist of target SPNs (configured in msDS-AllowedToDelegateTo).
3. Resource-Based Constrained Delegation (RBCD - Windows Server 2012): Inverts configuration control: the target resource server configures its own msDS-AllowedToActOnBehalfOfOtherIdentity attribute to specify which service accounts are permitted to impersonate users against it.

---

Why It Matters in DFIR

Delegation abuse lies at the center of sophisticated enterprise takeovers:

• Harvesting Tier 0 TGTs: An Unconstrained Delegation server acts as a credential trap. Attackers leverage authentication coercion techniques (PetitPotam, PrinterBug / MS-RPRN) to force a DC to authenticate to the compromised host, capturing the DC’s machine TGT from LSASS.
• Protocol Transition Attacks (S4U2Self / S4U2Proxy): In constrained delegation with protocol transition, an attacker possessing the service key can synthesize a service ticket for any domain user (including Domain Admins) without requiring user interaction.
• Stealthy RBCD Persistence: Attackers with write permissions (GenericWrite, WriteProperty) over a computer object can inject an attacker-controlled machine account into msDS-AllowedToActOnBehalfOfOtherIdentity, granting permanent local administrative compromise.

---

How It Works

1. Unconstrained Delegation

• Active Directory Attribute: userAccountControl contains the flag TRUSTED_FOR_DELEGATION (0x80000).
• When a client requests a TGS for this service, the KDC bundles a forwardable copy of the client’s TGT inside the service ticket.
• The receiving host decrypts the ticket and stores the forwarded TGT directly in local LSASS memory.

2. Constrained Delegation (S4U)

• AD Attributes: msDS-AllowedToDelegateTo (whitelisted SPNs) and TRUSTED_TO_AUTH_FOR_DELEGATION (protocol transition flag).
• Employs Microsoft Kerberos extensions S4U2Self (service requests a ticket to itself on behalf of an arbitrary user) and S4U2Proxy (service exchanges this ticket for a TGS targeting the authorized backend service).

3. Resource-Based Constrained Delegation (RBCD)

• AD Attribute: msDS-AllowedToActOnBehalfOfOtherIdentity (binary security descriptor DACL).
• Can be configured without Domain Admins rights by any identity possessing delegated management rights over the target computer.

---

What Is Possible

• Dumping Cached TGTs from Memory: On an Unconstrained host, executing sekurlsa::tickets dumps all forwardable TGTs stored in LSASS since the last reboot.
• Coercing Domain Controller Authentication: Running PetitPotam against a DC while listening on an Unconstrained host yields the DC01$ machine TGT, enabling instant DCSync.
• Protecting High-Value Accounts: Setting Account is sensitive and cannot be delegated (NOT_DELEGATED / 0x100000) or adding the account to the Protected Users group blocks TGT forwarding entirely.

---

What Is Not Possible

• Delegating Members of Protected Users: Members of this group cannot have their credentials forwarded or delegated under any Kerberos delegation model.
• Abusing Constrained Delegation to Access Unlisted SPNs: Target KDCs validate msDS-AllowedToDelegateTo. Unauthorized SPN requests fail with KDC_ERR_BADOPTION.
• Configuring RBCD Without an Account Bearing an SPN: Executing the S4U2Proxy leg requires that the operating principal possesses at least one valid SPN (standard computer account or gMSA).

---

Common DFIR Confusions

Frequent Confusion	Verifiable Forensic Reality
”All Windows servers have Unconstrained Delegation enabled by default.”	Only Domain Controllers have Unconstrained Delegation enabled by default. Any member server with this flag represents an architectural anomaly.
”The Protected Users group prevents all credential harvesting.”	It disables NTLM and Kerberos delegation, but does not protect against NTDS database extraction or DCSync.
”RBCD configuration requires Domain Admin rights.”	False. Any user with write permissions on the computer object (e.g., Owner, creator, or delegated technician) can populate RBCD attributes.

---

Concrete Forensic Example

During an investigation, an auxiliary print server PRINT-SRV is compromised:

1. Triage reveals PRINT-SRV holds the TRUSTED_FOR_DELEGATION flag.
2. The adversary triggers PetitPotam against domain controller DC01: python3 petitpotam.py PRINT-SRV 10.0.1.1
3. DC01 connects via MS-EFSR RPC to PRINT-SRV, providing its forwardable machine TGT (DC01$).
4. The attacker extracts DC01$’s TGT from LSASS using Rubeus.
5. The attacker injects this ticket into their session and invokes DCSync to dump the domain krbtgt hash.
6. DFIR Assessment: Complete domain takeover executed within 10 minutes originating from an unmonitored print server.

---

Key Forensic Artefacts

1. Active Directory Attributes:
   • userAccountControl: Flags 0x80000 (TRUSTED_FOR_DELEGATION) or 0x1000000 (TRUSTED_TO_AUTH_FOR_DELEGATION).
   • msDS-AllowedToDelegateTo: Multi-valued list of target SPNs.
   • msDS-AllowedToActOnBehalfOfOtherIdentity: Binary security descriptor on target computer objects.
2. DC Security Event Logs:
   • Event ID 4769 (TGS Request): Telemetry capturing S4U2Self and S4U2Proxy operations (service name appearing in client identity field).
   • Event ID 4738 / 4742: Account modifications capturing updates to delegation attributes.

---

Investigation Methods

1. Inventory All Unconstrained Delegation Hosts: Run Get-ADComputer -Filter {TrustedForDelegation -eq $True} to identify high-risk TGT collection points.
2. Audit RBCD Configurations Across the Fleet: Query for computer accounts where msDS-AllowedToActOnBehalfOfOtherIdentity is populated.
3. Monitor Inbound DC-to-Member-Server RPC Connections: Inspect network and host firewalls for anomalous outbound RPC/SMB traffic originating from DCs toward member servers (coercion signatures).

---

Investigative Tooling

• PowerView:

  Get-DomainComputer -Unconstrained
  Get-DomainUser -TrustedToAuth
  Get-DomainComputer | Where-Object { $_.'msds-allowedtoactonbehalfofotheridentity' -ne $null }

• BloodHound: Cypher Queries:
  • MATCH (c:Computer {unconstraineddelegation:true}) RETURN c
  • MATCH p=(u)-[:AllowedToAct]->(c:Computer) RETURN p

---

Key Takeaways

• Unconstrained delegation caches full client TGTs in LSASS.
• Chaining authentication coercion (PetitPotam) with Unconstrained Delegation achieves instantaneous domain compromise.
• RBCD enables granting administrative access over a workload without requiring Domain Admin rights.
• Privileged identities must be protected with Account is sensitive and cannot be delegated.

---

References & Further Reading

• Microsoft Learn: Kerberos Constrained Delegation Overview
• Card 21 — NTLM vs Kerberos: Fundamental Differences in DFIR Investigations
• Card 22 — The Kerberos PAC: Structure, Validation, and Forgery
• Card 26 — DCSync: Mechanics, Prerequisites, and Forensic Artefacts