Connect
Updated on September 29, 2025
Resource-Based Constrained Delegation (RBCD) is a feature in Windows Server Active Directory. It provides a secure, modern method for delegating a user’s or service’s authentication to another service. Unlike previous delegation models, RBCD shifts control from the delegating account to the resource itself. This allows a resource owner to explicitly define which accounts can be trusted to delegate access to them. It significantly enhances security and provides more granular, auditable control over delegation. This model is crucial for IT professionals managing distributed applications and services that require secure, cross-service communication.
Definition and Core Concepts
Resource-Based Constrained Delegation is a Kerberos delegation mechanism. It enables a service (the front-end service) to impersonate a user and access a resource (the back-end service) on that user’s behalf. What makes RBCD unique is that the configuration is stored on the resource object in Active Directory (AD), rather than on the front-end service account. This allows the resource owner, who often lacks broad administrative privileges, to manage delegation permissions for their specific resource.
Foundational Concepts
- Kerberos Delegation: A feature of the Kerberos protocol that allows a service to act on behalf of a user.
- Service Principal Name (SPN): A unique identifier for a service instance. RBCD relies on SPNs to identify the services involved in the delegation.
- Front-End Service: The service that a user connects to. It needs to impersonate the user to access a back-end resource.
- Back-End Resource (or Target Service): The service that the front-end service needs to access. This is where the delegation configuration is stored.
- msDS-AllowedToActOnBehalfOfOtherIdentity: This is the key attribute on the back-end resource’s AD object. It contains a list of the front-end service accounts permitted to delegate to this resource.
How It Works
RBCD is a key part of the Kerberos S4U2Proxy (Service for User to Proxy) extension. The delegation process is a secure, multi-step exchange of Kerberos tickets. The process unfolds as follows.
1. Initial Authentication (User to Front-End)
A user authenticates to the front-end service. They typically receive a Kerberos ticket for it.
2. S4U2Self (Service for User to Self)
The front-end service uses the S4U2Self protocol extension to request a new Kerberos ticket for the user’s account from the Key Distribution Center (KDC). This ticket is granted to the front-end service but impersonates the user. This step is a prerequisite for S4U2Proxy.
3. S4U2Proxy (Service for User to Proxy)
The front-end service, now holding the user’s impersonation ticket, requests a service ticket for the back-end resource from the KDC. In this request, it presents the user’s ticket it just acquired.
4. KDC Validation
The KDC performs a critical check. It inspects the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the back-end resource’s AD object. If the front-end service’s account is listed in this attribute, the KDC grants the service ticket. If not, the request is denied.
5. Access
The front-end service uses the newly acquired service ticket to access the back-end resource on the user’s behalf. The back-end service sees the request as coming from the user’s account.
Key Features and Components
Resource-Centric Control
The primary advantage is that the resource owner has full control over who can delegate to their resource. This promotes a least-privilege security model.
Enhanced Security
RBCD is more secure than the older “unconstrained” and “constrained” delegation models. It prevents the delegation from being used to access other services on the network (lateral movement). The permission is strictly tied to a single resource.
No Domain Admin Privileges Required
A resource owner can configure RBCD permissions for their own resource. This does not require a Domain Admin to configure the delegation on the front-end service.
Auditable
The delegation configuration is stored as a clear attribute on the resource object. This makes it easy to audit and review.
Use Cases and Applications
RBCD is the recommended delegation method for modern, distributed application architectures in Windows environments. Common use cases include:
- Web Services and APIs: A web front-end service needing to access a back-end database on behalf of the user.
- Distributed Applications: A multi-tier application where one service needs to securely connect to another service to complete a user’s request.
- Exchange and SharePoint: Internal services that need to access user mailboxes or files with the user’s context.
Advantages and Trade-offs
Advantages
RBCD offers superior security, granular control, simplified administration, and a clear audit trail. It is the modern best practice for Kerberos delegation.
Trade-offs
The setup can be complex due to the specific requirements of the Kerberos protocol and the need for correct SPN registration. It is also not supported on older operating systems prior to Windows Server 2012 R2.
Key Terms Appendix
- Kerberos Delegation: The ability for a service to act on a user’s behalf.
- Service Principal Name (SPN): A unique identifier for a service instance.
- S4U2Proxy: A Kerberos protocol extension that enables a service to request a ticket to a back-end service on behalf of a user.
- Key Distribution Center (KDC): The central server that issues and manages Kerberos tickets.
- Lateral Movement: The technique used by attackers to move from one system to another within a network.
