Kerberos Delegation Security Guide: Unconstrained and Constrained

Kerberos delegation lets a service act as the users who connect to it, and a single badly configured delegation setting can turn one compromised server or service account into control of the domain. Most Active Directory estates carry delegation settings made years ago, and few teams know which accounts can impersonate whom. This guide goes deeper than the Active Directory and Entra ID Hardening Guide on one topic: how unconstrained delegation, constrained delegation with and without protocol transition, and resource-based constrained delegation (RBCD) work, how each is abused in principle, and how to find, fix and monitor them. Kerberos tickets, encryption types and the KRBTGT account are covered in the Kerberos Security Guide and are not repeated here. It is written for directory engineers, identity security teams and detection engineers.

Key takeaways

• Unconstrained delegation is a credential cache. Every user who authenticates to a host trusted for unconstrained delegation leaves a reusable ticket granting ticket (TGT) behind, so outside domain controllers it should not exist.
• Protocol transition is impersonation without the user. Constrained delegation with "use any authentication protocol" lets a service obtain tickets as any user who is not protected, even users who never connected, so treat those accounts as tier zero when they can reach sensitive services.
• RBCD moves the decision to whoever can write one attribute. Write access to msDS-AllowedToActOnBehalfOfOtherIdentity on a computer object is effectively admin access to that computer, so govern the write ACL, not just the value.
• Sensitive accounts need an explicit opt-out. "Account is sensitive and cannot be delegated" and the Protected Users group stop administrators being impersonated through any delegation model; neither is the default.
• Delegation changes are detectable. Directory change auditing (event 5136) on three attributes, Transited Services in event 4769 and a MachineAccountQuota of zero close most delegation attack paths at low cost.

How Kerberos delegation works

Delegation exists to solve the double hop: a front-end service authenticated with Kerberos needs to reach a back-end service (a database, a file share, an API) as the user, not as itself. Active Directory offers four models. They differ in where the setting lives, who can change it and what the front-end service ends up holding.

Microsoft states the core risk of every constrained form: "If a server that hosted a front-end service was compromised, and it was configured to delegate to resource services, the resource services could also be compromised."

S4U2self, S4U2proxy and protocol transition

Constrained delegation and RBCD rely on two Microsoft extensions to Kerberos defined in the MS-SFU specification, collectively the S4U extensions.

• S4U2self (Service for User to Self): a service asks the KDC for a service ticket to itself on behalf of a named user. MS-SFU describes it as returning "a service ticket to the service itself (a ticket that cannot be used elsewhere)". It is how a web application that authenticated a user with forms, certificates or a federated token gets a Kerberos identity for that user. This is protocol transition.
• S4U2proxy (Service for User to Proxy): the service presents a forwardable service ticket for the user and asks for a ticket to a back-end service. MS-SFU: it "allows the caller to contact some other service, acting on behalf of the user."
• The forwardable rule: S4U2proxy only works with a forwardable evidence ticket. Under MS-SFU section 3.2.5.1.2 the KDC MUST set the FORWARDABLE flag on an S4U2self ticket when TrustedToAuthenticationForDelegation is true, and MUST NOT when it is false and the account has delegation targets. When the user is marked as not delegable, the KDC SHOULD NOT set it. This is why protocol transition is the dangerous switch in classic constrained delegation.
• RBCD ignores that switch: Microsoft states that "the KDC always allows protocol transition when performing resource-based constrained delegation as though the bit were set." Any account allowed to delegate to a resource through RBCD can therefore impersonate arbitrary users to it, unless those users are protected.
• Ticket tampering was fixed: CVE-2020-17049 let a compromised constrained delegation service tamper with a ticket so the KDC accepted it for delegation; Microsoft's ticket signature fix reached enforcement with the July 13, 2021 updates.

The conceptual abuse is the same for every S4U path: whoever controls an account allowed to delegate (its password, key or host) gets service tickets as other users for the permitted services. Defence is about which accounts can delegate, to what, and which users are excluded.

Unconstrained delegation: find it and remove it

With unconstrained delegation the user's TGT is sent to the front-end host and held in memory there. The joint ASD, CISA, NSA and Five Eyes guidance on Active Directory compromises describes the most damaging variant: an attacker who controls such a host coerces a domain controller, for example through the Print Spooler service, into authenticating to it, then reuses the domain controller's TGT. The guidance says to remove unconstrained delegation from computer objects, mark privileged users as sensitive, add them to Protected Users and disable the Print Spooler on domain controllers.

• Find it: list every account whose userAccountControl includes TRUSTED_FOR_DELEGATION (0x80000, the TrustedForDelegation property in PowerShell), excluding domain controllers (SERVER_TRUST_ACCOUNT, 0x2000), which have it by design. Microsoft Defender for Identity reports this as the "Unsecure Kerberos delegation" assessment.
• Replace it: Microsoft's remediation is to select "Trust this computer for delegation to specified services only" and list the services, or to move to RBCD. Collect 4769 events for the account first to learn which back-end SPNs it really uses.
• Keep trust boundaries closed: since the July 2019 updates, TGT delegation across inbound forest and external trusts is blocked unless the EnableTGTDelegation trust setting is turned on. Microsoft's reason is that unconstrained delegation across forests "violates the security boundary between forests". Do not re-enable it; Microsoft recommends RBCD instead.
• Reduce coercion: disable the Print Spooler on domain controllers and enforce LDAP signing and channel binding and SMB signing, which limit relay of coerced authentication. The relay side is covered in the Kerberos Security Guide.

