Skip to content
HackIndex logo

HackIndex

Delegation Misconfiguration Discovery

3 min read Jun 11, 2026

Kerberos delegation allows a service to authenticate to another service on behalf of a user. When misconfigured, delegation gives attackers a path to impersonate any domain user, including Domain Admins, to targeted services. Three delegation types exist with different risk levels:

  • Unconstrained Delegation: service receives a full TGT for any user that authenticates to it. Highest impact — coercing a DC to authenticate gives you the DC's TGT.

  • Constrained Delegation: service can request tickets only to a specific set of SPNs. If TRUSTED_TO_AUTH_FOR_DELEGATION is set (protocol transition), it can impersonate any user, including those that never authenticated to it.

  • Resource-Based Constrained Delegation (RBCD): the resource (not the requester) defines who can delegate to it. If you have GenericWrite on a computer, you can configure RBCD yourself.

Unconstrained delegation

Any computer or user with unconstrained delegation receives a copy of the authenticating user's TGT. Domain controllers always have unconstrained delegation — finding non-DC computers with this setting is the vulnerability. Coerce a DC to authenticate to the target host and extract the DC's TGT from LSASS.

┌──(kali㉿kali)-[~]
└─$ # Non-DC computers with unconstrained delegation
┌──(kali㉿kali)-[~]
└─$ # UAC: TrustedForDelegation (0x80000=524288) AND NOT SERVER_TRUST_ACCOUNT (0x2000=8192)
┌──(kali㉿kali)-[~]
└─$ bloodyAD -d $DOMAIN -u $USER -p $PASSWORD --host $TARGET_IP get search \
--filter '(&(objectClass=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288)(!(userAccountControl:1.2.840.113556.1.4.803:=8192)))' \
--attr dNSHostName operatingSystem userAccountControl
 
┌──(kali㉿kali)-[~]
└─$ # Users with unconstrained delegation (rare but high-value)
┌──(kali㉿kali)-[~]
└─$ bloodyAD -d $DOMAIN -u $USER -p $PASSWORD --host $TARGET_IP get search \
--filter '(&(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=524288)(!(objectClass=computer)))' \
--attr sAMAccountName userAccountControl
 
┌──(kali㉿kali)-[~]
└─$ # nxc
┌──(kali㉿kali)-[~]
└─$ nxc ldap $TARGET_IP -u $USER -p $PASSWORD --trusted-for-delegation 
dNSHostName: print01.corp.local
operatingSystem: Windows Server 2019 Standard
userAccountControl: WORKSTATION_TRUST_ACCOUNT, TRUSTED_FOR_DELEGATION

dNSHostName: fileserver.corp.local
operatingSystem: Windows Server 2016 Standard
PS C:\Users\Guest\Desktop> # Non-DC computers with unconstrained delegation
PS C:\Users\Guest\Desktop> Get-DomainComputer -UnconstrainedDelegation |
PS C:\Users\Guest\Desktop>  Where-Object {$_.useraccountcontrol -notmatch 'SERVER_TRUST_ACCOUNT'} |
PS C:\Users\Guest\Desktop>  Select-Object dnshostname, operatingsystem, useraccountcontrol
 
PS C:\Users\Guest\Desktop> # Users with unconstrained delegation
PS C:\Users\Guest\Desktop> Get-DomainUser -UnconstrainedDelegation | Select-Object samaccountname, useraccountcontrol
 
PS C:\Users\Guest\Desktop> # AD module
PS C:\Users\Guest\Desktop> Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, OperatingSystem |
PS C:\Users\Guest\Desktop>  Select-Object Name, OperatingSystem 
dnshostname: print01.corp.local  operatingsystem: Windows Server 2019

A non-DC computer with unconstrained delegation is a coercion target. Force a DC to authenticate to it (with Coercer or PrinterBug), then extract the DC's TGT with Rubeus or Mimikatz. See Unconstrained Delegation Abuse.

Constrained delegation

Accounts with msDS-AllowedToDelegateTo set can request service tickets on behalf of users to a specific list of SPNs. If the account also has TRUSTED_TO_AUTH_FOR_DELEGATION (protocol transition), it can impersonate any user, including Domain Admins, to those services without the user ever authenticating first.

