What is Active Directory Delegation?

Definition

Active Directory delegation is a Kerberos feature that lets a service impersonate a user to access other services on the user's behalf. It enables scenarios where a front-end service (web, app server) needs to access a back-end service (database, file share) as the original user.

Delegation is essential for many enterprise applications — and one of the most abused features in Active Directory.

In simple terms:

Delegation lets a service do things "as you." Misconfigured delegation lets attackers do things as anyone — including Domain Admin.

---

Why Delegation Matters

• Misconfigured delegation has been the root of many domain compromises.
• Unconstrained delegation is one of the highest-risk configurations possible in AD.
• RBCD is a powerful but easily-abused feature for privilege escalation.
• Delegation choices made years ago for one application often persist as latent risk.

---

Types of Kerberos Delegation

1. Unconstrained Delegation

• The service can impersonate the user to any service in the forest.
• The user's TGT is forwarded to the service and stored in memory.
• Compromise of the service exposes TGTs of every connecting user — including admins.

Risk: Critical. Avoid entirely outside DCs.

2. Constrained Delegation

• The service can impersonate the user to specific services only (defined by SPN list).
• Configured via msDS-AllowedToDelegateTo.
• Two flavors:
  • Without protocol transition — the user must authenticate via Kerberos.
  • With protocol transition ("any authentication protocol") — service can use Service-for-User-to-Self (S4U2Self) to obtain a ticket as any user, then delegate it.

Risk: Moderate to High depending on flavor and target services.

3. Resource-Based Constrained Delegation (RBCD)

• Configured on the target (resource) rather than the source.
• Resource specifies which accounts can delegate to it (msDS-AllowedToActOnBehalfOfOtherIdentity).
• Allows decentralized configuration.

Risk: High when misconfigured. Common privilege escalation vector.

---

How Attackers Abuse Delegation

Unconstrained Delegation Abuse

1. Compromise a server with unconstrained delegation.
2. Trigger or wait for a privileged user to authenticate (e.g., coerce DC via PetitPotam).
3. Extract their TGT from memory.
4. Use the TGT to impersonate them anywhere.

Constrained Delegation with Protocol Transition

1. Account has constrained delegation with protocol transition to a sensitive service.
2. Attacker uses S4U2Self + S4U2Proxy to obtain a service ticket as any user.
3. Authenticates to the target service as that user.

RBCD Abuse

1. Attacker has write access to a computer object (often via default ms-DS-MachineAccountQuota or via stolen creds).
2. Configures the computer to be allowed to delegate to a target via msDS-AllowedToActOnBehalfOfOtherIdentity.
3. Uses S4U2Self + S4U2Proxy to impersonate any user (including admins) to the target.

---

Real-World Examples

1. Unconstrained Delegation on a Web Server

A web server has been trusted for unconstrained delegation since 2010 to support an old SSO scenario. A Domain Admin browses to it for troubleshooting; the attacker who already controls the server extracts their TGT and reaches Domain Admin.

2. PetitPotam → Unconstrained Delegation

Attacker uses PetitPotam to coerce a DC to authenticate to an attacker-controlled server with unconstrained delegation. The DC's TGT is captured.

3. RBCD Privilege Escalation

A penetration tester with a low-privilege account discovers ms-DS-MachineAccountQuota is set to default 10. They create a new computer object, configure RBCD on a target server using the new object, and impersonate Domain Admin.

4. Constrained Delegation to KRBTGT-Equivalent

An account has constrained delegation with protocol transition to a sensitive service that's effectively as privileged as a DC. Attacker compromises the account and impersonates any user to that service.

---

Delegation Best Practices

1. Eliminate unconstrained delegation outside DCs.
2. Audit userAccountControl flag TRUSTED_FOR_DELEGATION across all accounts.
3. Prefer constrained delegation without protocol transition where delegation is needed.
4. Audit msDS-AllowedToDelegateTo on every account.
5. Audit msDS-AllowedToActOnBehalfOfOtherIdentity on every object (RBCD).
6. Set ms-DS-MachineAccountQuota to 0 for non-admins to prevent self-creation of computer objects.
7. Mark sensitive accounts with Account is sensitive and cannot be delegated (AdminCount users, Domain Admins, etc.).
8. Use the Protected Users group for additional protection (no delegation, no NTLM, short ticket lifetime).
9. Monitor S4U2Self and S4U2Proxy Kerberos events for anomalies.
10. Document every legitimate delegation with owner, purpose, and review date.
11. Remove delegations associated with decommissioned applications.
12. Restrict who can write msDS-AllowedToActOnBehalfOfOtherIdentity on computer objects.

---

Delegation Security Checklist

• No accounts with unconstrained delegation outside DCs?
• All constrained delegations documented and reviewed?
• All RBCD configurations documented and reviewed?
• ms-DS-MachineAccountQuota set to 0 for standard users?
• Sensitive accounts marked "Cannot be delegated" or in Protected Users?
• S4U2Self / S4U2Proxy anomaly detections in place?
• Delegation reviewed during application decommissioning?

---

How Forestall Helps

Forestall enumerates every delegation configuration across your forest:

• Accounts with unconstrained delegation.
• Constrained delegation paths and their sensitivity.
• RBCD configurations and who can write them.
• ms-DS-MachineAccountQuota posture.
• Attack paths from delegation misconfigurations to Tier 0.

It then ranks remediation by exploitability so you can fix the highest-leverage delegations first.

---

Frequently Asked Questions

Is delegation always bad?

No — it's necessary for many enterprise apps. The problem is misconfiguration, not delegation itself.

Why is unconstrained delegation so dangerous?

Because it allows the service to act as any user who authenticates to it, anywhere. Combined with coerced authentication (PetitPotam, PrinterBug), it leads directly to Domain Admin.

What is the Protected Users group?

A group whose members can't be delegated, can't use NTLM, and use shorter ticket lifetimes. Use it for sensitive accounts.

How does ms-DS-MachineAccountQuota matter?

If non-zero, any authenticated user can create computer objects, which they can then use as RBCD source identities. Setting it to 0 closes that path.

Can RBCD be used legitimately?

Yes — it allows resource owners to control delegation without involving the source admin. The risk is in who can write the attribute.

---

Conclusion

Delegation is one of the most powerful — and most abused — features of Active Directory. Eliminating unconstrained delegation, auditing constrained and RBCD configurations, hardening ms-DS-MachineAccountQuota, protecting sensitive accounts, and detecting S4U abuse are the controls that turn delegation from a hidden escalation path into a managed capability. Make delegation visible, intentional, and reviewed — and you remove a class of attack that has compromised countless domains.