▸ On this page 4 sections
Background
Kerberos delegation lets a service act on behalf of a user against another service. Misconfigured, it becomes one of the cleanest paths from a low-privilege account to Domain Admin - no memory corruption, no malware, just tickets working exactly as designed.
This is a lab walkthrough of an unconstrained-to-constrained delegation chain. All identifiers are placeholders.
Finding delegation
Start by enumerating accounts trusted for delegation. Service accounts with msDS-AllowedToDelegateTo populated are the interesting ones:
Get-ADObject -LDAPFilter "(msDS-AllowedToDelegateTo=*)" `
-Properties msDS-AllowedToDelegateTo,servicePrincipalName
If a computer account you control is trusted to delegate to a Tier-0 SPN, that is a direct path - treat the finding as critical in your report.
Requesting the ticket
With control of a delegating service account, request a service ticket on behalf of a privileged user (S4U2Self → S4U2Proxy), then inject it:
ticket-tool s4u --user web$ --impersonate admin \
--spn cifs/<target-host> --apply
S4U requests are visible in ticket-granting telemetry. Keep the impersonated principal and target SPN scoped to what the engagement actually needs.
Takeaway
Constrained delegation is safe only when the delegating account is treated with the same care as the most privileged service it can reach. Audit msDS-AllowedToDelegateTo regularly and keep delegating accounts out of paths that touch Tier-0.