Constrained Delegation in Active Directory

Constrained delegation is a Kerberos delegation setting in Active Directory that allows a service to impersonate users only to specific downstream services. It was introduced as a safer alternative to unconstrained delegation because it limits where delegated authentication can be used. The simplest way to think about constrained delegation is: A service can act on behalf of a user, but only to the specific services it has been allowed to access.

That restriction matters. With unconstrained delegation, a trusted service may be able to impersonate users broadly. With constrained delegation, administrators define the allowed destination services, which reduces the blast radius if the trusted server or service account is compromised.

What is Kerberos delegation?

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

This is common in multi-tier applications. For example:

A user accesses a web application.
The web application needs to query a backend SQL Server.
The SQL Server should receive the request in the context of the user.
Kerberos delegation allows the web application to request access to the backend service on behalf of that user.

Without delegation, the backend service may only see the identity of the web server or service account. With delegation, the user’s identity can be preserved across application tiers. Delegation is not automatically bad. It becomes risky when it is too broad, poorly documented, assigned to overprivileged accounts, or configured on systems that are not well protected.

What is constrained delegation?

Constrained delegation limits delegation to specific services.

In Active Directory Users and Computers, constrained delegation is usually configured with this option: Trust this user/computer for delegation to specified services only

Instead of allowing delegation to any service, the administrator selects the exact services the account is allowed to delegate to. These allowed services are stored as Service Principal Names, or SPNs.

For example, a web server might be allowed to delegate only to:

MSSQLSvc/sql01.example.com:1433

That means the web server can delegate user credentials to that SQL service, but not to every other service in the domain.

Microsoft’s constrained delegation overview explains that constrained delegation restricts the services to which the specified server can act on behalf of a user.

Why constrained delegation matters

Constrained delegation matters because it reduces the scope of impersonation. If an application requires delegation, unconstrained delegation is usually too broad. Constrained delegation gives administrators a way to support business requirements while limiting where delegated credentials can be used.

This helps reduce risk in several ways:

Delegation is limited to specific services.
Application trust boundaries are clearer.
A compromised delegated service has a smaller blast radius.
Unnecessary downstream access can be avoided.
Delegation settings can be reviewed more directly.

Constrained delegation is not risk-free. If an attacker compromises an account trusted for constrained delegation, they may still be able to impersonate users to the allowed services. The difference is that the attacker should be limited to the configured delegation targets.

Constrained delegation vs unconstrained delegation

Constrained delegation and unconstrained delegation solve a similar application problem, but they have very different security implications.

Delegation type	Scope	Risk level	Typical use
Unconstrained delegation	Any service	High	Legacy configurations
Constrained delegation	Specific services	Lower	Multi-tier applications
Resource-based constrained delegation	Controlled by target resource	Depends on permissions	Modern cross-boundary or resource-controlled scenarios

Unconstrained delegation gives the trusted account broad delegation ability. Constrained delegation limits delegation to specific SPNs. Resource-based constrained delegation changes the control model by allowing the target resource to define which principals can delegate to it.

Constrained delegation is usually safer than unconstrained delegation, but it still requires careful review.

Kerberos only vs protocol transition

When configuring constrained delegation, you may see two common options: Use Kerberos only and Use any authentication protocol. These options are important.

Use Kerberos only

This option allows constrained delegation when the user authenticated using Kerberos. It is generally the more restrictive option.

Use any authentication protocol

This option enables protocol transition, also known as S4U. It allows a service to obtain a Kerberos service ticket on behalf of a user even when the user did not originally authenticate with Kerberos. This can be useful for applications that accept non-Kerberos authentication at the front end but need Kerberos to access backend services. However, it can also increase risk if the trusted service account is compromised or overprivileged.

In general, use the most restrictive option that supports the application requirement.

What are SPNs?

A Service Principal Name identifies a service instance in Active Directory. Kerberos uses SPNs to determine which account is associated with a service.

Examples include:

HTTP/web01.example.com
MSSQLSvc/sql01.example.com:1433
CIFS/fileserver01.example.com
HOST/app01.example.com

In constrained delegation, the allowed delegation targets are configured by selecting SPNs. This means SPN hygiene is important. Stale, incorrect, duplicate, or overly broad SPNs can make delegation harder to understand and more difficult to secure.

Why constrained delegation can still be risky

Constrained delegation is safer than unconstrained delegation, but it can still be abused under the right conditions.

Risk increases when:

