Unconstrained Delegation Hiding on Service Accounts

The Trap

Unconstrained Kerberos delegation set directly on a service account rather than a computer object — the userAccountControl bit TRUSTED_FOR_DELEGATION (0x80000) applied to an account such as svc-sqlprod or svc-iisapp.

The Default State

Admins provisioning a legacy application that needs to hop credentials to a backend database or file share open the account’s Delegation tab in ADUC and select “Trust this user for delegation to any service (Kerberos only)” because it is the option that just works, rather than configuring msDS-AllowedToDelegateTo for constrained delegation. The account keeps a static password, an SPN registered against it, and runs an IIS application pool or a Windows service across several member servers. No one revisits the setting once the application ships, and delegation reviews during audits typically enumerate computer objects for unconstrained delegation, skipping user accounts entirely.

The Blast Radius

Any Kerberos ticket a caller presents to a process running under that account arrives with a full, forwardable TGT copy, cached in LSASS on whichever host the service is running. If a Tier-0 admin, backup operator, or help-desk account with elevated rights ever authenticates through that service — browsing the IIS site, connecting to the SQL instance, or triggering the scheduled task — their TGT sits extractable via sekurlsa::tickets on that box. Because the flag lives on the account, not the host, every server that runs the service inherits the same harvesting surface: a cluster of four IIS nodes means four separate places an attacker can lift the same admin’s ticket. The stolen TGT then impersonates that admin against any service in the domain, not just the delegating application, for the remaining lifetime of the ticket.

The Lead Mechanic Fix

Audit first: Get-ADObject -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=524288)' -Properties sAMAccountName,ServicePrincipalName. Migrate each hit to resource-based constrained delegation bound to a group-managed service account so credentials never sit extractable: Install-ADServiceAccount plus Set-ADComputer -PrincipalsAllowedToDelegateToAccount on the target resource, then clear the flag with Set-ADAccountControl -TrustedForDelegation $false. Place every Tier-0 and admin account in Protected Users, or set “Account is sensitive and cannot be delegated,” so no delegation type — constrained or not — can forward their ticket.