Constrained delegation lets specific services act on behalf of users when accessing other resources in Active Directory. This Kerberos feature serves legitimate purposes, like enabling a web application to pull data from a backend database using user credentials, but it creates serious security gaps when misconfigured. Attackers who compromise a service account with delegation privileges can access sensitive resources across your network.
This article explains how Kerberos constrained delegation works, covers the different types available in Active Directory constrained delegation scenarios, and provides a step-by-step implementation approach. You'll learn about common constrained delegation attack techniques and detection methods to stop threats before they become breaches.
Understanding Constrained Delegation
Delegation in Active Directory allows a service to impersonate a user when connecting to other services. Unconstrained delegation grants broad access, essentially a blank check to impersonate users anywhere, while constrained delegation restricts this privilege to specific services.
What Is Constrained Delegation?
Constrained delegation limits which backend services a frontend service can access on behalf of users. When you configure it, you explicitly define the target services that can receive delegated credentials. For example, you might allow your web server to access only the SQL database service using user credentials, preventing it from reaching file servers or email systems. This controlled approach addresses the security concerns that make unconstrained delegation dangerous.
Constrained delegation restricts service impersonation to an administrator-approved list of specific backend services, reducing the attack surface compared to unconstrained delegation.
In Active Directory constrained delegation configurations, administrators specify Service Principal Names (SPNs) for each allowed backend service. The domain controller then enforces these restrictions, issuing service tickets only for the preapproved targets. You set these permissions through the Active Directory Users and Computers interface or PowerShell commands, defining exactly where delegated credentials can flow.
How Kerberos Constrained Delegation Works
Kerberos constrained delegation relies on service tickets with forwarding restrictions. When a user authenticates to your frontend service, like a web application, the service receives a Ticket Granting Service (TGS) ticket that includes the user's authorization data. The frontend service then requests another ticket from the Key Distribution Center (KDC) to access the backend service, presenting the original user's TGS ticket as proof.
The KDC checks whether the requesting service account has delegation privileges for the target service. If the configuration permits this specific delegation path, the KDC issues a new service ticket with the user's identity. The frontend service can now authenticate to the backend service as if it were the original user. This process happens transparently, so users don't need to reauthenticate or provide credentials multiple times.
The Role of Service for User (S4U) Extensions
S4U extensions add flexibility to Kerberos constrained delegation through two capabilities: S4U2Self and S4U2Proxy:
S4U2Self allows a service to obtain a service ticket to itself on behalf of any user, even when that user didn't authenticate using Kerberos. This matters when users log in through non-Kerberos methods like form-based authentication or certificate authentication.
S4U2Proxy enables protocol transition, where the service can then use that self-issued ticket to request access to backend services.
Together, these extensions support scenarios where the initial authentication doesn't involve Kerberos, but backend services require it. You enable protocol transition through a checkbox in the delegation settings, though this option requires careful consideration since it expands the ways a service account can obtain delegated credentials.
Types of Active Directory Constrained Delegation
Active Directory offers two different approaches to constrained delegation, each designed for specific scenarios and administrative structures. The right choice depends on how your organization manages services and who controls access to backend resources.
Traditional Kerberos Constrained Delegation
Traditional constrained delegation puts the configuration on the frontend service account. Administrators specify which backend services this account can access by adding Service Principal Names to the “Trust this user/computer for delegation to specified services only" field in Active Directory Users and Computers. The settings live directly on the account, performing the delegation there rather than on the target resources.
This delegation method requires elevated privileges in the domain. Administrators need write access to the delegating account's properties, which usually means Domain Admin rights or specifically delegated permissions for these security-sensitive attributes. This centralized approach can create administrative bottlenecks, especially in larger organizations where multiple teams manage different services.
Traditional constrained delegation works best when service relationships remain stable over time. If your web application consistently accesses the same database server, configuring the web server's service account once handles all subsequent requests. The tradeoff is that adding new backend services requires updating the frontend account's delegation settings, which can slow down infrastructure changes and new resource deployment.
Resource-Based Constrained Delegation
Resource-based constrained delegation reverses the configuration model entirely. Rather than specifying what a frontend service can access, you configure which frontend services are allowed to delegate credentials to a backend resource. The permission resides on the backend service account or computer object through the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
Resource-based constrained delegation decentralizes permission management, allowing resource owners to control access without requiring Domain Admin intervention.
This approach gives backend service owners greater control over their resources. The team managing a database server can grant delegation permissions to approved frontend services without waiting for Domain Admin assistance. You configure these permissions through PowerShell using the PrincipalsAllowedToDelegateToAccount parameter or by directly modifying the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
Resource-based constrained delegation requires Windows Server 2012 or later. It handles cross-domain and cross-forest scenarios more gracefully than traditional constrained delegation, making it particularly useful for organizations with multiple domains or complex trust relationships.
Comparing Delegation Methods
Here's a detailed comparison of how each method works and when to use it.
| Feature | Traditional Kerberos Constrained Delegation | Resource-Based Constrained Delegation |
|---|---|---|
| Configuration Location | Frontend service account properties | Backend resource account properties |
| Required Permissions | Domain Admin or delegated rights on frontend account | Write access to backend resource account |
| Minimum Domain Functional Level | Windows Server 2003 | Windows Server 2012 |
| Cross-Domain Support | Limited; requires specific trust configuration | Better support for complex trust scenarios |
| Management Model | Centralized on delegating service | Decentralized to resource owners |
| Best Use Case | Stable service relationships; legacy infrastructure | Dynamic environments; delegated administration |
Your choice should align with your organizational structure and how you manage IT resources. Traditional constrained delegation fits environments with centralized IT management and service architectures that don't change frequently. Resource-based constrained delegation works better for organizations with DevOps practices or distributed teams that manage their own resources. Many organizations run both approaches simultaneously, applying each method where it delivers the most value for specific services and security requirements.
Implementing Constrained Delegation Securely
Setting up constrained delegation requires careful planning and precise configuration. Each step builds on the previous one, and skipping ahead creates security gaps or broken authentication flows. This implementation process applies whether you're using traditional or resource-based constrained delegation, though the specific configuration locations differ between the two methods.
Step 1: Identify Service Accounts That Require Delegation
Start by mapping out your service architecture and identifying which services need to access backend resources on behalf of users. Document the frontend services, the backend services they must reach, and the business justification for each delegation relationship. A web application might need database access, but does it really need to access file shares or email systems? Challenge each requirement.
Service accounts running under the SYSTEM or Network Service context involve different security considerations than domain user accounts. Computer accounts have higher privileges in Active Directory, so delegating through them expands the potential damage from compromise. Dedicated service accounts with minimal privileges reduce this risk. Review your existing service accounts and eliminate any with excessive permissions before enabling delegation.
Step 2: Configure Service Principal Names
SPNs uniquely identify service instances in Kerberos authentication. Before you configure delegation, register SPNs for both the frontend and backend services. Use the setspn command to add these registrations, specifying the service class and host name. For a SQL Server instance, you might run setspn -S MSSQLSvc/sqlserver.domain.com:1433 DOMAIN\sqlservice.
Duplicate SPNs break Kerberos authentication entirely, so check for existing registrations with setspn -Q before adding new ones. Each SPN must be unique across your entire Active Directory forest. If you find duplicates, remove the incorrect entries and keep only the valid registration on the actual service account.
Step 3: Set Delegation Permissions in Active Directory
Next, configure the actual delegation permissions. For traditional Kerberos constrained delegation, open the properties of the frontend service account in Active Directory Users and Computers. Navigate to the Delegation tab, select “Trust this user for delegation to specified services only," and add the SPNs of backend services that the account can access.
Always configure the minimum set of services necessary for the application to function; additional permissions create unnecessary attack surface.
For resource-based constrained delegation, use PowerShell on the backend resource. The command Set-ADComputer -Identity BackendServer -PrincipalsAllowedToDelegateToAccount FrontendService$ grants the frontend service permission to delegate to that backend. This decentralized approach gives resource owners direct control without waiting for domain-level permission changes.
Step 4: Enable Protocol Transition When Necessary
Protocol transition lets services obtain Kerberos tickets for users who authenticated through non-Kerberos methods. Check the “Use any authentication protocol" option in the Delegation tab if your frontend service handles forms-based authentication, certificate authentication, or other non-Kerberos login methods. Without this setting, delegation only works when users authenticate directly with Kerberos.
This capability increases risk because it allows the service to request tickets for any user without proof that the user has actually authenticated. Only enable protocol transition when the application architecture requires it, and implement additional logging to track when services use this privilege.
Step 5: Test and Validate Delegation Configuration
Testing catches configuration errors before they affect production users. Log into the frontend service as a test user and attempt to access backend resources. Use network traces or Kerberos event logs to verify that the service receives tickets with the correct user identity. Failed attempts generate specific error codes, e.g., KRB_AP_ERR_MODIFIED typically indicates SPN issues, while KDC_ERR_BADOPTION suggests delegation permission problems.
Document your delegation configurations in a central repository. Include which services have delegation enabled, what they can access, and why the delegation is necessary. This documentation becomes essential during security audits and when troubleshooting authentication issues. Regular reviews of these configurations help you identify and remove delegation permissions that are no longer needed as your infrastructure evolves.
Protecting Against Constrained Delegation Attack Vectors
Constrained delegation creates specific attack opportunities when misconfigured or left unmonitored. Attackers who compromise service accounts with delegation privileges can move laterally across your network, accessing resources as if they were legitimate users. Understanding these threats and implementing detection mechanisms transforms delegation from a security liability into a controlled, monitored capability.
Common Attack Techniques Targeting Delegation
The most common constrained delegation attack starts with compromising a service account configured for delegation. Once attackers gain control of this account (through password spraying, credential dumping, or exploiting service vulnerabilities), they can request service tickets for any user to access the permitted backend services. This technique, sometimes called “delegation abuse," allows attackers to pivot from a compromised web server to backend databases or file servers.
Resource-based constrained delegation introduces another attack vector. Attackers with write access to a computer object's msDS-AllowedToActOnBehalfOfOtherIdentity attribute can add their own controlled accounts to the delegation list. This grants their account permission to impersonate users when accessing that resource. The attack requires specific Active Directory permissions, but these are often granted too broadly in environments with complex delegation structures.
Protocol transition abuse represents a third category. When services have both constrained delegation and protocol transition enabled, attackers can obtain service tickets for any domain user without possessing that user's credentials or proof of authentication; they simply need to compromise the service account itself. This makes protocol transition particularly dangerous and highlights why it should only be enabled when absolutely necessary for application functionality.
Monitoring and Detecting Suspicious Delegation Activity
Detection starts with logging the right events. Windows Event ID 4769 (Kerberos service ticket request) shows when services request tickets on behalf of users. Filter these logs for ticket requests involving accounts configured for delegation, then look for patterns that deviate from normal application behavior. A web server requesting tickets at 3 AM or accessing services outside its configured list warrants immediate investigation.
Effective delegation monitoring requires correlating ticket requests with expected application behavior and flagging deviations in real time.
Changes to delegation settings themselves signal potential compromise. Monitor Event ID 4738 (user account change) and Event ID 4742 (computer account change) for modifications to the msDS-AllowedToDelegateToAccount and msDS-AllowedToActOnBehalfOfOtherIdentity attributes. Attackers establishing persistence often modify these properties to maintain access even after you've addressed the initial compromise vector.
Strengthening Your Environment With Cayosoft Guardian
Cayosoft Guardian provides continuous monitoring specifically designed for Active Directory security, including delegation configurations. The platform tracks changes to delegation settings in real time, alerting your team immediately when someone modifies a service account's delegation properties or adds new entries to resource-based delegation lists. These instant notifications let you investigate changes while the context is fresh rather than discovering modifications during quarterly audits.
The tool's attribute-level recovery capability addresses constrained delegation attack scenarios directly. If attackers modify delegation settings to establish persistence, Guardian can restore the affected account or computer object to its pre-attack state within seconds. This granular recovery approach means you don't need to restore entire organizational units or roll back broader changes; you fix exactly what the attacker modified.
Guardian integrates with SIEM platforms to correlate Active Directory changes with authentication patterns. When the system detects someone adding delegation permissions to a service account, it can automatically cross-reference this change against recent authentication failures, privilege escalations, or other indicators of compromise. This context helps security teams distinguish between legitimate administrative changes and attacker activity. Schedule a demo with our team to see how Guardian's monitoring and recovery capabilities can protect your delegation configurations.
Conclusion
Constrained delegation remains a necessary feature for multi-tier applications, but treating it as a set-and-forget configuration creates significant security exposure. The implementation approach you choose (traditional or resource-based) matters less than establishing proper oversight through continuous monitoring and regular audits. Organizations that document their delegation relationships, enforce least-privilege principles for service accounts, and track configuration changes detect attacks before credential theft escalates into full environment compromise. Make sure your delegation settings always reflect current application requirements, not historical decisions made years ago when your infrastructure looked different.
Building resilience requires both prevention and response capabilities. Configure only the delegation paths your services actually need, eliminate protocol transition where possible, and establish alerting for suspicious ticket requests or attribute modifications. When incidents occur, rapid restoration of affected accounts prevents attackers from maintaining persistence through modified delegation settings. Start by inventorying your existing delegation configurations, then establish baseline monitoring for changes and anomalous authentication patterns that indicate potential abuse.
FAQs
Can constrained delegation work across different Active Directory forests?
Resource-based constrained delegation handles cross-forest scenarios more effectively than traditional methods, though it requires proper trust relationships between forests and Windows Server 2012 or later. Traditional Kerberos constrained delegation has limited cross-forest capabilities and needs specific trust configurations to function properly.
What permissions do I need to configure delegation for service accounts?
Traditional constrained delegation typically requires Domain Admin rights or specifically delegated permissions to modify the frontend service account's properties. Resource-based delegation only requires write access to the backend resource's msDS-AllowedToActOnBehalfOfOtherIdentity attribute, making it more suitable for decentralized administration.
How do I know if my service account has been compromised and is being used for delegation abuse?
Monitor Event ID 4769 for unusual Kerberos service ticket requests, such as tickets requested during off-hours, from unexpected IP addresses, or for services outside the normal access pattern. Look for Event IDs 4738 and 4742 to detect unauthorized changes to delegation attributes on user or computer accounts.
Should I use protocol transition when setting up delegation for web applications?
Only enable protocol transition if users authenticate through non-Kerberos methods like form-based or certificate authentication while the backend services require Kerberos. This feature increases security risk because it allows services to obtain tickets for any user without proof of authentication, so implement additional logging when necessary.
What's the difference between a Service Principal Name and a User Principal Name in delegation?
Service Principal Names (SPNs) identify specific service instances and are required for Kerberos authentication in delegation scenarios, while User Principal Names (UPNs) identify user accounts for login purposes. You configure delegation by specifying the SPNs of the backend services that the frontend service can access on behalf of users.
Top comments (0)