Constrained Delegation: 'Kerberos Only' Doesn't Make It Safe

Import-Module ActiveDirectory

$dcNames = foreach ($dc in Get-ADDomainController -Filter *) { $dc.HostName; $dc.Name }
$props   = 'sAMAccountName', 'servicePrincipalName', 'userAccountControl', 'msDS-AllowedToDelegateTo'

Get-ADObject -LDAPFilter '(msDS-AllowedToDelegateTo=*)' -Properties $props |
  ForEach-Object {
    $targets = @($_.'msDS-AllowedToDelegateTo')
    $hosts   = $targets | ForEach-Object { (($_ -split '/')[1] -split ':')[0] }
    $hasSpn  = ($_.servicePrincipalName | Measure-Object).Count -gt 0
    $anyAuth = [bool]($_.userAccountControl -band 0x1000000)
    [pscustomobject]@{
        Account   = $_.sAMAccountName
        Class     = $_.ObjectClass
        Form      = if ($anyAuth) { 'Any protocol' } elseif ($hasSpn) { 'Kerberos only' } else { 'Kerberos only, no SPN' }
        TargetsDC = [bool]($hosts | Where-Object { $_ -in $dcNames })
        Targets   = $targets -join '; '
    }
  } | Sort-Object @{ Expression = 'TargetsDC'; Descending = $true }, Account

How constrained delegation works

Delegation lets a front-end service reach a back-end service as the signed-in user. A web app that queries SQL Server with each user's own permissions is the classic example. Constrained delegation limits that to a list of back-end services, stored on the front-end account in msDS-AllowedToDelegateTo. Our posts on unconstrained delegation and resource-based constrained delegation cover the other two forms.

The Delegation tab in Active Directory Users and Computers offers two versions of it:

• Use Kerberos only. The service can only act as a user who signed in to it with Kerberos. It needs a forwardable ticket from that user first.
• Use any authentication protocol. It's also called protocol transition. The service can get a ticket as almost any user on its own, whether or not they ever signed in to it. Windows marks these accounts with the TRUSTED_TO_AUTH_FOR_DELEGATION flag.

Under the hood, "Use Kerberos only" relies on a Kerberos extension Microsoft calls S4U2Proxy. "Use any authentication protocol" adds S4U2Self on top. For defenders, the important point is that whoever controls the account can ask for tickets to the listed services as other users. Setting the list takes the "Enable computer and user accounts to be trusted for delegation" right, which only Administrators hold on domain controllers by default.

Why constrained delegation is risky

Each entry on that list lets the account act as your users toward that service. If an attacker gets the account's password or hash, they can do the same. The only users they can't impersonate are members of Protected Users and accounts marked "Account is sensitive and cannot be delegated." Anyone else can be impersonated, including your admins.

How bad that gets depends on what's on the list. An entry for a SQL Server gives the attacker that database as any user. The service name in a delegated ticket isn't protected, though. If the SQL SPN sits on the server's computer account, the attacker can rewrite the ticket for other services on that server, including file shares. Any entry for a service on a domain controller, even something like the time service, can be turned into access to the DC itself.

For years the advice was to pick "Use Kerberos only" and move on. The attacker would need a forwardable ticket from a real user, which they shouldn't be able to get. Elad Shamir showed in 2019 how to get one anyway on accounts that have an SPN, using resource-based constrained delegation. Accounts with no SPN were the only setup left without a public abuse path.

What changed for accounts with no SPN

On September 22, 2026, Hunter Wade published a way to abuse that last case on his blog, hun.io. Sprocket Security posted it in October. It's not a new Kerberos bug. The write-up combines Shamir's 2019 trick with a 2022 technique from James Forshaw for getting tickets to accounts that have no SPN. With both, an attacker can abuse constrained delegation from a "Use Kerberos only" account that has no SPN and reach every service on its list.

What the attacker needs:

• Control of an account with "Use Kerberos only" delegation and no SPN.
• RC4 still allowed in the domain. The chain swaps the account's password hash for a ticket's session key, which only works with RC4.
• A second account with an SPN. With MachineAccountQuota above 0, any domain user can make a computer account for it. An account with an SPN they've already compromised works too.
• A way to set resource-based delegation on the compromised account. The researcher says accounts can do that on themselves by default.

The chain is noisy because it overwrites the account's password, which breaks whatever normally uses that account. In the write-up's lab, the account could delegate to the host service on a domain controller. The chain ended with a ticket as Administrator to that service and a dump of the DC's secrets.

Microsoft's 2026 change turned off the silent RC4 fallback, but RC4 still works anywhere it's been set explicitly, on an account or domain-wide. If you turned RC4 back on domain-wide to keep an old app running, assume this path is open. Our Kerberos RC4 post shows how to check.

Find constrained delegation in your domain

Go through every entry

The Check it now command lists every account with a delegation list, which form it uses and whether any target is a domain controller. What to look for:

• TargetsDC is True. The account can delegate to a service on a domain controller. Treat it as a path to the DC and find out who owns it today.
• Any protocol. Protocol transition is the easiest form to abuse. Confirm the app needs it.
• Kerberos only, no SPN. These are the accounts the new technique targets. They're usually leftovers, because the Delegation tab only appears once an account has an SPN. Someone either set the list with a script or removed the SPN later without clearing the list.
• Class is user. A user account means a password somebody chose. Check how old it is and who knows it.

TargetsDC only knows this domain's DCs by name. Read the Targets column for anything pointing at another domain, a DNS alias or a GUID-style name.

Check the settings the newest path needs

The SPN-less path needs RC4 and a second account with an SPN. MachineAccountQuota is the easy way to get that account. The command below shows how many computers a standard user can add, which defaults to 10.

