Constrained Delegation: Security Risks and Solutions in Active Directory

Microsoft has introduced three distinct iterations of delegation over the years, each attempting to fix the security flaws of the previous version. Understanding this evolution is crucial for grasping the specific nuances of Constrained Delegation.

1. Unconstrained Delegation (The Original Implementation)

Introduced in Windows 2000, Unconstrained Delegation was the first attempt at solving the impersonation problem, and it was a security disaster. When a user authenticated to a server configured for Unconstrained Delegation, the Domain Controller (DC) placed a copy of the user's Ticket Granting Ticket (TGT) directly into the memory (LSASS) of that server. The server could then use that TGT to request access to any service on the network, pretending to be the user. The Risk: If an attacker compromised a server with Unconstrained Delegation, they could simply dump the LSASS memory, steal the TGTs of any user who had authenticated to it (including Domain Admins), and immediately compromise the entire domain. Due to this catastrophic risk, Unconstrained Delegation should be completely eliminated from modern networks.

2. Constrained Delegation (The Solution)

Recognizing the massive risks of Unconstrained Delegation, Microsoft introduced Constrained Delegation in Windows Server 2003. This feature aimed to apply the Principle of Least Privilege. Instead of giving the front-end server a blank check (the user's TGT) to access any service, Constrained Delegation restricts the impersonation. The Active Directory administrator explicitly defines a list of target services (identified by their Service Principal Names, or SPNs) that the front-end server is permitted to access on behalf of the user. For example, the Web Server is explicitly allowed to delegate credentials only to the MSSQLSvc/sqlserver.corp.local SPN.

3. Resource-Based Constrained Delegation (RBCD)

Introduced in Windows Server 2012, RBCD flipped the administrative model. Instead of configuring the front-end server with a list of where it was allowed to go, RBCD configures the target resource (the backend server) with a list of who is allowed to impersonate users to it. This shifted control from the Domain Administrator to the owner of the target resource, simplifying administration and addressing some specific cross-domain delegation issues.

To make Constrained Delegation function securely without requiring the user's powerful TGT, Microsoft developed two critical extensions to the Kerberos protocol, collectively known as Service for User (S4U). Understanding these two extensions is the key to understanding how attackers exploit the feature.

1. S4U2Proxy (Service for User to Proxy)

This extension handles the core delegation scenario. When a user authenticates to the Web Server using Kerberos, the Web Server receives a Service Ticket (TGS) for the user. Under S4U2Proxy, the Web Server takes this valid TGS, presents it to the Domain Controller, and says, "I have proof this user authenticated to me. Please give me a new Service Ticket to access the backend SQL database on their behalf." The DC checks the Constrained Delegation configuration on the Web Server's computer object in AD. If the SQL Database's SPN is on the approved list, the DC issues the new ticket.

2. S4U2Self (Service for User to Self) / Protocol Transition

S4U2Self was introduced to solve a massive architectural headache: Protocol Transition. What happens if the user does not authenticate to the Web Server using Kerberos? What if they authenticate using a web form (username/password), NTLM, or a SAML token? Because the user didn't use Kerberos, the Web Server doesn't have a Kerberos Service Ticket to show the DC. S4U2Self allows the Web Server to unilaterally ask the Domain Controller for a Kerberos Service Ticket to itself, on behalf of any arbitrary user, without requiring the user to supply a password. The Web Server basically tells the DC, "Trust me, Bob just authenticated to me using a web form. Please give me a Kerberos ticket for Bob to access my own service." Once the Web Server possesses this S4U2Self ticket, it can then use the S4U2Proxy extension to swap it for a ticket to the backend SQL server. This is the most dangerous aspect of Constrained Delegation. If an administrator configures a server with Constrained Delegation and selects the option "Use any authentication protocol," they are enabling S4U2Self.

While Constrained Delegation limits the blast radius compared to Unconstrained Delegation, it introduces highly complex, logical vulnerabilities that attackers exploit with devastating efficiency.

Compromising the Trusted Middle-Tier Server

The entire security model of Constrained Delegation relies on the integrity of the front-end server (the computer or service account configured with the delegation rights). If an attacker compromises that server (e.g., by exploiting a vulnerability in the web application or gaining local administrator rights), they inherit the delegation privileges of that machine account.

Abusing S4U2Self (Protocol Transition) for Privilege Escalation

If an attacker compromises a server configured with Constrained Delegation that allows "Any Authentication Protocol" (Protocol Transition), they hold the keys to the kingdom regarding the specific backend services they are allowed to access. Because S4U2Self allows the compromised server to request a ticket on behalf of any user without a password, the attacker can use a tool like Rubeus to request a ticket on behalf of a Domain Administrator. The attack flow works like this:

1. The attacker, operating on the compromised Web Server, uses Rubeus to execute an S4U2Self request to the DC: "Give me a ticket for the user 'DomainAdmin' to access myself (the Web Server)."
2. The DC, trusting the Web Server because it is configured for Protocol Transition, issues the ticket.
3. The attacker then uses Rubeus to execute an S4U2Proxy request: "Take this ticket for 'DomainAdmin' and give me a ticket to access the backend SQL Server."
4. The DC checks the delegation list, sees the SQL Server is approved, and issues the ticket.
5. The attacker now has a valid Kerberos ticket to access the backend SQL server with full Domain Administrator privileges. If that backend server happens to be a Domain Controller (e.g., if delegation was mistakenly configured to the CIFS or LDAP SPN on a DC), the entire active directory forest is immediately compromised.

The "Alternate Services" Attack (SPN Forgery)

Another critical vulnerability lies in how the Kerberos service ticket is encrypted. When the DC issues a Service Ticket via S4U2Proxy, the ticket is encrypted using the password hash of the target service (the backend server). However, the Service Principal Name (SPN) inside the ticket is not cryptographically protected in a way that prevents the middle-tier server from altering it if the target SPNs share the same underlying account. For example, if the Web Server is permitted to delegate to the TIME/backend.corp.local SPN, an attacker can request the ticket, and then locally alter the SPN in the ticket to CIFS/backend.corp.local before presenting it to the backend server. Because both the TIME service and the CIFS (file sharing) service run under the context of the backend server's machine account, the backend server will decrypt and accept the forged ticket. The attacker requested access to check the time, but effectively gained access to the entire file system of the backend server.

Detecting the abuse of Constrained Delegation requires deep visibility into Active Directory configuration and rigorous monitoring of Kerberos authentication traffic at the Domain Controller level.

Mapping Delegation Paths with BloodHound

The most effective proactive defense is understanding exactly where delegation is configured in the environment. Security teams and penetration testers heavily utilize BloodHound, an open-source tool that uses graph theory to map Active Directory relationships. BloodHound queries AD via LDAP to identify all computer and user accounts configured with Constrained Delegation and maps their allowed target SPNs. This provides a visual roadmap of potential escalation paths. If BloodHound reveals a low-tier web server with Constrained Delegation rights pointing to a highly critical database server or, disastrously, a Domain Controller, security teams can remediate the misconfiguration before it is exploited.

Monitoring Windows Event Logs

Detection during an active attack relies on analyzing Domain Controller security event logs.

• Event ID 4769 (A Kerberos service ticket was requested): This is the core event to monitor.
• Identifying Anomalies: Defenders must look for anomalous 4769 events. For instance, if an attacker abuses S4U2Self, the event log will show the compromised Web Server's machine account requesting a ticket for a highly privileged user (like a Domain Admin), where the target service is the Web Server itself. Furthermore, if a Web Server suddenly begins requesting service tickets for the CIFS (SMB) or HOST (WMI/WinRM) services of a backend server when it normally only requests MSSQLSvc tickets, this is a massive red flag indicative of an attacker pivoting.

Securing Active Directory against delegation attacks requires a combination of strict configuration management and aggressive protective controls for administrative accounts.

1. Limit the Scope and Use of Delegation

The most fundamental mitigation is to simply use delegation as sparingly as possible. Do not configure Constrained Delegation unless the application architecture absolutely requires impersonation to function. When it is required, never configure it to target highly critical infrastructure like Domain Controllers or critical Tier-0 management servers.

2. Transition to Resource-Based Constrained Delegation (RBCD)

Wherever possible, organizations should transition away from traditional Constrained Delegation and adopt RBCD. RBCD is generally considered more secure because the access control list is maintained on the target resource, reducing the risk of a compromised front-end server arbitrarily altering SPNs to attack other services sharing the same account.

3. Protect High-Value Accounts

The most devastating outcome of a delegation attack is an attacker impersonating a Domain Admin. Active Directory provides built-in mechanisms to prevent specific accounts from ever being delegated, regardless of how the servers are configured.

• "Account is sensitive and cannot be delegated": Every user account object in AD has this checkbox in its properties. This must be checked for all Domain Admins, Enterprise Admins, and critical service accounts. If checked, the Domain Controller will explicitly refuse to issue an S4U2Proxy ticket on behalf of that user.
• The Protected Users Security Group: Introduced in Windows Server 2012 R2, placing administrative accounts into this highly restrictive group automatically applies several security features, including the absolute prohibition of Kerberos delegation.

4. Disable "Any Authentication Protocol" (Protocol Transition)

Unless an application explicitly relies on non-Kerberos front-end authentication (like forms-based auth), administrators should never select the "Use any authentication protocol" option when configuring Constrained Delegation. Selecting "Use Kerberos only" disables the dangerous S4U2Self extension, forcing the attacker to actually possess the user's valid TGS before they can request delegation to the backend, drastically reducing the attack surface.