Kerberos Delegation Audit: How to Find and Remediate Unconstrained and Constrained Delegation Risks in Active Directory

Find all computer accounts with unconstrained delegation (excluding DCs, which legitimately have it): Get-ADComputer -Filter { TrustedForDelegation -eq $true } -Properties TrustedForDelegation, ServicePrincipalName | Where-Object { $_.DistinguishedName -notlike 'Domain Controllers' } | Select-Object Name, ServicePrincipalName. Find all user accounts with unconstrained delegation (always suspicious -- user accounts should never have this): Get-ADUser -Filter { TrustedForDelegation -eq $true } -Properties TrustedForDelegation | Select-Object SamAccountName, DistinguishedName. Find constrained delegation: Get-ADObject -Filter { msDS-AllowedToDelegateTo -like '' } -Properties msDS-AllowedToDelegateTo, SamAccountName | Select-Object SamAccountName, 'msDS-AllowedToDelegateTo'. Find resource-based constrained delegation (RBCD): Get-ADObject -Filter { 'msDS-AllowedToActOnBehalfOfOtherIdentity' -like '' } -Properties 'msDS-AllowedToActOnBehalfOfOtherIdentity', SamAccountName | Select-Object SamAccountName, 'msDS-AllowedToActOnBehalfOfOtherIdentity'. BloodHound also enumerates all delegation types -- query 'Find computers with Unconstrained Delegation' and 'Find accounts with Constrained Delegation' in the built-in query set.

Any computer account with TrustedForDelegation=True and any user account with the same setting represents an unconstrained delegation risk. The Printer Bug (PrinterBug / SpoolSample) attack exploits this: an attacker forces a domain controller to authenticate to an unconstrained delegation host by triggering the MS-RPRN or MS-EFSRPC interface. The DC's machine ticket arrives at the unconstrained delegation host; Rubeus can extract it and use it to perform a DCSync. Remediation for computer accounts: migrate the application using this account to constrained delegation instead. If migration is not immediately possible, add the computer account to a monitored group and alert on any Kerberos ticket extraction (Event ID 4769 with Service Name ending in $ from that host). Remediation for user accounts: there is almost never a legitimate reason for a user account to have unconstrained delegation. Remove the flag immediately via Active Directory Users and Computers (Delegation tab, select 'Do not trust this user for delegation') or PowerShell: Set-ADUser username -TrustedForDelegation $false.

Constrained delegation limits which specific services a service account can impersonate users to (e.g., only the SQL Server MSSQLSvc SPNs, not any service in the domain). The risk is lower than unconstrained delegation but still real if the constrained delegation target includes high-value services. Review the msDS-AllowedToDelegateTo values: if a service account has constrained delegation to 'LDAP/dc01.domain.com', an attacker who compromises that service account can impersonate any user to the DC's LDAP service and perform DCSync without domain admin credentials. Audit the constrained delegation target list and ask: does this service account actually need to delegate to the LDAP service on the DC? Most web and application accounts need database SPNs (MSSQLSvc), not DC SPNs. Remove delegation targets that are not required by the application. Also check whether the account is configured for 'Use any authentication protocol' (Protocol Transition) vs. 'Use Kerberos only' -- Protocol Transition is more dangerous as it allows transitioning from non-Kerberos authentication to Kerberos delegation and should only be used when the application specifically requires it.

RBCD allows a target resource to control which principals can delegate to it by setting msDS-AllowedToActOnBehalfOfOtherIdentity on the target computer object. If an attacker can write to this attribute on a computer object (via GenericWrite or similar ACL rights), they can configure an attacker-controlled machine account to impersonate any user to that computer -- including domain admins. The attack requires: write access to the target computer object's msDS-AllowedToActOnBehalfOfOtherIdentity attribute (findable via BloodHound as 'GenericWrite' or 'WriteProperty' edges to computer objects), and a machine account (which any domain user can create by default, up to the MachineAccountQuota of 10). Remediation: reduce MachineAccountQuota to 0 for non-admin users (ms-DS-MachineAccountQuota on the domain object). Audit msDS-AllowedToActOnBehalfOfOtherIdentity on all computer objects and remove any unexpected entries. Restrict GenericWrite access to computer objects to administrative accounts only.

The simplest and most important delegation hardening step for privileged accounts is adding them to the Protected Users security group. Accounts in Protected Users cannot be delegated regardless of what delegation settings are configured on the service -- the KDC will refuse to create a delegable ticket for Protected Users members. Add all domain admin accounts, tier 0 service accounts, and executives to Protected Users immediately. Also set 'Account is sensitive and cannot be delegated' on any account that does not need to be delegated to at all -- this is a per-account flag that prevents delegation from that account (different from Protected Users, which also restricts NTLM and RC4). Use the 'Account is sensitive' flag for all service accounts that do not require delegation. For ongoing monitoring: alert on any modification to TrustedForDelegation, msDS-AllowedToDelegateTo, or msDS-AllowedToActOnBehalfOfOtherIdentity via Event ID 5136 (directory service object modification).