How to find unconstrained delegation in Active Directory: Find it, remove it and keep it gone

Any computer or service account trusted for unconstrained delegation receives a reusable copy of the Kerberos ticket of every user who authenticates to it, so one compromised server can hand an attacker a domain administrator's identity. The setting is a single bit in the userAccountControl attribute, it is easy to tick in the Delegation tab and it is rarely removed once a project ends. This runbook shows how to find every account with the flag, separate the expected cases (domain controllers) from the risky ones, move each workload to constrained or resource-based constrained delegation, and stop new instances appearing. It is for Active Directory administrators, identity engineers and security teams running a clean-up or preparing for an audit. For the design side of delegation, see the Kerberos Delegation Security Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Confirm cmdlet behaviour against Microsoft's current documentation before changing production accounts.

Key takeaways

• Search for one bit. Unconstrained delegation is TRUSTED_FOR_DELEGATION, value 0x80000 (524288) in userAccountControl. The PowerShell property is TrustedForDelegation.
• Check users as well as computers. The flag can sit on a user account that runs a service, and those accounts often have weak, old passwords.
• Domain controllers are the expected exception. They carry the flag by design; everything else needs a named owner and a reason, or it goes.
• Protect the identities you cannot afford to lose. Set "Account is sensitive and cannot be delegated" (NOT_DELEGATED, 0x100000) on privileged users, or add people to Protected Users, so their tickets are never forwarded.
• Watch event 4742 and 4738. A change that enables "Trusted For Delegation" on a computer or user should raise an alert, because re-enabling is the most common way the problem returns.

When you need this

• Attack path reduction: unconstrained delegation hosts are a classic step in attack paths. An attacker who controls such a host and can make a domain controller or administrator authenticate to it (authentication coercion, ATT&CK T1187 Forced Authentication) can extract the forwarded ticket and reuse it (T1550.003 Pass the Ticket). See Authentication Coercion Defence.
• Security posture findings: Microsoft Defender for Identity reports "Unsecure Kerberos delegation" for non-domain controller entities, and many AD assessment tools flag the same condition.
• Audit and hardening programmes: least privilege (NIST SP 800-53 AC-6) and secure configuration (CM-6) apply directly to delegation settings.
• Before tiering or migration work: a server that holds forwarded tickets of administrators is effectively Tier 0. Finding these hosts early prevents a tiering model that looks clean on paper.

Before you start

How the three delegation types show up in the directory

Microsoft describes TRUSTED_FOR_DELEGATION as meaning that any service running under that account "can impersonate a client requesting the service". The opposite protection, NOT_DELEGATED, means the user's security context is not delegated even when the service account is trusted for delegation.

Access, tools and agreements

• Read access: any authenticated domain user can read userAccountControl, so discovery needs no special rights. Run it from an administrative workstation with the Active Directory PowerShell module (RSAT).
• Write access: changing delegation settings on an account requires the right to modify it, and enabling unconstrained delegation requires the Enable computer and user accounts to be trusted for delegation user right (SeEnableDelegationPrivilege), which by default only administrators on domain controllers hold. Keep it that way.
• Logging: enable the advanced audit subcategories Audit Computer Account Management (event 4742) and Audit User Account Management (event 4738) on domain controllers before you begin, so your own changes and any regressions are recorded.
• Change approach: agree with application owners that each host will move to constrained delegation or RBCD, with a test window and a rollback, rather than simply clearing the flag on a Friday.

Step-by-step

Steps 1 to 4 are read-only. Steps 5 and 6 change accounts but are reversible. Step 7 adds prevention.

1. Find computer accounts trusted for unconstrained delegation. Use the bitwise AND matching rule (OID 1.2.840.113556.1.4.803) against userAccountControl:

   Get-ADComputer -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)" `
     -Properties TrustedForDelegation, OperatingSystem, LastLogonDate, ManagedBy, Description |
     Select-Object Name, OperatingSystem, LastLogonDate, ManagedBy, Description

   The equivalent PowerShell filter is Get-ADComputer -Filter {TrustedForDelegation -eq $true}. The LDAP form is portable to other tools such as ldapsearch or an AD auditing product.
