Generated Wednesday, October 7, 2026 · Depth: deep · Delegation behaviors, MachineAccountQuota, Protected Users, and the 2025 guidance checked against Microsoft documentation and Microsoft's December 2025 Active Directory threat-mitigation blog.

Delegation and trust, the last mile of Kerberos

Plain English first

Delegation is Kerberos solving a real business problem. You open a web app; the web app needs to pull your rows from a database on another server, as you, not as itself. Someone has to let the web server reuse your identity on the next hop. That permission is delegation.

It is genuinely useful and genuinely dangerous. If a server can act as you, then whoever controls that server can act as you, and if the configuration is loose, as anyone. Three designs exist, built over 20 years, each tightening the last:

• Unconstrained: the oldest and most dangerous. The server can impersonate you to anything. It caches your master ticket to do so.
• Constrained: the server can impersonate you, but only to a named list of services.
• Resource-based (RBCD): the same idea, but the permission is set on the destination, which flips who can configure it, and that flip is an attack path.

The analogy: the valet, the concierge, and the loading dock

Why it matters now

If you remember only 5 things

1. Unconstrained delegation is the one to hunt and kill first. It caches users' Ticket Granting Tickets (TGTs), including a DC's if you can coerce one to connect. Treat any non-DC host with it as near-Tier 0.
2. Constrained and RBCD both run on S4U. S4U2self gets a ticket "as" a user; S4U2proxy forwards it to a back-end. Understanding those two calls explains constrained, resource-based, and sapphire tickets at once.
3. RBCD's danger is who can configure it. The permission lives on the target and anyone with write access to it can set it. Combined with the default machine-account quota of 10, a plain user can often engineer impersonation.
4. Protect Tier 0 identities from delegation entirely. Add them to Protected Users and mark them "sensitive and cannot be delegated." No correctly configured delegation can then impersonate them.
5. Trusts move the blast radius. SID history and weak SID filtering let a compromise in one domain reach another. A forest is one security boundary; a domain is not.

Core concepts

Thirteen ideas, each building on the last. Open "Go deeper" for expert detail.

Visual map

Step through legitimate S4U delegation, then the two escalation paths. Each step names the defense that breaks it.

The three delegation models

The S4U extensions

Protections for an identity against delegation

TechnicalUnder the hood

Unconstrained delegation

A front-end account flagged TRUSTED_FOR_DELEGATION receives, inside each inbound service ticket, a forwarded copy of the user's TGT plus its session key. The server caches that TGT in memory (in the Local Security Authority Subsystem Service, LSASS) and can present it to any service as the user. All DCs are trusted for delegation by design; the danger is any other host that carries the flag.

• The escalation: if an attacker controls an unconstrained host, they wait for, or coerce, a privileged account to authenticate to it, then lift that account's cached TGT.
• Coercion turns waiting into forcing. Techniques that make a server authenticate on command (the long-known "printer bug" via the Print System Remote Protocol, and the later PetitPotam over the Encrypting File System Remote Protocol) can point a DC's authentication at the attacker's unconstrained host, capturing the DC's own TGT. From there, DCSync (Part 2) yields the domain.
• Why it's so dangerous: no weak password, no ACL mistake, just one over-trusted host and a way to make a target connect to it.

Constrained delegation (KCD) and its two flavors

• Protocol transition (TrustedToAuthForDelegation, "use any authentication protocol"): the service may call S4U2self to obtain a ticket for a user who never authenticated with Kerberos, then forward it. Powerful, because the front-end can mint a usable ticket for any user at will.
• Kerberos only ("use Kerberos only"): the front-end can only forward a ticket the user genuinely presented, so it cannot conjure arbitrary users.
• The classic widening: msDS-AllowedToDelegateTo lists SPNs, but the service class in the forwarded ticket is not strongly bound. A front-end allowed to delegate to HTTP/host can often reach CIFS/host or LDAP/host on the same host, because the ticket targets the account, not the specific service. Delegating to a DC's services this way can mean full control.

Resource-based constrained delegation (RBCD)

RBCD inverts where trust is declared. Instead of a domain admin listing targets on the front-end, the target names who may delegate to it, in msDS-AllowedToActOnBehalfOfOtherIdentity. The practical consequence is who can configure it.