The delegated account is compromised.
The delegated account has local administrator rights on important servers.
The account can delegate to sensitive services.
Protocol transition is enabled unnecessarily.
The account is overprivileged.
The allowed SPNs are too broad.
The application server is exposed to many users.
Privileged users authenticate to the delegated service.
Delegation settings are not reviewed regularly.

A compromised constrained delegation account may allow an attacker to impersonate users to the configured downstream services. If those services are sensitive, the impact can still be significant.

High-risk delegation targets

Some delegation targets are more sensitive than others.

Examples of high-risk targets include:

CIFS on file servers
LDAP on domain controllers
HOST on sensitive servers
MSSQLSvc on database servers
HTTP on administrative web applications
Services hosted on Tier 0 systems
Services that store credentials, secrets, or sensitive data

Delegation to ordinary application services may be acceptable when documented and controlled. Delegation to domain controllers, privileged infrastructure, or broad file services should be reviewed carefully.

User accounts vs computer accounts

Constrained delegation can be configured on computer accounts and user accounts.

Computer accounts

Computer accounts are commonly used when the service runs as Local System, Network Service, or another built-in identity on the server. Delegation is then configured on the computer object.

User service accounts

User accounts are commonly used when an application runs under a domain service account. Delegation is then configured on that user account.

Both should be reviewed. User service accounts are especially important because they often have passwords, SPNs, application permissions, and sometimes excessive privileges.

PowerShell: Find accounts configured for constrained delegation

The msDS-AllowedToDelegateTo attribute stores the list of services an account is allowed to delegate to.

To find user accounts configured for constrained delegation:

Get-ADUser -Filter { msDS-AllowedToDelegateTo -like "*" } `
    -Properties msDS-AllowedToDelegateTo, ServicePrincipalName, Enabled, PasswordLastSet, LastLogonDate |
    Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, ServicePrincipalName, msDS-AllowedToDelegateTo

To find computer accounts configured for constrained delegation:

Get-ADComputer -Filter { msDS-AllowedToDelegateTo -like "*" } `
    -Properties msDS-AllowedToDelegateTo, OperatingSystem, LastLogonDate |
    Select-Object Name, DNSHostName, OperatingSystem, LastLogonDate, msDS-AllowedToDelegateTo

These commands identify accounts with constrained delegation configured. They do not prove the configuration is required or secure.

PowerShell: Find protocol transition

Protocol transition is commonly associated with the TrustedToAuthForDelegation property.

To find user accounts configured with protocol transition:

Get-ADUser -Filter { TrustedToAuthForDelegation -eq $true } `
    -Properties TrustedToAuthForDelegation, msDS-AllowedToDelegateTo, ServicePrincipalName, Enabled |
    Select-Object SamAccountName, Enabled, TrustedToAuthForDelegation, ServicePrincipalName, msDS-AllowedToDelegateTo

To find computer accounts configured with protocol transition:

Get-ADComputer -Filter { TrustedToAuthForDelegation -eq $true } `
    -Properties TrustedToAuthForDelegation, msDS-AllowedToDelegateTo, OperatingSystem |
    Select-Object Name, DNSHostName, OperatingSystem, TrustedToAuthForDelegation, msDS-AllowedToDelegateTo

Accounts with protocol transition should be reviewed carefully because they may be able to obtain service tickets on behalf of users without the user originally authenticating with Kerberos.

PowerShell: Identify sensitive delegation targets

This example searches constrained delegation entries for common sensitive service classes:

$SensitiveServices = @("LDAP", "CIFS", "HOST", "MSSQLSvc", "HTTP")

$Users = Get-ADUser -Filter { msDS-AllowedToDelegateTo -like "*" } `
    -Properties msDS-AllowedToDelegateTo, Enabled

$Computers = Get-ADComputer -Filter { msDS-AllowedToDelegateTo -like "*" } `
    -Properties msDS-AllowedToDelegateTo, OperatingSystem

$Results = foreach ($Account in @($Users + $Computers)) {
    foreach ($Target in $Account.'msDS-AllowedToDelegateTo') {
        foreach ($Service in $SensitiveServices) {
            if ($Target -like "$Service/*") {
                [PSCustomObject]@{
                    AccountName = $Account.Name
                    ObjectClass = $Account.ObjectClass
                    DelegationTarget = $Target
                    MatchedService = $Service
                }
            }
        }
    }
}

$Results | Sort-Object MatchedService, AccountName

This is a starting point for review, not a final risk determination. The actual risk depends on the target system, the application, the account’s privileges, and who can authenticate to the delegated service.

