👉 Overview
👀 What ?
Windows Resource-based Constrained Delegation (RBCD) is a security feature in Microsoft's Active Directory (AD) that allows a service to impersonate a user to other services, but with certain limitations. This feature was designed to provide flexibility in enterprise environments where services need to perform actions on behalf of users, while minimizing the security risks associated with service impersonation.
🧐 Why ?
RBCD is important because it allows administrators to control which services can impersonate users, and to which other services. This provides a balance between functionality and security in complex enterprise environments. Without such controls, any compromised service could impersonate any user to any other service, leading to a full domain compromise.
⛏️ How ?
To use RBCD, administrators must first enable it in the AD domain. Then, they must configure the security descriptor of each service that needs to delegate permissions, specifying which users it can impersonate and to which other services. The security descriptor is an Access Control List (ACL) that lists the users and services allowed for delegation. Administrators can use PowerShell commands or the AD Users and Computers management console to configure these settings.
⏳ When ?
RBCD was introduced in Windows Server 2012 R2, as an enhancement to the original Kerberos Constrained Delegation (KCD) feature. It has been included in all subsequent versions of Windows Server.
⚙️ Technical Explanations
Resource-based Constrained Delegation (RBCD) in Windows is a security measure that modifies the process of authentication in Active Directory (AD). This feature is predominantly focused on Kerberos, a network authentication protocol.
In a typical Kerberos setup, a service requests a Ticket-Granting Ticket (TGT) for a user from the Key Distribution Center (KDC). The KDC is a service that issues tickets to users and computers in a Windows domain.
The novel aspect of RBCD is how it influences this typical process. When a service requests a TGT for a user, the KDC checks the service's security descriptor. A security descriptor is a data structure that contains security information associated with a protected object, such as a service in this case.
If RBCD is enabled and the service is granted permission to impersonate the user to the target service, the KDC includes the service's Security Identifier (SID) in the TGT. A SID is a unique value that identifies a security principal (a user or group) in Windows. Including the SID in the TGT is a way of providing access to the service to act on behalf of the user.
When the service then presents the TGT to the target service, the target service checks the SID against its own security descriptor. If it finds the SID listed, it processes the request as if it were coming directly from the user. This process provides a level of control and security, ensuring that only approved services can impersonate users and only to specific other services.
RBCD was introduced in Windows Server 2012 R2 as an enhancement to the original Kerberos Constrained Delegation (KCD) feature. It offers a balance between functionality and security in complex enterprise environments, allowing certain services to perform actions on behalf of users while minimizing the security risks associated with service impersonation.
Here's an example of how you might use Windows Resource-based Constrained Delegation (RBCD) in a real-world scenario, specifically for a service named ServiceA
to impersonate a user to another service named ServiceB
.
- Enable RBCD in Active Directory
First, you need to enable RBCD in your Active Directory domain. This can be done using the AD Users and Computers management console or PowerShell commands.
- Configure Security Descriptor for ServiceA
Next, you would configure the security descriptor for ServiceA
. This involves specifying which users it can impersonate and to which other services. Below is an example of a PowerShell command that might be used:
Set-ADUser -Identity ServiceA -PrincipalsAllowedToDelegateToAccount ServiceB
In this case, ServiceA
is allowed to delegate to ServiceB
.
- ServiceA Requests a Ticket-Granting Ticket (TGT)
When ServiceA
needs to perform an action on behalf of a user, it requests a TGT for that user from the Key Distribution Center (KDC). This happens automatically in the background when ServiceA
tries to authenticate to ServiceB
as the user.
- KDC Checks ServiceA's Security Descriptor
The KDC checks ServiceA
's security descriptor. If RBCD is enabled and ServiceA
has been granted permission to impersonate the user to ServiceB
, the KDC includes ServiceA
's Security Identifier (SID) in the TGT.
- ServiceA Presents the TGT to ServiceB
ServiceA
then presents the TGT to ServiceB
. ServiceB
checks the SID in the TGT against its own security descriptor. If it finds the SID listed, it processes the request as if it were coming directly from the user.
The whole process ensures that only approved services can impersonate users and only to specific other services, providing an additional level of control and security.