2. Separate domain controllers. Domain controller accounts carry SERVER_TRUST_ACCOUNT (0x2000, 8192) and the flag by design. Exclude them so the remaining list is your problem set:

   Get-ADComputer -LDAPFilter "(&(userAccountControl:1.2.840.113556.1.4.803:=524288)(!(userAccountControl:1.2.840.113556.1.4.803:=8192)))" `
     -Properties OperatingSystem, LastLogonDate

   Read-only domain controllers do not normally carry the flag; if one does, investigate.
3. Find user accounts trusted for unconstrained delegation. Service accounts running under a user object can carry the same bit:

   Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)" `
     -Properties TrustedForDelegation, ServicePrincipalName, PasswordLastSet, LastLogonDate, Enabled

   A user account with this flag and an old password combines two weaknesses: its ticket can be requested and cracked offline (see the Kerberoasting and AS-REP Roasting Defence Guide), and the cracked account then receives forwarded tickets.
4. Enrich each result and find the owner. For each account record: what runs on the host (IIS with Windows authentication, a reporting server, a file or print server, a legacy middleware tier), which back-end services it needs to reach as the user, its ManagedBy and description, whether it is still in use (LastLogonDate), and whether it is in a privileged tier. Also list the protected side:

   Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=1048576)" | Select-Object SamAccountName
   Get-ADGroupMember -Identity "Protected Users" -Recursive | Select-Object SamAccountName

   Compare these with your privileged group membership. Every Domain Admin, Enterprise Admin and other Tier 0 user that is in neither list is exposed if it ever authenticates to an unconstrained host.
5. Protect privileged users first (reversible). This step lowers risk immediately without touching any application:

   Set-ADAccountControl -Identity <admin-account> -AccountNotDelegated $true

   For interactive human administrators, Protected Users also blocks delegation along with NTLM and weak Kerberos encryption. Microsoft warns never to add service or computer accounts to Protected Users, so use NOT_DELEGATED for those instead. Test one admin account first: sensitive accounts cannot be delegated by any service, so an administrator who relied on delegation through a web console will see that feature fail.
6. Replace unconstrained delegation on each host (reversible). Work with the owner to choose the replacement:
   • Constrained delegation: in Active Directory Users and Computers, on the account's Delegation tab, choose Trust this computer for delegation to specified services only and list only the SPNs the service genuinely needs (for example MSSQLSvc/db01.corp.example:1433). Choose Use Kerberos only unless the application needs protocol transition.
   • RBCD: set the trust on the back-end resource instead, for example Set-ADComputer -Identity <backend> -PrincipalsAllowedToDelegateToAccount (Get-ADComputer <frontend>). Microsoft documents that RBCD lets the resource owner, not the domain administrator, decide which front ends may delegate to it, and that it works across domains.
   • No delegation: many flags are leftovers. If the owner cannot name a back-end service accessed as the user, clear it.
   Then clear the flag:

   Set-ADAccountControl -Identity "<computer-name>$" -TrustedForDelegation $false

   Record the original userAccountControl value and delegation settings in the change ticket before you do.
7. Prevent new instances. Keep SeEnableDelegationPrivilege limited to domain controller administrators, alert on events 4742 and 4738 that show "Trusted For Delegation" enabled, and add the discovery query from step 2 to a scheduled report that must return zero non-DC rows.

Verify it worked

