Unconstrained Delegation in Active Directory

Unconstrained delegation is a legacy Kerberos delegation setting in Active Directory that allows a trusted service to impersonate users to other services. It was designed to support multi-tier applications, but it can create serious security risk if the trusted server or service account is compromised. A server trusted for unconstrained delegation may be able to reuse delegated Kerberos credentials to access other services as the user.

That can be dangerous because a compromised server with unconstrained delegation may allow an attacker to capture or reuse Kerberos tickets from users who authenticate to it. If a privileged user connects to that server, the impact can become much more serious.

What is Kerberos delegation?

Kerberos delegation allows a service to access another service on behalf of a user.

This is useful for multi-tier applications. For example:

A user accesses a web application.
The web application needs to query a database.
The database should see the request as coming from the user, not just from the web server.
Kerberos delegation allows the web application to act on behalf of the user when connecting to the database.

Delegation is not automatically bad. Some applications legitimately need it. The risk depends on how broadly delegation is allowed, what account is trusted for delegation, and what privileges users have when they authenticate to the delegated service.

What is unconstrained delegation?

Unconstrained delegation is the broadest and riskiest form of Kerberos delegation.

When an account is trusted for unconstrained delegation, the service can impersonate users to other services without being limited to a specific downstream service. Microsoft’s UserAccountControl documentation describes the TRUSTED_FOR_DELEGATION flag as allowing the service account, either a user or computer account, to impersonate a client requesting the service.

In Active Directory Users and Computers, this setting appears on the Delegation tab as: Trust this user for delegation to any service (Kerberos only)

For computer accounts, it may appear as: Trust this computer for delegation to any service (Kerberos only)

Why unconstrained delegation matters

Unconstrained delegation matters because it can turn a compromised server into a credential theft and impersonation point.

If a server trusted for unconstrained delegation is compromised, an attacker may be able to abuse Kerberos tickets from users who authenticate to that server. If a normal user authenticates, the attacker may gain access to resources available to that user. If a privileged user authenticates, the attacker may gain much more powerful access.

This is especially risky when unconstrained delegation is configured on:

Application servers
Web servers
Database servers
File servers
Print servers
Legacy middleware servers
Service accounts
Any system where privileged users might authenticate

Microsoft Defender for Identity treats insecure Kerberos delegation as an identity security posture issue and describes unsecure delegation as giving an entity the ability to impersonate a user to other services.

How attackers abuse unconstrained delegation

A typical unconstrained delegation abuse scenario looks like this:

An attacker compromises a server trusted for unconstrained delegation.
A user authenticates to that server using Kerberos.
The server receives delegated Kerberos material.
The attacker extracts or reuses that material from the compromised server.
The attacker impersonates the user to other services.
If the user is privileged, the attacker may move laterally or escalate access.

MITRE ATT&CK tracks Kerberos ticket theft and abuse under Steal or Forge Kerberos Tickets, T1558, and Pass-the-Ticket under T1550.003. Both are relevant to understanding why delegated Kerberos material is valuable to attackers.

Why privileged users make this worse

Unconstrained delegation becomes much more dangerous when privileged users authenticate to a delegated server.

Examples include:

Domain Admins logging into an application server
Server administrators connecting interactively
Help desk or operations accounts accessing delegated systems
Backup operators authenticating to infrastructure servers
Service accounts with broad access connecting to the server

If a highly privileged account authenticates to a compromised unconstrained delegation server, the attacker may be able to impersonate that account to sensitive services.

User accounts vs computer accounts

Unconstrained delegation can be configured on both user accounts and computer accounts.

Computer accounts

Computer accounts are commonly involved because servers hosting applications may be trusted for delegation. A computer account configured for unconstrained delegation means services running on that computer may be able to impersonate users broadly.

User accounts

User accounts can also be configured for unconstrained delegation, usually when a service runs under a domain user account. This is especially risky if the service account has broad privileges or if the account is used by multiple systems.

Domain controllers and unconstrained delegation

Domain controllers are special. They are highly trusted systems and commonly show delegation-related flags because of how domain controller authentication works. Do not treat domain controllers the same way you treat ordinary application servers.

The real concern is usually non-domain-controller systems configured for unconstrained delegation. When reviewing unconstrained delegation, separate results into:

Domain controllers
Non-domain-controller computer accounts
User service accounts

This prevents domain controllers from hiding the more actionable findings.

How to find unconstrained delegation with PowerShell

You can identify computer accounts trusted for unconstrained delegation with:

Get-ADComputer -Filter { TrustedForDelegation -eq $true } `
    -Properties TrustedForDelegation, OperatingSystem, LastLogonDate |
    Select-Object Name, DNSHostName, OperatingSystem, LastLogonDate, TrustedForDelegation

To exclude domain controllers:

$DomainControllers = Get-ADDomainController -Filter * | Select-Object -ExpandProperty ComputerObjectDN

Get-ADComputer -Filter { TrustedForDelegation -eq $true } `
    -Properties TrustedForDelegation, DistinguishedName, OperatingSystem, LastLogonDate |
    Where-Object { $DomainControllers -notcontains $_.DistinguishedName } |
    Select-Object Name, DNSHostName, OperatingSystem, LastLogonDate, TrustedForDelegation

To find user accounts trusted for unconstrained delegation:

Get-ADUser -Filter { TrustedForDelegation -eq $true } `
    -Properties TrustedForDelegation, ServicePrincipalName, PasswordLastSet, LastLogonDate |
    Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, ServicePrincipalName, TrustedForDelegation

To find enabled user accounts with SPNs and unconstrained delegation:

Get-ADUser -Filter { TrustedForDelegation -eq $true -and Enabled -eq $true } `
    -Properties TrustedForDelegation, ServicePrincipalName, PasswordLastSet |
    Where-Object { $_.ServicePrincipalName } |
    Select-Object SamAccountName, PasswordLastSet, ServicePrincipalName, TrustedForDelegation

These commands identify where the setting exists. They do not prove exploitation. The next step is to determine whether each result is required, who owns it, and what users authenticate to it.

Graphical Option to check the setting

You can also check the setting in Active Directory Users and Computers.

Open Active Directory Users and Computers.
Enable Advanced Features from the View menu.
Find the computer or user account.
Open Properties.
Go to the Delegation tab.
Review the selected delegation option.

The risky option is: Trust this user/computer for delegation to any service (Kerberos only)

A safer configuration is usually constrained delegation, resource-based constrained delegation, or no delegation, depending on the application requirement.

How to remediate unconstrained delegation

The preferred remediation is to remove unconstrained delegation unless there is a documented business requirement.

In Active Directory Users and Computers, change the Delegation tab setting to Do not trust this user/computer for delegation

For a computer account in PowerShell:

Set-ADAccountControl -Identity "SERVER01$" -TrustedForDelegation $false

For a user service account:

Set-ADAccountControl -Identity "svc-app" -TrustedForDelegation $false

Before making changes, confirm whether the application actually needs delegation. Removing delegation from a production service without testing can break multi-tier authentication.

Use constrained delegation instead

If delegation is required, use a more limited option. Constrained delegation allows administrators to specify which services the account can delegate to. Microsoft describes Kerberos constrained delegation as a way to limit the scope of delegation and enforce application trust boundaries.

In many cases, the safer choices are:

No delegation
Kerberos constrained delegation
Resource-based constrained delegation
Application redesign to avoid broad delegation

Protect privileged accounts from delegation

Privileged accounts should be configured so they cannot be delegated.

In Active Directory Users and Computers, this is the account option: Account is sensitive and cannot be delegated

This setting helps prevent the account from being delegated to services.

Use it for accounts such as:

Domain Admins
Enterprise Admins
Schema Admins
Highly privileged service accounts
Tier 0 administration accounts
Sensitive administrative accounts

Also consider placing privileged accounts in the Protected Users group where appropriate, after testing compatibility.

Detection opportunities

Detection should focus on both configuration and behavior.

Configuration detection

Look for:

Non-domain-controller computers trusted for unconstrained delegation
User service accounts trusted for unconstrained delegation
Privileged accounts that are not marked as sensitive and cannot be delegated
Delegation settings added or modified recently
Servers with unconstrained delegation that are exposed to broad user access

Behavioral detection

Monitor for:

Unusual Kerberos service ticket requests
Authentication by privileged users to unconstrained delegation servers
Service ticket requests from unexpected systems
Pass-the-Ticket behavior
Lateral movement after Kerberos authentication
Changes to delegation-related attributes

Useful Windows Security events include:

Event ID	Purpose
4769	A Kerberos service ticket was requested
4738	A user account was changed
4742	A computer account was changed
5136	A directory service object was modified

Event ID 4769 is useful for Kerberos service ticket activity. Events 4738, 4742, and 5136 can help identify account and directory object changes related to delegation settings.

Common mistakes

Assuming unconstrained delegation is always required

Many environments have unconstrained delegation because of legacy configuration, old troubleshooting, or application history. It should be reviewed, not assumed necessary.

Removing delegation without testing

Some applications may depend on delegation. Test changes before removing delegation from production service accounts or servers.

Ignoring user service accounts

Computer accounts are common, but user service accounts can also be trusted for unconstrained delegation. Review both.

Treating domain controllers like normal findings

Domain controllers are special and should be reviewed separately. Focus remediation on non-domain-controller systems and user service accounts.

Allowing admins to log into delegated servers

If privileged users authenticate to servers trusted for unconstrained delegation, the risk increases significantly. Administrative access patterns matter.

Fixing delegation but ignoring privilege

Removing unconstrained delegation is important, but service account privileges should still be reviewed. A highly privileged service account remains risky even after delegation is corrected.

Practical recommendation

A practical unconstrained delegation reduction plan should include:

Identify all accounts trusted for unconstrained delegation.
Separate domain controllers from non-domain-controller systems.
Review all user service accounts with unconstrained delegation.
Confirm application ownership and business need.
Remove unconstrained delegation wherever it is not required.
Replace it with constrained delegation or resource-based constrained delegation where needed.
Mark privileged accounts as sensitive and not delegable.
Reduce privileged logons to application servers.
Monitor changes to delegation settings.
Recheck regularly as part of Active Directory hygiene.

The long-term goal should be to eliminate unconstrained delegation from ordinary servers and user service accounts.

Summary

Unconstrained delegation is a legacy Kerberos delegation setting that can create serious security exposure in Active Directory. It allows a trusted service to impersonate users broadly, which can become dangerous if the trusted server or service account is compromised.

The highest-risk scenarios involve non-domain-controller servers, user service accounts, privileged users, and systems where administrators commonly authenticate. Defenders should identify unconstrained delegation, validate whether it is required, remove it where possible, replace it with constrained alternatives when necessary, and protect privileged accounts from delegation.

Unconstrained delegation should be rare in a modern Active Directory environment. When it exists, it should be documented, monitored, and justified.