Unconstrained Kerberos Delegation: Finding and Fixing It with PowerShell
- Chris Keim
- 5 hours ago
- 6 min read
In This Article:
Unconstrained Kerberos delegation is one of the most dangerous misconfigurations in Active Directory, and it still found surprisingly often in legacy or environments that are not reviewed often. When a computer account is configured for unconstrained delegation, the user’s forwardable Kerberos credentials can be delegated to that host, where the TGT is cached in memory for reuse. The server caches it. An attacker with local admin on that machine can dump cached Kerberos tickets from memory and impersonate users who authenticated there, including privileged administrators.
This isn't a theoretical edge case. It's a well-documented lateral movement and privilege escalation technique with real-world usage. Domain controllers are a special case in Kerberos and are commonly treated as trusted for delegation, which is why attacks like Printer Bug + unconstrained delegation are so severe. In most environments I've reviewed, additional servers have it enabled, often left behind by legacy application requirements or by someone checking a box without understanding the security impact.
This article is for AD administrators who want to understand what unconstrained delegation is, find every account configured for it in their environment, and remediate what doesn't belong. You don't need a pen testing background, just PowerShell and access to Active Directory
How Unconstrained Kerberos Delegation Works
Kerberos delegation is a legitimate feature that allows a service to act on behalf of a user when accessing other resources. A common example is a web application that connects to a back-end database using the authenticated user’s identity.
In Active Directory, the three primary delegation models are unconstrained delegation, constrained delegation, and resource-based constrained delegation (RBCD). Unconstrained delegation is the oldest and highest-risk model.
When a user authenticates to a service running on a machine trusted for unconstrained delegation, Kerberos allows that server to obtain and cache a forwardable copy of the user’s TGT in LSASS memory. The server can then request service tickets to other Kerberos services as that user, without any delegation scope restrictions beyond the user’s existing permissions.
If an attacker gains local administrator access to a machine configured for unconstrained delegation, tools such as Mimikatz or Rubeus can be used to extract cached tickets from LSASS. If a highly privileged account authenticated to that system, even briefly through administration, automation, file access, or remote management, those credentials may be abused and can often lead to full domain compromise.
The attack becomes even more dangerous when combined with coercion techniques such as the printer bug (MS-RPRN). An attacker can force a domain controller to authenticate to a compromised host trusted for unconstrained delegation by triggering a print-related notification request. When that happens, the domain controller’s Kerberos credentials for its computer account may be cached on the target system. Because domain controllers are highly privileged security principals with replication-related privileges, compromise of those credentials can often lead to full domain compromise.
Who Is Configured for Unconstrained Delegation?
Unconstrained delegation is controlled by the "TRUSTED_FOR_DELEGATION" flag on computer and user accounts in Active Directory.
Domain controllers are typically trusted for delegation by design. This is expected because domain controllers require delegation-related behavior for core Kerberos and Active Directory operations. Any non-domain-controller computer or user account with this setting should be treated as a potential exposure point and explicitly justified.
Common sources of non-DC unconstrained delegation in production environments:
Legacy application servers — older middleware, SharePoint farms, SQL Server deployments, and line-of-business applications where delegation was enabled during setup and never revisited.
Service accounts — user accounts trusted for unconstrained delegation, which can be particularly risky when they use static passwords, shared ownership, or weak lifecycle controls.
Any non-DC system with unconstrained delegation enabled can become a pivot point. If an attacker gains local administrator access to that host, they may be able to extract cached delegated credentials for privileged users who authenticated to it and use those credentials for lateral movement or escalation.
Finding Unconstrained Delegation with PowerShell
This script queries Active Directory for all computer and user accounts with the TRUSTED_FOR_DELEGATION flag set, filters out domain controllers, and surfaces everything else:
No elevated rights required, standard domain user access is sufficient to query these attributes.
Interpreting Results
Domain controllers — filtered out by the script. Expected and required.
Legacy application servers — investigate. Determine whether the application actually requires unconstrained delegation or whether constrained delegation would work. Many legacy configurations used unconstrained delegation because it was easier to set up, not because it was necessary.
Jump servers or management hosts — treat as high priority. These machines see frequent privileged authentication, making their TGT cache extremely valuable to an attacker. Unconstrained delegation should never be enabled on management infrastructure.
User accounts — treat as a critical finding. There is almost no legitimate reason a user account needs unconstrained delegation. Remove the flag immediately and investigate how it was set.
Stale or inactive computer accounts — if LastLogonDate is more than 90 days ago, the account may be from a decommissioned system. Disable or remove the computer account and clean up the delegation flag.
Remediation
Migrate to constrained delegation. For any application that legitimately requires delegation, replace unconstrained delegation with constrained delegation or resource-based constrained delegation (RBCD). Configure delegation only to the specific backend services the application needs.
This removes the broad trust model associated with unconstrained delegation while preserving required functionality. Test application flows carefully during migration, especially where legacy authentication paths or double-hop scenarios exist.
Remove unconstrained delegation where it isn't needed. For any account where delegation isn't required at all, remove the flag entirely:
Enable the printer spooler mitigation. If you cannot immediately remove unconstrained delegation from all systems, disable the Print Spooler service on any machine configured for unconstrained delegation that does not require printing functionality.
This reduces attack surface and removes one of the most well-known coercion vectors used in printer bug (MS-RPRN) attacks. It should be treated as a compensating control while unconstrained delegation is being eliminated.
Add sensitive accounts to the Protected Users group. Members of the Protected Users security group receive additional authentication protections, including restrictions that prevent their credentials from being delegated to machines configured for unconstrained delegation.
Adding high-value accounts, such as Domain Admins, Enterprise Admins, Tier 0 administrators, and other privileged user identities to Protected Users helps reduce credential theft risk regardless of server configuration. Validate application and legacy authentication dependencies before broad deployment.
Detection
Event ID 4769 — Kerberos service ticket request
Event ID 4769 records Kerberos Ticket Granting Service (TGS) requests on domain controllers and is useful for identifying activity involving systems trusted for delegation.
When monitoring unconstrained delegation abuse, look for:
Ticket Options containing the Forwardable flag (exact values vary by scenario and OS version)
Service Name matching a non-domain-controller system configured for unconstrained delegation
High-value accounts requesting tickets to those systems
Unexpected client addresses or request patterns inconsistent with normal application behavior
Event ID 4624 — Logon to Delegation Hosts
Monitor successful logons to machines configured for unconstrained delegation, especially from privileged accounts. A Domain Admin or other Tier 0 administrator authenticating to an unconstrained delegation host is a high-value risk event worth alerting on.
Network logons (Type 3), remote administration activity, and interactive administrative access should all be reviewed in context.
SIEM / Behavioral Analytics
If you have network or log visibility into Kerberos activity, alert on unusual ticket behavior involving non-DC systems trusted for unconstrained delegation, such as:
Sudden privileged account activity
Abnormal ticket volume
Access outside normal hours
Requests involving domain controller computer accounts
Lateral movement patterns after privileged logon events
The goal is to detect suspicious use of delegation-enabled systems, not just normal Kerberos traffic.
Here's a PowerShell script to surface Event 4769 events with forwardable ticket options on domain controllers:
Prerequisites: Ensure Audit Kerberos Service Ticket Operations is enabled in your Default Domain Controllers Policy under Computer Configuration → Advanced Audit Policy Configuration → Account Logon.
Conclusion
Unconstrained delegation is dangerous because it is often overlooked until it is abused. A server in your environment with the "TRUSTED_FOR_DELEGATION" flag set may cache delegated credentials for privileged users who authenticate to it, creating a high-value target for anyone who gains local administrative access. Many organizations still have systems like this left behind from legacy application deployments and never revisited.
Run the audit script. Every non-domain-controller result should be reviewed as a potential credential theft and privilege escalation path. Migrate legitimate use cases to constrained delegation or resource-based constrained delegation, remove the flag where delegation is no longer required, and consider placing your highest-value administrative accounts in the Protected Users group after compatibility testing.
If you have not yet reviewed your Kerberoasting, AS-REP Roasting, and DCSync exposure, those should be next. They are common credential abuse paths that frequently intersect with the same Active Directory privilege escalation chains that make unconstrained delegation so dangerous.
Comments