1. An attacker who can write that attribute on a target (via a misconfigured ACL, GenericWrite, GenericAll, WriteDACL, or control of the computer's own account) points it at an account they control.
2. They need a controlled account Kerberos treats as a service, which means an SPN. Because MachineAccountQuota defaults to 10, an ordinary user can usually just create a computer account to serve as that principal.
3. They then use S4U2self and S4U2proxy to obtain a ticket impersonating a privileged user to the target.

RBCD requires a Windows Server 2012 or higher domain functional level. Relay attacks tie in here: an authentication relayed to LDAP can write the attribute, which is why coercion plus relay plus RBCD is a common chain.

Trusts and SID history

• A forest is the security boundary, not a domain. Within a forest, the shared krbtgt-equivalent trust and the lack of SID filtering mean a compromise in one domain can often reach others.
• SID history (sIDHistory) exists to preserve access during migrations by carrying old SIDs. An attacker who can write it can insert a privileged SID (for example, a Domain or Enterprise Admin group) so a low-privileged account inherits that access. Golden and diamond tickets can embed SID history directly.
• SID filtering is the countermeasure: it strips SIDs that don't belong to the trusted domain. It is applied by default on cross-forest trusts (quarantine), but intra-forest trusts don't filter, which is why intra-forest escalation via SID history works.
• Referral tickets carry a client across trusts: the home KDC issues a referral TGT to the trusted domain's KDC, which then issues the service ticket. This is the machinery attackers ride when moving between domains with forged or SID-history-laden tickets.

Kerberos armoring (FAST)

Flexible Authentication Secure Tunneling (FAST) wraps the pre-authentication exchange inside an "armor" protected by the machine's TGT, so the timestamp and errors aren't exposed to offline attack, and it enables compound authentication (device plus user claims). It raises the cost of AS-REP roasting and pre-auth attacks from Part 1 and underpins authentication policies and silos. It needs both client and DC support and is turned on through Group Policy; it is not universally on by default, so treat it as a deliberate hardening project.

Authentication policies and silos

These are the opt-in controls that actually restrict ticket issuance by context: an authentication policy can require armor and cap TGT lifetime, and a silo can confine a set of accounts so their tickets are only issued when they authenticate from designated hosts. For Tier 0, a silo plus Protected Users is the strongest standing configuration Kerberos offers.

Common misconceptions

Finding and verifying delegation

# Unconstrained (non-DC hosts flagged for delegation)
Get-ADComputer -Filter {TrustedForDelegation -eq $true -and PrimaryGroupID -ne 516} -Properties TrustedForDelegation
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation

# Constrained (KCD)
Get-ADObject -Filter {msDS-AllowedToDelegateTo -like '*'} -Properties msDS-AllowedToDelegateTo

# Resource-based (RBCD): targets that name a delegate
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
  Where-Object {$_.'msDS-AllowedToActOnBehalfOfOtherIdentity'}

# Machine account quota
(Get-ADObject (Get-ADDomain).DistinguishedName -Properties ms-DS-MachineAccountQuota).'ms-DS-MachineAccountQuota'

# Accounts protected from delegation
Get-ADUser -Filter {AccountNotDelegated -eq $true} -Properties AccountNotDelegated
Get-ADGroupMember 'Protected Users'

AttackerAttacker's view, for defenders

Covered at the level needed to recognise, test for, and explain each path. Focus on prerequisites, what makes an environment vulnerable, the evidence left, and how it reads as a finding. Tools are named so you can build detections and a lab.

How delegation findings usually chain

1. Discovery: LDAP and BloodHound enumerate delegation flags, the msDS-Allowed* attributes, write permissions on computer objects, and the machine-account quota.
2. Setup: for RBCD, create or commandeer a controllable SPN account and write the target attribute; for unconstrained, identify a flagged host and a coercion target.
3. Impersonation: S4U calls (constrained/RBCD) or a captured TGT (unconstrained) yield access as a privileged user.
4. Objective: access to the target service, and frequently a direct path to Tier 0, especially when a DC is involved.

DefenderDefender's playbook

The strategy: eliminate unconstrained delegation, scope the other two tightly, close the machine-account quota, protect Tier 0 identities from delegation, and alert on the few attribute changes that signal abuse.

Quick wins (days)

1. Hunt unconstrained delegation on non-DC hosts and remove it, or convert those apps to constrained or resource-based delegation. Treat each flagged host as near-Tier 0 until fixed.

   Get-ADComputer -Filter {TrustedForDelegation -eq $true -and PrimaryGroupID -ne 516} -Properties TrustedForDelegation |
     Select Name,DNSHostName

2. Set MachineAccountQuota to 0 and grant computer-join rights only to a delegated group.

   Set-ADDomain (Get-ADDomain) -Replace @{'ms-DS-MachineAccountQuota'=0}

3. Protect Tier 0 identities: add them to Protected Users and set the sensitive flag.

   Set-ADAccountControl -Identity adm_tier0 -AccountNotDelegated $true
   Add-ADGroupMember 'Protected Users' adm_tier0

4. Review RBCD attributes already present; any unexpected msDS-AllowedToActOnBehalfOfOtherIdentity is suspicious.
5. Audit write permissions on computer objects (GenericWrite, GenericAll, WriteDACL, WriteProperty) and remove over-broad grants. BloodHound maps these edges well.
6. Mitigate coercion: patch, disable the Print Spooler where it isn't needed, and apply the recommended registry and Extended Protection for Authentication settings against PetitPotam-style relays.

Longer-term fixes (weeks to months)

1. Deploy authentication policies and silos for Tier 0, confining those accounts to designated admin hosts and requiring armor.
2. Turn on Kerberos armoring (FAST) by policy across clients and DCs, after testing. It hardens the pre-auth attacks from Part 1 and supports compound authentication.
3. Enforce SMB signing, LDAP signing, and LDAP channel binding (default-on in Windows Server 2025) to blunt the relay half of RBCD chains.
4. Review trusts: confirm SID filtering / quarantine on cross-forest trusts, remove unnecessary trusts, and alert on sIDHistory writes.
5. Scope constrained delegation precisely, prefer "Kerberos only" over protocol transition, and never delegate to Tier 0 services.
6. Migrate front-end services to gMSAs so their keys are strong and managed, shrinking both roasting and silver-ticket exposure on the delegating host.

Detection signals

Verify the fix worked

1. Re-run the discovery queries: no unexpected unconstrained hosts, machine-account quota is 0, and no stray RBCD attributes.
2. Confirm Tier 0 accounts show AccountNotDelegated = true and are in Protected Users.
3. Have testers attempt the RBCD chain against a hardened target and confirm it fails and that 4741/5136 alerts fire.
4. Confirm coercion attempts no longer capture a DC TGT (no unconstrained non-DC hosts remain) and that patches/registry settings are applied.
5. Where armoring was enabled, confirm clients and DCs negotiate it and that authentication policies apply to the Tier 0 silo.

Why remediation stalls, and workable compromises

ExecutiveExecutive brief

The risk in plain language

To work smoothly, our network lets some servers act "on behalf of" a user, so that, for example, a web application can fetch your data from a database as you. This is normal and useful. The risk is that if one of those servers is set up too loosely, or if the permission controlling it can be edited by the wrong person, an attacker can use it to impersonate anyone, including our most powerful administrators.

One older form of this feature is especially dangerous: a server set up with it can be tricked into capturing the credentials of a domain controller, one of the servers that vouches for every login, which leads to control of the whole network.

Business impact

• A path from a modest foothold to full control of the Windows environment, often without cracking a single password.
• Impersonation of specific high-value users, undermining the trustworthiness of our access logs.
• In networks connected by trust relationships, compromise can spread from one business unit or acquisition to another.

What drives likelihood

• Old, over-trusted servers left configured with the dangerous legacy form of this feature.
• Loose permissions that let ordinary users create machine accounts or edit delegation settings.
• Unprotected administrator accounts that aren't marked as off-limits to this feature.
• Unmanaged trust relationships between parts of the organization.

Cost of inaction

The fixes are configuration and permission changes, not purchases: removing the legacy feature where it isn't needed, tightening who can create machine accounts, protecting administrator accounts, and reviewing trusts. The cost of leaving it is a reliable, quiet route to total compromise that doesn't trip the defenses aimed at passwords.

What good looks like

• The dangerous legacy form of delegation exists only where it's unavoidable, on isolated and closely watched servers.
• Ordinary users can't create machine accounts or edit delegation settings.
• Administrator accounts are explicitly protected from being impersonated this way.
• Trust relationships are inventoried, justified, and filtered.
• We're alerted when someone changes a delegation setting or creates a machine account unexpectedly.

Questions executives ask

Presenting this finding to leadership

1. Headline: "A loose server setting let us impersonate an administrator and reach full control, without guessing any password."
2. Make it concrete: name the server or permission involved and what it let us reach.
3. Stress the fix is cheap: configuration changes, not new products.
4. The ask: remove the legacy feature where unneeded, lock down machine-account creation, protect admin accounts, and fund the monitoring.

Talk the talk

Jargon decoder

Smart questions to ask

Sysadmins

• Which non-DC hosts are trusted for unconstrained delegation, and why?
• What is MachineAccountQuota set to, and who can create computer accounts?
• Are Tier 0 accounts in Protected Users and marked sensitive?
• Do you audit changes to the delegation attributes and to sIDHistory (event 5136)?
• Is constrained delegation scoped to specific SPNs, and do you use "Kerberos only" where possible?
• Have you enabled Kerberos armoring, and do you have authentication policies and silos for Tier 0?

Executives

• Do we know which servers can impersonate our users, and is that list as short as it should be?
• Are our administrator accounts explicitly protected from impersonation?
• Do we have a current inventory of our trust relationships with other networks?

Coworkers

• Does scope cover coercion and relay, or just the delegation config itself?
• Is the machine-account quota in play, or do we already hold write on a target?
• Are we testing across a trust, and is SID filtering in the way?

Say this, not that

Same point, two audiences

Acronyms

Every acronym used on this page. Four test modes are below the table.

Test yourself

Flashcards

Quiz

Fifteen questions, mostly scenarios. Feedback appears as soon as you choose.

Conversation drills

Say or type your answer first, then compare with the sample.

Export cards

Basic cards (Quizlet and Anki Basic)

Standard flashcards, acronym cards, and cloze cards turned into "sentence with ____" fronts. Tab separates front and back; one card per line.

• Quizlet: Create a set, choose Import, paste, set "Between term and definition" to Tab and "Between cards" to New line.
• Anki: Paste into a .txt file, then File, Import, choose the Basic note type with Tab as the field separator.

Anki cloze cards

Uses Anki's {{c1::answer}} syntax. Quizlet doesn't support cloze.

• Anki: Paste into a .txt file, then File, Import, choose the Cloze note type; the whole line maps to the Text field.

Keep going

You've finished the three-part core. What to learn next, in order

1. Active Directory Certificate Services (AD CS) abuse. Certificate templates and enrollment flaws (the well-known certificate-escalation paths) turn into Kerberos tickets through PKINIT. It's the largest adjacent surface and a natural next topic.
2. NTLM, relay, and coercion in depth. The other half of Windows authentication, and the relay engine behind many RBCD chains.
3. Reading attack paths as graphs. BloodHound fluency, so you can explain delegation and ACL edges to a client visually.
4. AD incident response and forest recovery. Tying Parts 2 and 3 together into a containment and rebuild runbook.
5. Detection engineering for identity. Writing and tuning the 5136, 4741, and Transited-Services rules in your SIEM.

Resources worth seeking out

• Specifications: [MS-SFU] for the S4U extensions, [MS-PAC] for authorization data, and [MS-KILE] for Windows Kerberos.
• Microsoft: the December 2025 "guidance to help mitigate critical threats to Active Directory Domain Services" blog, the Protected Users and authentication-policies/silos documentation, and the KB articles on coercion mitigations and Extended Protection for Authentication.
• MITRE ATT&CK: T1558 (Steal or Forge Kerberos Tickets), T1134 (Access Token Manipulation), and T1187 (Forced Authentication) for coercion.
• Reference writeups: the delegation sections of the-hacker-recipes and the Compass Security "Kerberos Deep Dive" series, which are written clearly enough to double as defender references.
• Defender reading: Elad Shamir's foundational article on resource-based constrained delegation, and Sean Metcalf's ADSecurity.org delegation and trust articles.
• Hands-on labs: the GOAD (Game of Active Directory) project includes delegation scenarios; run each, then find the 5136 and 4741 traces in the DC logs.