Import-Module ActiveDirectory
Get-ADObject (Get-ADDomain).DistinguishedName -Properties 'ms-DS-MachineAccountQuota' |
    Select-Object 'ms-DS-MachineAccountQuota'

Anything above 0 means any domain user can create one, as long as Authenticated Users still holds the "Add workstations to domain" right, which it does by default. Anyone with Create Computer objects on an OU can add computers whatever the quota says. Our MachineAccountQuota post covers both. For RC4, the checks in our Kerberos RC4 post show whether it's still on domain-wide or set on specific accounts.

Find admins that can still be delegated

Protecting your admin accounts keeps them from being impersonated through any form of delegation. It doesn't help with computer accounts, which can't go in Protected Users. Removing entries that point at a DC still comes first. The script below lists enabled admin accounts that aren't in Protected Users and aren't marked sensitive.

Import-Module ActiveDirectory
$pu        = "$((Get-ADDomain).DomainSID.Value)-525"
$protected = @(Get-ADGroupMember -Identity $pu -Recursive | ForEach-Object { $_.SID.Value })

Get-ADUser -LDAPFilter '(adminCount=1)' -Properties AccountNotDelegated |
    Where-Object { $_.Enabled -and -not $_.AccountNotDelegated -and $_.SID.Value -notin $protected } |
    Select-Object SamAccountName, DistinguishedName

The script uses adminCount, which covers the built-in admin groups and also picks up people who used to be in them. Admins who get their rights some other way, like delegated OU permissions, won't show up. Protect the former admins too, or clear the flag if they don't need it anymore.

Clean up constrained delegation

1. Remove entries nobody can explain

Start with anything pointing at a domain controller, then the SPN-less entries. Clearing msDS-AllowedToDelegateTo removes the list. Protocol transition is a separate flag you can turn off on its own. Test the app before and after, since some front ends really do depend on delegation.

Import-Module ActiveDirectory

# Clear the delegation list on one account. Use the Account value from the check above.
Get-ADObject -Filter "sAMAccountName -eq 'svc-web'" | Set-ADObject -Clear 'msDS-AllowedToDelegateTo'

# Or keep the list and drop "any authentication protocol" so it's Kerberos only
Set-ADAccountControl -Identity 'svc-web' -TrustedToAuthForDelegation $false

2. Protect admin accounts from delegation

Put admins in Protected Users or set "Account is sensitive and cannot be delegated." Either one stops every form of delegation from impersonating them. Our Protected Users post covers rolling it out without locking anyone out, including the break-glass account that stays outside the group.

3. Close what the newest path needs

Finish turning off RC4, which is the change that breaks the SPN-less chain. Setting MachineAccountQuota to 0 helps too because it removes the easy way to get the second account, although an attacker who already controls a computer or service account won't need it. Neither change does anything for "Use any authentication protocol." Steps 1 and 2 come first for that reason.

4. Use resource-based delegation for new setups

If a computer needs delegation going forward, the ASD and CISA guidance says to use resource-based constrained delegation. It still needs regular review. Our RBCD post shows how to do that.

Watch for the chain

The SPN-less chain leaves traces if you're watching for them:

• A password change or reset on an account with delegation, events 4723 and 4724.
• The same account suddenly failing for the app that uses it.
• New computer accounts created by regular users, event 4741.
• Writes to msDS-AllowedToActOnBehalfOfOtherIdentity, event 5136, once auditing is on for that attribute.

If you run Microsoft Defender for Identity, its alert for a suspicious Kerberos delegation attempt by a newly created computer fits the version of this chain that uses MachineAccountQuota.

Check constrained delegation with Insight Recon

Insight Recon's free, read-only Active Directory security assessment runs 155+ checks. These are the ones that matter for constrained delegation:

• SPN-less Constrained Delegation (High): "Use Kerberos only" entries on accounts with no SPN, the path from this post.
• Constrained Delegation through protocol transition enabled (High): accounts set to "Use any authentication protocol."
• Constrained Delegation Detected (Moderate): every account with a delegation list, for a full review.
• Privileged Users Allowed to Be Delegated (High) and Protected Users Group Not Utilized (Moderate): the admins any of these entries could impersonate.
• Non-administrative users can add computer accounts (High): MachineAccountQuota above 0.
• DES/RC4 Support Enabled (Moderate): the RC4 the SPN-less path needs.
• Unknown Account within Delegation (Moderate): delegation pointing at accounts that no longer resolve.

You can see what the findings look like in our sample report.

Constrained delegation checklist

• Does every account in the Check it now output have an owner and a reason?
• Is anything pointing at a service on a domain controller? Does it have to?
• Have you cleared the Kerberos only, no SPN entries nobody needs?
• Is protocol transition off everywhere it isn't required?
• Are your admins in Protected Users or marked sensitive?
• Is MachineAccountQuota set to 0?
• Is RC4 off domain-wide, with no accounts set to it explicitly?

If nobody can explain an entry that points at a domain controller, fix that one today.

Compliance mapping

Constrained delegation FAQ

References

• Hunter Wade, hun.io: Abusing Constrained Delegation without Protocol Transition against SPN-less accounts
• Sprocket Security: Abusing Constrained Delegation without Protocol Transition against SPN-less accounts
• Elad Shamir: Wagging the Dog, Abusing Resource-Based Constrained Delegation
• James Forshaw: Exploiting RBCD Using a Normal User Account
• Microsoft Learn: Kerberos constrained delegation overview
• Microsoft Learn: Protected Users security group
• Microsoft Learn: Microsoft Defender for Identity security alerts
• ASD, CISA, NSA and partners: Detecting and mitigating Active Directory compromises
• MITRE ATT&CK: T1558, Steal or Forge Kerberos Tickets
• MITRE ATT&CK: T1550.003, Pass the Ticket