• Directory state: the step 2 and step 3 queries return only domain controllers and documented exceptions.
• Application behaviour: the owner confirms that the double-hop function (for example a web front end querying SQL Server as the signed-in user) still works under constrained delegation or RBCD.
• Audit trail: event 4742 on a domain controller shows "'Trusted For Delegation' - Disabled" for each computer you changed, and the AllowedToDelegateTo field lists the new SPNs where you configured constrained delegation.
• Protection coverage: every privileged user is either marked sensitive or in Protected Users.
• Posture tools: Defender for Identity's "Unsecure Kerberos delegation" assessment no longer lists the host. Microsoft notes that impacted entity lists update within minutes but the assessment status can take longer, as scores refresh every 24 hours.

Rollback and common errors

Clearing the flag does not invalidate tickets already cached on the host. If you suspect the host was compromised, treat any administrator who signed in to it as exposed: reset their credentials and follow the Active Directory Domain Compromise Response Playbook.

Choosing the replacement

Small organisation: often there are only a handful of non-DC results, typically old print or file servers, and most can simply be cleared after a check with the owner. Large estate: expect dozens, many owned by teams that have changed. Prioritise hosts where privileged users authenticate, hosts exposed to user networks, and user accounts with the flag, and run the work as a tracked programme with a weekly report.

Where identity fits

Every unconstrained host is a machine identity with an outsized privilege: the right to act as anyone who connects. User-type service accounts with the flag are non-human identities that usually have no owner, never-expiring passwords and SPNs. Move them to group managed service accounts where the application supports it (see How to convert AD service accounts to gMSA), record the remaining delegation rights in your service account inventory, and review them in the same cycle as other machine entitlements.

Detection and measurement

Metrics that show the programme is working:

• Non-DC accounts with unconstrained delegation: target zero, or a short, documented exception list.
• Privileged users protected from delegation: percentage of Tier 0 users marked sensitive or in Protected Users; target 100%.
• Constrained delegation entries targeting domain controller services: target zero.
• Time to detect a re-enabled flag: from event to alert triage; aim for the same day.
• Exceptions past review date: target zero.

Framework mapping

Common failure patterns

• Only checking computers: user service accounts with the flag are missed, and they are often the easiest to crack.
• Clearing the flag without a replacement: the application breaks, the change is reverted in a hurry, and the flag is never revisited.
• Swapping to protocol transition everywhere: constrained delegation with "Use any authentication protocol" plus a list that includes domain controller services is barely safer than what it replaced.
• Adding service accounts to Protected Users: Microsoft advises against it; it gives no protection for those accounts and can break the services that use them.
• Ignoring coercion: leaving services that can be forced to authenticate (for example the Print Spooler on domain controllers) running means any remaining unconstrained host can still collect a domain controller ticket.
• No owner of the exception list: documented exceptions grow, never expire, and the metric loses meaning.

Practitioner checklist

• Enable auditing for computer and user account management on all domain controllers.
• Run the LDAP bitwise query for 524288 against computers and users and exclude domain controllers.
• Record owner, purpose, back-end SPNs and last logon for every result.
• Mark every privileged user as sensitive or add human administrators to Protected Users.
• Replace each unconstrained setting with constrained delegation, RBCD or nothing, and test with the owner.
• Clear the flag and keep the original value in the change ticket for rollback.
• Limit SeEnableDelegationPrivilege to domain controller administrators.
• Alert on 4742 and 4738 events that enable delegation flags.
• Schedule the discovery query and track the metrics monthly.

Standards and references

• Microsoft: Use the UserAccountControl flags to manipulate user account properties
• Microsoft: Kerberos constrained delegation overview
• Microsoft: Set-ADAccountControl
• Microsoft: Search Filter Syntax
• Microsoft: Protected Users security group
• Microsoft: 4742(S) A computer account was changed
• Microsoft: Defender for Identity accounts security posture assessments
• MITRE ATT&CK: Forced Authentication

Related NHI Mgmt Group resources: Kerberos Delegation Security Guide · Authentication Coercion Defence · BloodHound and Active Directory Attack Path Guide · Active Directory Delegation · How to find service accounts with Domain Admin rights