Mitigating unconstrained delegation vulnerabilities

What “unconstrained delegation” actually means

Kerberos delegation exists so a front-end service (like a web server) can access a back-end service (like SQL) as the user. With unconstrained delegation, you are telling AD: “This computer/service is allowed to delegate to any service in the domain (Kerberos only).”

In practice, when a user authenticates to a host trusted for unconstrained delegation, that host can end up holding user credentials in the form of Kerberos tickets (including highly reusable tickets). If the host is compromised, those tickets can be abused to move laterally or impersonate users elsewhere.

Where you see and change these settings in the GUI: Active Directory Computer Delegation tab and the broader computer object property view: Active Directory (AD) Computer Object.

Why it’s dangerous: the real-world failure mode

Unconstrained delegation turns the delegated host into a high-value “ticket collection point.” If an attacker gains admin-level control of that host, they can often extract or reuse tickets present on it and impersonate users to other services—sometimes including privileged identities if they ever authenticate there.

Common ways it becomes a breach path

• Legacy app servers (IIS, middleware, old identity-integrated apps) left with unconstrained delegation “because it fixed auth.”
• Shared jump boxes / admin workstations mistakenly configured for delegation.
• Tier boundary violations: privileged admins log on interactively to servers that should never see admin sessions.
• Cross-forest / trust complexity where “just make it work” choices expand blast radius.

Trust boundaries matter here. If you’re operating in complex multi-forest/trust designs, also review SID filtering in complex AD layouts: expert guide & runbook to reduce “surprising” cross-boundary effects when hardening authentication flows.

Quick triage: decide what to fix first

Start with impact-based ordering. Fixing unconstrained delegation is not just “flip the checkbox”—it’s change management.

1. Any non-essential server/workstation with unconstrained delegation: remove immediately.
2. Internet-facing / DMZ-adjacent hosts: prioritize (they’re the easiest footholds).
3. Systems that admins log into (RDP, console, “temporary troubleshooting”): treat as critical.
4. App tiers that can be migrated to constrained delegation or RBCD: plan migration next.
5. Hard-to-change legacy apps: isolate and contain while building a migration path.

Inventory: find unconstrained delegation in your directory

You want to identify both computer accounts and user/service accounts that are “trusted for delegation.” Start with a read-only discovery run and produce a list you can validate with application owners.

PowerShell: identify computers trusted for delegation

# Requires RSAT ActiveDirectory module
Import-Module ActiveDirectory

# Computers with unconstrained delegation (TrustedForDelegation flag)
Get-ADComputer -Filter { TrustedForDelegation -eq $true } -Properties TrustedForDelegation,ServicePrincipalName,OperatingSystem |
  Select-Object Name, OperatingSystem, TrustedForDelegation, ServicePrincipalName |
  Sort-Object Name

LDAP filter (useful for tooling and SIEM pipelines)

Unconstrained delegation is often represented via the userAccountControl bit flag. Many orgs use directory search tooling to query:

(userAccountControl:1.2.840.113556.1.4.803:=524288)

Don’t forget service accounts

Some environments have user accounts (often service accounts) marked trusted for delegation.

Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)" -Properties ServicePrincipalName |
  Select-Object SamAccountName, Enabled, ServicePrincipalName |
  Sort-Object SamAccountName

Tip: As you review service identities, prefer modern managed identities where possible. For AD-integrated workloads, consider gMSA patterns; see Configure gMSA Defender Identity: Step-by-Step Guide for a practical example of moving away from static-password service accounts.

Mitigation options (choose the right replacement)

1) Remove unconstrained delegation entirely (best outcome)

If the system does not truly require delegation, set it to Do not trust this computer for delegation. This is the most robust fix because it removes the risky behavior instead of “scoping it.”

2) Move to constrained delegation (classic model)

Constrained delegation limits which back-end services a front-end service can delegate to. This is safer than unconstrained delegation, but it still needs strong hygiene: minimal scope, strict service list control, and change monitoring.

3) Move to Resource-Based Constrained Delegation (RBCD) (modern model)

RBCD shifts control to the target service (the back-end), letting it specify which principals may delegate to it. This model is often easier to manage at scale and can better match modern application ownership boundaries.

4) Containment when you can’t migrate yet

• Isolate the host (network segmentation, no admin browsing, minimal inbound paths).
• Block privileged interactive logons to the delegated host (tiering discipline).
• Use dedicated service identities (prefer gMSA where feasible).
• Harden the OS (credential protections, reduce local admin sprawl, disable unnecessary services).
• Monitor aggressively (see monitoring section below).

