Unconstrained Kerberos Delegation on a Service Account Grants Domain-Wide Impersonation

Symptom

A service account running a legacy application on a member server shows "Trust this computer for delegation to any service (Kerberos only)" enabled on its Active Directory computer or service account object. Nothing in the AD Users and Computers delegation tab, or in the default Active Directory Administrative Center view, indicates that this setting differs materially from constrained delegation. Administrators reviewing the account see a single checked box under the Delegation tab and move on, because the interface presents unconstrained delegation as just another delegation mode rather than as a distinct, high-risk trust relationship.

The operational trigger is usually unremarkable: a help desk ticket asks why a privileged user’s credentials appear to be usable from an unrelated server, or a security review flags Kerberos ticket-granting-ticket (TGT) material cached on a host that has no business holding it. There is no error message, no failed login, and no obvious audit alert unless Windows Security auditing for Kerberos ticket events is explicitly enabled and reviewed.

False assumption

The misleading assumption is that Kerberos delegation settings are scoped by default and that "delegation" inherently means the receiving service can only act on behalf of a user for the specific application it was configured for. Administrators frequently assume the checkbox they see is equivalent to constrained delegation ("Trust this computer for delegation to specified services only"), because both options live under the same UI tab and both are described using the word delegation. In practice, unconstrained delegation grants the host itself the ability to cache and reuse the full TGT of any user who authenticates to any service on that host using Kerberos, not just the application the administrator intended to support.

A second embedded assumption is that legacy compatibility settings are inert unless actively exploited. Teams often leave unconstrained delegation enabled after a migration "just in case" the legacy behaviour is still needed, believing that an unused permission carries no operational risk until it is deliberately invoked. Kerberos delegation does not require deliberate exploitation by the account owner: any authenticated session that reaches the flagged host deposits reusable ticket material there automatically.

Root cause

The root cause is that unconstrained Kerberos delegation was enabled on the service account or computer object, most often during a legacy application migration, and was never revisited once the application’s actual delegation requirements were understood. Unlike constrained delegation, which requires an explicit list of target services (msDS-AllowedToDelegateTo) or resource-based constrained delegation (msDS-AllowedToActOnBehalfOfOtherIdentity) scoped to specific back-end resources, unconstrained delegation has no service list at all. Any Kerberos-authenticated user session that reaches the trusted host causes their TGT to be forwarded and cached in that host’s LSASS memory, where it becomes available to anything with sufficient privilege on that host, including malware or a compromised local administrator.

This is a configuration trap rather than a simple misconfiguration because the delegation tab presents the unconstrained option with equal visual weight to constrained delegation, and because the setting’s danger is contingent on who authenticates to the host, not on the account’s own behaviour. A host that appears low-value on the day it is configured can become high-value later if a Domain Admin, a backup service account, or a certificate authority operator ever logs into it interactively or via a Kerberos-authenticated service, at which point their ticket material is exposed regardless of intent.

Impact

The operational consequence is that any account (including highly privileged ones) whose Kerberos session reaches the flagged host has its TGT cached there, giving anyone with sufficient access to that host the means to impersonate that account domain-wide until the ticket expires or is revoked. This converts what looks like a scoped legacy application server into a domain-wide privilege escalation point. Microsoft’s cloud security benchmark identifies identity and privileged access control as a core control domain precisely because trust relationships of this kind extend the effective blast radius of a single host compromise across the whole identity boundary rather than containing it to the host itself.

Because there is no failed authentication, no application error and no default alert, the exposure typically persists for the lifetime of the account and is discovered only through a dedicated Kerberos delegation audit, a privileged access review, or after an incident where lateral movement patterns are traced back to ticket-caching behaviour on the flagged host.

Diagnosis

Diagnosis is read-only and does not require touching the delegation setting itself. Confirm the account’s delegation type and cross-reference it against which privileged accounts have authenticated to the host recently.

Correction

The correction replaces unconstrained delegation with resource-based constrained delegation (RBCD) scoped to only the specific back-end service the legacy application requires, or with classic constrained delegation restricted to an explicit service list, after confirming the exact target service principal names the application actually needs. Do not disable delegation outright as a first step in a live environment without first confirming the replacement scope, since removing delegation entirely will break the legacy application’s ability to authenticate onward to its dependency, and that failure will be immediate for every user of the application, not gradual.

Validation

Validation must confirm both that the unconstrained flag is cleared and that the legacy application still authenticates onward successfully using the new constrained or resource-based scope, in the isolated or non-production environment first.

Rollback

Rollback restores the prior delegation state only if the constrained replacement breaks the legacy application’s downstream authentication, and must be time-boxed to the maintenance window with the original state captured before any change.

Prevention

Add unconstrained delegation detection to the recurring privileged access review: any account or computer object with TrustedForDelegation set to true, other than domain controllers, should be treated as a finding requiring justification, not a default. Require that any legacy application onboarding request specify the exact back-end service it needs before delegation of any kind is granted, so that constrained or resource-based scoping is the default starting point rather than a later remediation. Where the legacy application vendor cannot confirm its actual delegation target, treat that as a vendor risk finding and escalate to the application owner rather than defaulting to the broadest permission to make the ticket close faster.