A server configured for unconstrained delegation stores a usable ticket for every account that authenticates to it, including domain administrators and domain controllers. Compromise that one server and you can impersonate whoever connects next. The joint advisory on detecting and mitigating Active Directory compromises, published in September 2024 by allied cyber security agencies including the NCSC, lists delegation abuse among the techniques defenders most often overlook.
What the setting actually does
Delegation exists so a front-end service can act on a user’s behalf against a back end, such as a web application reaching a database as the signed-in user. The unconstrained version is the original implementation and it places no limit on where that impersonation may be used. When a user authenticates, their ticket-granting ticket is cached on the server, and anyone with local administrator rights there can extract it. Constrained delegation and its resource-based successor exist precisely because the unconstrained form gives away far more than the scenario requires.
Turning it into domain compromise
The attack does not wait for an administrator to log in. A tester with access to the delegation server coerces an authentication from a chosen target, using a remote procedure call that makes a machine connect back, which has been possible through several protocol paths over the years. Coerce a domain controller and its ticket lands in the cache, which leads directly to full domain compromise. That is why the finding is rated critical even when the delegation server itself looks unimportant: a print server or an old web front end can become the shortest route to the domain.
“Clients often tell me delegation was set up years ago for an application that no longer exists. Nobody removed the flag because nobody knew what it did. Run the query, list every account with unconstrained delegation, and treat each one as a tier zero asset until you have removed the setting and confirmed nothing broke.”
William Fieldhouse, Director, Aardwolf Security Ltd
Finding it in your own directory
The query is short and worth running today. Search Active Directory for computer and user accounts with the trusted for delegation flag set, and expect domain controllers to appear, since they hold it legitimately. Anything else on the list needs an owner and a justification. Check for constrained delegation entries at the same time, because a service allowed to delegate to a sensitive target is a smaller version of the same problem. Record what you find with the application it supports, since removing delegation from a live service without knowing what it does is how you cause an outage.
Removing it safely
Migrate rather than switch off blindly. Resource-based constrained delegation puts control at the target service and covers most modern scenarios, so work with the application owner to move to it. Add sensitive accounts to the Protected Users group and mark them as not delegated, which prevents their tickets from being cached even if a delegation server remains. Patch and disable the coercion paths you do not need, including the print spooler service on servers that do not print. An internal network security assessment will show whether the remaining configuration can still be chained, and it is worth asking penetration testing firms directly whether their internal methodology covers delegation, because plenty of reports never mention it.
Frequently asked questions about delegation
These questions follow an internal test that flags this configuration.
Is constrained delegation safe?
Safer, not safe by default. It limits impersonation to named services, so the impact of compromising the delegating host is contained. It still deserves review, particularly where the target service is sensitive.
How urgent is this finding?
Treat it as urgent. It requires local administrator rights on the delegating host, which is often easier to obtain than people assume, and the outcome is full domain compromise rather than a step towards it.