┌──(kali㉿kali)-[~]
└─$ # Accounts with msDS-AllowedToDelegateTo set (users and computers)
┌──(kali㉿kali)-[~]
└─$ bloodyAD -d $DOMAIN -u $USER -p $PASSWORD --host $TARGET_IP get search \
--filter '(msDS-AllowedToDelegateTo=*)' \
--attr sAMAccountName msDS-AllowedToDelegateTo userAccountControl
 
┌──(kali㉿kali)-[~]
└─$ # nxc — constrained delegation flag
┌──(kali㉿kali)-[~]
└─$ nxc ldap $TARGET_IP -u $USER -p $PASSWORD --admin-count 
sAMAccountName: svc-mssql
msDS-AllowedToDelegateTo: MSSQLSvc/sql01.corp.local:1433
userAccountControl: TRUSTED_TO_AUTH_FOR_DELEGATION  <-- protocol transition

sAMAccountName: WEB01$
msDS-AllowedToDelegateTo: http/intranet.corp.local
PS C:\Users\Guest\Desktop> # Users with constrained delegation
PS C:\Users\Guest\Desktop> Get-DomainUser -TrustedToAuth | Select-Object samaccountname, msds-allowedtodelegateto, useraccountcontrol
 
PS C:\Users\Guest\Desktop> # Computers with constrained delegation
PS C:\Users\Guest\Desktop> Get-DomainComputer -TrustedToAuth | Select-Object dnshostname, msds-allowedtodelegateto, useraccountcontrol
 
PS C:\Users\Guest\Desktop> # AD module
PS C:\Users\Guest\Desktop> Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne '$null'} -Properties msDS-AllowedToDelegateTo, userAccountControl |
PS C:\Users\Guest\Desktop>  Select-Object Name, 'msDS-AllowedToDelegateTo', userAccountControl

TRUSTED_TO_AUTH_FOR_DELEGATION in userAccountControl means protocol transition is enabled — the account can impersonate any user (including Domain Admins) to the listed SPNs. Without it, delegation only works when the target user authenticates first. Protocol transition is the more dangerous variant. See Constrained Delegation Abuse.

Resource-based constrained delegation (RBCD)

RBCD is configured on the resource — the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on a computer object specifies which accounts can delegate to it. If this attribute is already set on a machine, an attacker who controls the listed account can impersonate Domain Admin to that computer. If you have write access to this attribute (via GenericWrite on the computer), you can configure RBCD yourself.

┌──(kali㉿kali)-[~]
└─$ # Computers with msDS-AllowedToActOnBehalfOfOtherIdentity already set
┌──(kali㉿kali)-[~]
└─$ bloodyAD -d $DOMAIN -u $USER -p $PASSWORD --host $TARGET_IP get search \
--filter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' \
--attr dNSHostName msDS-AllowedToActOnBehalfOfOtherIdentity
 
┌──(kali㉿kali)-[~]
└─$ # Find accounts that can WRITE this attribute (GenericWrite on computers)
┌──(kali㉿kali)-[~]
└─$ bloodyAD -d $DOMAIN -u $USER -p $PASSWORD --host $TARGET_IP get writable --detail \
| grep -B2 'msDS-AllowedToActOnBehalfOfOtherIdentity'
PS C:\Users\Guest\Desktop> # Computers with RBCD already configured
PS C:\Users\Guest\Desktop> Get-DomainComputer | Where-Object {
$_.'msds-allowedtoactonbehalfofotheridentity' -ne $null
} | Select-Object dnshostname, 'msds-allowedtoactonbehalfofotheridentity'
 
PS C:\Users\Guest\Desktop> # Find accounts that have GenericWrite on computer objects
PS C:\Users\Guest\Desktop> Get-DomainComputer | ForEach-Object {
$computer = $_.dnshostname
Get-DomainObjectAcl -Identity $_.distinguishedname -ResolveGUIDs | Where-Object {
$_.ActiveDirectoryRights -match 'GenericWrite|GenericAll|WriteProperty' -and
$_.ObjectAceType -match 'msDS-AllowedToActOnBehalfOfOtherIdentity'
} | Select-Object @{N='Computer';E={$computer}}, IdentityReferenceName, ActiveDirectoryRights
}

If msDS-AllowedToActOnBehalfOfOtherIdentity is already set on a machine pointing to a user-controlled account, the attack is immediately actionable: use S4U2Self + S4U2Proxy to get a service ticket as Domain Admin. If GenericWrite on a computer is found via ACL enumeration, you can set RBCD yourself and then exploit it. See Constrained Delegation Abuse for the S4U chain.

References