Constrained delegation and protocol transition

Classic constrained delegation is safer than unconstrained, but its risk depends entirely on the SPNs in msDS-AllowedToDelegateTo and on whether protocol transition is enabled. Microsoft's own description of TRUSTED_TO_AUTH_FOR_DELEGATION calls it "a security-sensitive setting. Accounts that have this option enabled should be tightly controlled."

• Rank by target: delegation to services on a domain controller (its LDAP, CIFS or HOST services) lets the holder act as an administrator against the directory. Any account that can delegate to a tier zero service is tier zero.
• Delegation to krbtgt: a msDS-AllowedToDelegateTo entry naming the krbtgt service, or an RBCD entry on the krbtgt account, has no legitimate business use and would let the holder obtain TGTs for other users. Treat either as a likely persistence mechanism and investigate, not just remove.
• Prefer Kerberos only: enable "use any authentication protocol" only where the front end authenticates users without Kerberos (forms, certificates, federation).
• Protect the delegating account's credentials: the key of a service account with protocol transition is as valuable as an admin password for its target services. Run it as a group managed service account where possible. See the Group Managed Service Accounts (gMSA) Guide.
• Restrict who can configure it: setting TRUSTED_FOR_DELEGATION or msDS-AllowedToDelegateTo requires the "Enable computer and user accounts to be trusted for delegation" user right (SeEnableDelegationPrivilege) on domain controllers. Keep that right to Administrators and review it in the Default Domain Controllers Policy.

Resource-based constrained delegation (RBCD) and its abuse paths

RBCD stores the list of allowed front ends on the resource as a security descriptor in msDS-AllowedToActOnBehalfOfOtherIdentity; administrators usually set it through the PrincipalsAllowedToDelegateToAccount parameter of the Active Directory PowerShell cmdlets. It is the model Microsoft and the joint guidance recommend where delegation is still needed, because it is scoped to one resource and works across domains. Its weakness is that it is only as strong as the write permissions on that attribute.

• Write access equals impersonation: anyone who can write the attribute on a computer object can add an account they control and then obtain tickets as any non-protected user, including local administrators, to services on that computer. ATT&CK T1098 Account Manipulation lists a threat actor procedure that abused RBCD assignments to impersonate high-privileged users.
• The attacker needs an account with an SPN: a computer account qualifies, which is why MachineAccountQuota matters (next section).
• Relay into the attribute: Microsoft's analysis of KrbRelayUp showed a low-privileged local user relaying the computer's own authentication to LDAP to set RBCD on it, then using S4U to become local administrator. Microsoft advised requiring LDAP server signing and Extended Protection for Authentication. Defender for Identity raises "Suspicious edit of the Resource Based Constrained Delegation Attribute by a machine account (KrbRelayUp)" for this pattern.
• High-value resources: the Microsoft Entra seamless single sign-on computer account (AZUREADSSOACC) should never carry RBCD. Microsoft warns that an account with that delegation could "impersonate any user in the Microsoft Entra tenant that is synchronized from AD"; the normal state is an empty attribute. Apply the same expectation to domain controllers, certificate authorities, synchronisation servers and the krbtgt account.
• Govern the ACL: audit who holds GenericAll, GenericWrite, WriteDacl or WriteProperty on this attribute over computer objects, including broad groups and each object's creator. A graph-based attack path tool shows these chains at scale. See the Lateral Movement Guide.

MachineAccountQuota: who can create computer accounts

ms-DS-MachineAccountQuota is defined by Microsoft as "the number of computer accounts that a user is allowed to create in a domain". It is set on the domain object and defaults to 10, so any authenticated user can create computer accounts. Those accounts come with SPNs and a password the user chose, which is exactly what RBCD abuse needs. The joint guidance recommends that unprivileged users cannot add computer objects to the domain.

1. Report computer accounts created by ordinary users: the creator is recorded in ms-DS-CreatorSID, and event 4741 (a computer account was created) shows who did it.
2. Delegate "Create Computer objects" on the specific OUs used for builds to a dedicated provisioning group or service account, and pre-stage computer objects where your build process allows.
3. Set ms-DS-MachineAccountQuota to 0 in a change window, after confirming that imaging, VDI and self-service join processes use the delegated account rather than end-user rights.
4. Roll back by restoring the previous value; only join workflows that relied on user rights are affected.

Protecting sensitive accounts from delegation

Privileged users should be impossible to impersonate through any delegation. Three complementary controls apply.