Protect the identities that matter most

Even if you are still cleaning up legacy delegation, you can reduce impact by preventing high-value accounts from being delegated in the first place.

Mark privileged accounts as “sensitive and cannot be delegated”

For Tier-0 and other high-impact accounts (Domain Admins, enterprise admins, key service operators, break-glass accounts), enable the user setting: Account is sensitive and cannot be delegated. This helps prevent their credentials/tickets from being delegated to other services.

Operational discipline: tiering and “where admins log on”

No checkbox replaces operational reality. If admins RDP into random servers to troubleshoot, those servers become credential exposure points. Treat any delegated host as higher sensitivity until fixed.

Remediation playbook (phased, low-drama)

Phase 0 — Map and validate

• Produce an inventory list (computer + user/service accounts).
• For each entry: document business owner, application dependency, and “why delegation exists.”
• Identify “easy wins” (unused, decommissioned, or misconfigured objects).

Phase 1 — Remove unconstrained delegation from everything that doesn’t need it

• Change the delegation setting to “Do not trust…” for low-risk targets.
• Regression test authentication flows (front-end to back-end).
• Document exceptions explicitly (no silent exceptions).

Phase 2 — Migrate remaining dependencies to constrained delegation or RBCD

• Prefer RBCD where it fits ownership boundaries and app architecture.
• Keep the allowed services list minimal and reviewed.
• Move away from static-password service accounts when possible (gMSA is often a strong step).

Phase 3 — Lock down privileged identity exposure

• Set “Account is sensitive and cannot be delegated” for high-value accounts.
• Enforce admin tiering (no interactive admin logons to app servers).
• Review where service operators and admins actually log in (reality > policy docs).

Phase 4 — Continuous monitoring and drift control

• Alert on any object changed to “trusted for delegation.”
• Run scheduled exports (daily/weekly) and diff against a known-good baseline.
• Require change tickets for any delegation-related modification.

Monitoring: how to detect delegation drift and suspicious behavior

Your goal is twofold: (1) detect configuration drift (someone re-enables unconstrained delegation), and (2) detect high-risk authentication patterns involving delegation-enabled hosts.

Monitor AD object changes

• Enable and collect Directory Service change auditing so you can alert when delegation-relevant attributes change (commonly via AD DS auditing event patterns such as “directory object modified”).
• Track changes to userAccountControl and delegation-related attributes on computer and service accounts.

Monitor Kerberos service ticket patterns

• Baseline normal service ticket requests from each app tier.
• Flag unusual spikes, new destinations, or “new” requesting hosts.
• Pay special attention to delegated hosts requesting tickets to sensitive services (e.g., domain controllers, management planes).

Use identity threat detection where available

If you run an identity detection platform (for example, sensors that understand AD authentication semantics), treat unconstrained delegation findings as “fix now” hygiene items—then keep the findings from returning via configuration monitoring.

Common mistakes that cause outages (and how to avoid them)

• Removing unconstrained delegation without knowing the dependency.
  Fix: Inventory first; validate with app owners; test in a controlled window.
• Replacing unconstrained with overly broad constrained delegation.
  Fix: Keep the allowed service list tight; document why each entry exists.
• Ignoring admin behavior.
  Fix: Stop privileged interactive logons to app servers; enforce tiering in practice.
• Letting “temporary fixes” become permanent.
  Fix: Time-box exceptions and track them like vulnerabilities.

Appendix: practical snippets

Export a baseline you can diff in CI / scheduled jobs

$computers = Get-ADComputer -Filter * -Properties TrustedForDelegation,userAccountControl |
  Select-Object Name, DistinguishedName, TrustedForDelegation, userAccountControl |
  Sort-Object Name

$computers | Export-Csv -NoTypeInformation ".\ad-delegation-baseline-computers.csv"

List SPNs for a delegation-enabled computer (helps app owners identify what runs there)

Get-ADComputer -Identity "APP-SRV-01" -Properties ServicePrincipalName |
  Select-Object -ExpandProperty ServicePrincipalName

Related reading (internal)

• Active Directory Computer Delegation tab
• Active Directory (AD) Computer Object
• NTLM authentication and Kerberos Authentication Protocols Explained
• Configure gMSA Defender Identity: Step-by-Step Guide
• SID filtering in complex AD layouts: expert guide & runbook