Unconstrained Kerberos Delegation Leaves a Reusable Ticket Trail

Kerberos delegation exists to let a service act for a user against another service. Constrained delegation narrows that authority to named services. Unconstrained delegation is broader: a service trusted this way can receive a forwarded ticket-granting ticket and use it to reach services beyond the immediate request. That design makes every unconstrained endpoint an attractive target.

Microsoft's documentation and security guidance treat unconstrained delegation as a legacy and high-risk configuration. The Windows Server Kerberos troubleshooting material describes scenarios in which it is used, while Microsoft's Active Directory hardening guidance recommends moving away from it. The practical question is not whether every use is malicious. It is whether the service truly needs the ability to impersonate users across arbitrary services, and whether the organization can detect abuse if the endpoint is compromised.

Why the ticket matters

Authentication establishes an initial ticket. Delegation can forward a ticket-granting ticket to a service. An attacker who gains suitable control of an unconstrained delegation endpoint may collect delegated tickets from users who connect to it, then use those tickets to access other resources. The exact outcome depends on the ticket, its lifetime, the target service, and the attacker's privileges. A compromised host with this configuration can turn an ordinary user visit into a broader authentication problem.

The risk is not limited to domain administrator accounts. Help-desk tools, file services, web applications, and management consoles can all become delegation targets. An inventory based only on server names will miss service accounts and computer objects with the delegation flag enabled.

Find and reduce the population

Start with a read-only directory query for accounts and computers configured for unconstrained delegation. Review the business owner, protocol, authentication method, and downstream services for each result. Remove the flag where it is not required. Prefer constrained delegation or a design that does not require the service to receive a reusable ticket-granting ticket. Protect the remaining endpoints as high-value assets with restricted administration, patching, network segmentation, and alerting.

Credential Guard and other platform controls can block some Kerberos behaviors, but they do not make an unsafe trust model safe. Microsoft's Credential Guard material notes that Kerberos unconstrained delegation is blocked in relevant configurations, yet compatibility and coverage vary by platform and environment. Treat that as defense in depth and verify the actual state rather than assuming a policy is active.

Detection and validation

Collect Kerberos authentication events and directory-service changes, including changes to delegation attributes. Alert on new unconstrained delegation flags, unusual ticket requests from an endpoint, and authentication to services that a given application does not normally use. Keep enough identity context to distinguish a legitimate administrative workflow from an unexpected one.

Validation should use a controlled lab or approved test environment. Confirm which accounts and computers still carry the flag, confirm that the expected business flow works after removal, and verify that alerting survives a directory change. Do not attempt to harvest or replay tickets in production. The goal is to reduce the population and make the remaining authority observable.

Unconstrained delegation is a useful reminder that authentication protocol features can encode authority long after the original application has changed. Removing the flag is a governance action, not only an Active Directory cleanup task.