Resource-based constrained delegation (RBCD) is an Active Directory (AD) security feature that enables administrators to delegate permissions in order to manage resources more securely and with greater control. Introduced in Windows Server 2012 R2 as an enhancement to the traditional Kerberos constrained delegation (KCD), RBCD can help to reduce the risk of privilege escalation and to maintain the principle of least privilege.
Why use resource-based constrained delegation?
By using RBCD to delegate permissions at a granular level, administrators can ensure that users and services have the minimum access required to perform their tasks. Maintaining this level of least privilege reduces the potential for unauthorized access or misuse of sensitive information.
Resource-based constrained delegation is especially useful for service accounts that need to access resources on behalf of users but should not have full access to the users’ accounts. In RBCD, the delegation of permissions is based on resources rather than the service accounts that access those resources.
RBCD enables administrators to grant specific users or groups the ability to impersonate other users when accessing a particular resource, without giving them broad permissions to all resources within the domain. For example, suppose that:
- An application needs to access a file share but should not be able to delete or modify any files in the share. By enabling RBCD, you can configure the application service account to impersonate a user when accessing the file share. That way, the account will have access only to the files that the application needs.
- An application interacts with a database. To enhance security and control access to the database, you can use RBCD to delegate permissions to the application service account, allowing it to impersonate users when accessing the database.
How to enable resource-based constrained delegation
To enable the use of resource-based constrained delegation, you need to modify the AD attribute msDS-AllowedToActOnBehalfOfOtherIdentity. You modify the attribute to specify which security principals (such as users or groups) are permitted to delegate their privileges to a service running on the computer.
Once configured, the specified security principals can then delegate their privileges to the service account running the service. This delegation allows the service to impersonate those principals when accessing resources. The service can then access resources on behalf of users without requiring excessive permissions. This approach helps to maintain the principle of least privilege and enhance security.
To configure the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, you can use PowerShell or Lightweight Directory Access Protocol (LDAP)-based utilities. To prevent unauthorized access and maintain a secure environment when modifying the attribute, grant delegation permissions only to the necessary security principals.
Resource-based constrained delegation and AD security risks
Modifying the msDS-AllowedToActOnBehalfOfOtherIdentity attribute can have security implications if not performed carefully and with proper consideration. Some of the risks include:
- Privilege escalation: A service account or user gain unauthorized access to resources.
- Increased attack surface: An attacker exploits the delegated permissions of a compromised service or user account to gain access to sensitive resources or perform malicious actions.
- Complexity and management challenges: Managing and maintaining the msDS-AllowedToActOnBehalfOfOtherIdentity attribute can be complex, especially in large environments with multiple service accounts and resources. Misconfigurations or inconsistencies can lead to security gaps or unintended consequences.
- Auditing and monitoring difficulties: Tracking and auditing the use of delegated permissions can be challenging and require additional logging and monitoring to ensure that delegated permissions are used appropriately and securely.
Another potential security risk in the context of resource-based constrained delegation involves the krbtgt account. It is possible to configure Kerberos delegation on the krbtgt account itself. This capability is concerning because of the critical role that the krbtgt account plays in the Kerberos authentication process.
Authentication requires only generic write permissions, which is a lower level of privilege than domain admin rights. This means that an attacker—even one who has gained only limited permissions—might be able to manipulate the krbtgt account’s delegation settings without needing full administrative access to the domain.
This potentially dangerous situation can create a vulnerability in the Kerberos authentication process. An attacker who successfully exploits this vulnerability might be able to gain unauthorized access to resources or perform malicious actions in the domain, leading to serious security breaches. Examples include generating a Ticket Granting Service (TGS) request to the krbtgt account as any user, which has the effect of essentially generating a Ticket Granting Ticket (TGT) similar to a Golden Ticket.
The trouble doesn’t stop there. It has been discovered that this security risk can also occur in certain Azure AD environments. When using Azure AD and enabling the Seamless SSO feature, an automatic computer account object named AZUREADSSOACC is generated within your tenant. When this object is configured with RBCD, any user added to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on this object can impersonate any user within the Azure AD tenant.
As a result, you must ensure that this object’s attribute remains empty and is never configured. If you discover that the attribute has been configured, there is a high likelihood that your system has been compromised, putting your Azure AD tenant at significant risk.
Evaluating and remediating RBCD security risk
To identify potential misconfigurations and security vulnerabilities and to determine whether the security of your Active Directory has been compromised, you should conduct periodic AD security scans.
You can use tools like Purple Knight or Semperis Directory Services Protector (DSP). When executed in your environment, these tools scan and search for specific indicators, including signs of the exploits discussed here.
Such scans can help you answer important AD security questions:
- Is the krbtgt account configured with RBCD?
- Is the configuration set up correctly?
- Do any users have permissions to configure RBCD on the krbtgt account?
- Who can request a TGS with the permissions of the object it was configured on, such as the krbtgt account and all the domain controllers (DCs) within the forest?
Purple Knight and DSP scans specifically examine the krbtgt account and DC objects but also encompass all computer objects. This alert is highly unlikely to appear in a typical, non-compromised AD environment. If detected, it serves as a strong indication that your system has been compromised.
Figure 1, for example, shows a report identifying the krbtgt account with RBCD enabled for a bad actor.
Figure 2 shows a report that identifies the same issue for DCs in the environment.
Figure 3 shows a report identifying the security risk in an Azure AD environment.
Manage RBCD wisely to maintain AD security
Resource-based constrained delegation can be a powerful AD security feature for administrators who want to delegate permissions with increased control and security. But despite its benefits, RBCD requires careful management and monitoring of its configurations to prevent security risks and vulnerabilities.
Regular security scans, proper management of permissions, and adherence to the principle of least privilege are crucial in maintaining a secure environment. By understanding and addressing the potential risks associated with RBCD, administrators can leverage its capabilities to enhance the security and efficiency of their Active Directory infrastructure.
Learn more about AD security