Protected Users records failures in the ProtectedUserFailures-DomainController log (event 100 for NTLM failures, 104 for DES or RC4) and successes as event 303, but both logs are disabled by default; enable them on domain controllers before adding members. Delegating service accounts should be gMSAs, because their own key is what an attacker would use. See the Service Account Security Guide.

Detecting delegation abuse

Enable "Audit Kerberos Service Ticket Operations" and "Audit Directory Service Changes" on every domain controller, then add SACL entries that audit writes to the delegation attributes on the domain's user and computer objects. Event 5136 is only generated where such a SACL exists.

Correlate them: a new computer account, a 5136 on a resource's RBCD attribute and a 4769 with Transited Services for an administrator within minutes is a high-confidence chain. See the ITDR Guide.

Metrics that show it is working:

• Non-DC accounts with unconstrained delegation (target: zero).
• Accounts with protocol transition, and the share whose targets include tier zero services (target: zero for tier zero).
• Objects with a non-empty RBCD attribute, each with a named owner and justification (target: 100 percent owned).
• ms-DS-MachineAccountQuota value (target: 0) and computer accounts created by non-provisioning identities per month.
• Share of privileged human accounts marked sensitive or in Protected Users (target: 100 percent).

Implementation roadmap

1. Inventory: export every account with either delegation flag, msDS-AllowedToDelegateTo or a non-empty RBCD attribute, plus the write ACLs on them, and assign owners.
2. Turn on visibility: enable the audit subcategories and SACLs above, and the Protected Users operational logs, before changing anything. Baseline two to four weeks of 4769 Transited Services.
3. Quick wins: remove unjustified delegation to krbtgt or tier zero services, clear RBCD on DCs and AZUREADSSOACC, and mark privileged accounts sensitive.
4. Pilot Protected Users: add one group of admins, watch events 100 and 104, then extend. Rollback is removing the account from the group.
5. Replace unconstrained delegation: for each host, switch to constrained delegation or RBCD using the SPNs seen in the baseline, test the application with a non-admin user, and keep the old setting documented for a quick rollback.
6. Close machine account creation: delegate join rights, then set MachineAccountQuota to 0.
7. Operate: review the inventory quarterly and put delegation under change control.

Decision guidance

• Unconstrained versus anything else: there is no case for it on member servers; if a vendor insists, treat the host as tier zero.
• Classic constrained delegation or RBCD: choose RBCD when the resource owner should decide or services span domains or forests; choose classic constrained delegation when you want changes to need domain admin rights. Protocol transition is implicit in RBCD, so protect sensitive users either way.
• Small or large organisations: a small domain gets most of the value from removing unconstrained delegation, setting MachineAccountQuota to 0, marking admins sensitive and alerting on 5136. A large or multi-forest estate also needs attack path analysis of attribute ACLs, an owner per delegation entry and correlation of 4741, 5136 and 4769.

Framework mapping

Common failure patterns

• Delegation as an old fix: unconstrained delegation enabled years ago for a double hop, on a server many admins use.
• Cleaning values, not permissions: RBCD entries removed while broad groups keep GenericWrite on computer objects.
• Default MachineAccountQuota: any domain user can still create ten computer accounts, giving every phished user the raw material for RBCD abuse.
• Admins not marked sensitive: constrained delegation is "safe", but the target service accepts impersonated Domain Admins because nobody set NOT_DELEGATED or used Protected Users.
• No SACL, no 5136: Directory Service Changes auditing is enabled but no SACL covers the delegation attributes, so the most important change never produces an event.

Practitioner checklist

• Inventory every account with unconstrained delegation, constrained delegation, protocol transition or RBCD, and give each an owner.
• Remove unconstrained delegation from all non-DC accounts and keep EnableTGTDelegation off on trusts.
• Remove any delegation to krbtgt or to tier zero services that cannot be justified, and investigate how it got there.
• Audit write ACLs on msDS-AllowedToActOnBehalfOfOtherIdentity and keep it empty on DCs, CAs, sync servers and AZUREADSSOACC.
• Set ms-DS-MachineAccountQuota to 0 after delegating join rights to a provisioning group.
• Mark all privileged human accounts "sensitive and cannot be delegated" and add them to Protected Users; never add service or computer accounts.
• Add SACLs and alert on 5136 for userAccountControl, msDS-AllowedToDelegateTo and msDS-AllowedToActOnBehalfOfOtherIdentity.
• Baseline 4769 Transited Services and alert on delegation for privileged users or new accounts.

Standards and references

• Microsoft Learn: Kerberos constrained delegation overview
• Microsoft: [MS-SFU] Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol
• ASD, CISA, NSA et al.: Detecting and Mitigating Active Directory Compromises
• Microsoft Learn: Protected Users security group
• Microsoft Learn: ms-DS-MachineAccountQuota attribute
• Microsoft Learn: Unsecure Kerberos delegation assessment
• Microsoft Learn: Event 4769, a Kerberos service ticket was requested
• MITRE ATT&CK: T1558 Steal or Forge Kerberos Tickets

Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · Kerberos Security Guide · Service Account Security Guide · Group Managed Service Accounts (gMSA) Guide · ITDR Guide