GUI: How to check constrained delegation

You can review constrained delegation in Active Directory Users and Computers.

Open Active Directory Users and Computers.
Enable Advanced Features from the View menu.
Find the user or computer account.
Open Properties.
Go to the Delegation tab.
Look for Trust this user/computer for delegation to specified services only.
Review whether it is set to Use Kerberos only or Use any authentication protocol.
Review the list of allowed services.

The key review questions are:

Is delegation still required?
Who owns the application?
Are the allowed services correct?
Is protocol transition required?
Is the account overprivileged?
Do privileged users authenticate to this service?
Can the delegation target be narrowed?

How to remediate risky constrained delegation

The right remediation depends on whether delegation is actually needed.

If delegation is not required

Remove the delegation configuration.

In Active Directory Users and Computers, set the account to Do not trust this user/computer for delegation

If delegation is required

Keep delegation constrained to the minimum required services.

Review and reduce:

Allowed SPNs
Protocol transition
Service account privileges
Administrative access to the delegated server
Users allowed to authenticate to the service
Exposure of the application server

If protocol transition is not required

Change from: Use any authentication protocol to Use Kerberos only.

Only do this after testing the application, because some applications depend on protocol transition.

Protect privileged accounts from delegation

Privileged accounts should generally be protected from delegation.

In Active Directory Users and Computers, enable Account is sensitive and cannot be delegated.

This helps prevent the account from being delegated to services.

Consider this protection for:

Domain Admin accounts
Enterprise Admin accounts
Schema Admin accounts
Tier 0 administrator accounts
Highly privileged service accounts
Sensitive operational accounts

Also consider using the Protected Users group for appropriate privileged accounts after testing compatibility.

Detection opportunities

Detection should include both configuration monitoring and behavior monitoring.

Configuration monitoring

Watch for changes to:

msDS-AllowedToDelegateTo
TrustedToAuthForDelegation
userAccountControl
Service Principal Names
Group membership of delegated service accounts
Local administrator rights on delegated servers

Useful Windows Security events include:

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

Behavioral monitoring

Look for:

Unusual service ticket requests
Delegated accounts requesting tickets for sensitive services
Service ticket activity from unexpected hosts
Privileged users authenticating to delegated servers
New delegation settings followed by lateral movement
Protocol transition activity where it is not expected

A single Kerberos event is not automatically suspicious. The value comes from understanding normal application behavior and detecting meaningful changes.

Common mistakes

Assuming constrained delegation is always safe

Constrained delegation is safer than unconstrained delegation, but it can still be abused if the trusted account or server is compromised.

Allowing too many delegation targets

The allowed services should be as narrow as possible. Broad lists of SPNs increase risk and make the configuration harder to justify.

Enabling protocol transition unnecessarily

Protocol transition can be useful, but it should not be enabled unless the application requires it.

Ignoring service account privileges

A delegated service account with excessive privileges is still dangerous. Delegation settings and account privileges should be reviewed together.

Forgetting about computer accounts

Delegation is not limited to user service accounts. Computer accounts can also be configured for constrained delegation.

Not protecting privileged users

Privileged users should generally be marked as sensitive and not delegable. Administrative logon patterns should also be reviewed.

Leaving stale delegation in place

Delegation settings often outlive the applications they were created for. Old configurations should be removed when no longer needed.

Practical recommendation

A practical constrained delegation review should include:

Identify all accounts with msDS-AllowedToDelegateTo configured.
Separate user accounts from computer accounts.
Identify accounts using protocol transition.
Review each allowed SPN.
Confirm application ownership and business purpose.
Remove delegation where it is no longer required.
Narrow delegation targets where possible.
Remove protocol transition unless required.
Reduce privileges on delegated accounts.
Protect privileged accounts from delegation.
Monitor changes to delegation-related attributes.
Recheck regularly as part of Active Directory hygiene.

Constrained delegation should be documented, narrow, and tied to a clear application requirement.

Summary

Constrained delegation is a Kerberos delegation model that allows a service to impersonate users only to specific downstream services. It is usually safer than unconstrained delegation because it limits where delegated authentication can be used.

However, constrained delegation is not automatically safe. Risk depends on the delegated account, the allowed SPNs, whether protocol transition is enabled, the sensitivity of the target services, and the privileges of users who authenticate to the service.

In a healthy Active Directory environment, constrained delegation should be limited, documented, reviewed regularly, and protected with least privilege.