The AddAllowedToAct permission in Active Directory allows an account to modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on computer or service accounts. This permission is crucial for configuring Kerberos Resource-Based Constrained Delegation (RBCD), enabling services to impersonate users securely and access resources on their behalf. It facilitates flexible authentication scenarios and simplifies delegation configurations within the network.
However, if misconfigured, the AddAllowedToAct permission can introduce significant security vulnerabilities. An attacker with this permission can add their own account to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of a target computer or service account. This grants them the ability to impersonate any user when accessing services on that machine. Exploiting this vulnerability could lead to unauthorized access, privilege escalation, and full compromise of the system, as the attacker can act on behalf of any user—including domain administrators—to access sensitive resources.
Identification
PowerShell
Using the Active Directory PowerShell module, you can enumerate AddAllowedToAct entries.
1. Find-AddAllowedToAct Function
2. Scan all domain Service Principal Names objects
3. Scan a specific object
4. Using SearchBase to limit the searching scope
.NET Directory Services
By leveraging PowerShell’s built-in .NET DirectoryServices namespace, you can enumerate AddAllowedToAct entries without relying on any external modules or dependencies.
1. Find-AddAllowedToActSimple function
2. Scan all Service Principal Names objects in the domain
3. Scan a specific object
Active Directory Users and Computers
1. Open Active Directory Users and Computers on a Windows server.
2. Right-click the object and select Properties.
3. In the Properties window, go to the Security tab.
4. Click the Advanced button to open the Advanced Security Settings dialog.
5. In the Advanced Security Settings window, locate and select the relevant Access Control Entry (ACE) for the user or group you wish to review.
6. Click Edit to modify the selected ACE.
7. In the permissions list, locate and check the option Write msDS-AllowedToActOnBehalfOfOtherIdentity if you intend to grant it, or clear it to remove the permission.
8. Click OK to save and close the dialogs.
ADCU
Exploitation
This permission can be exploited on Windows systems using tools like Rubeus and on Linux systems with the impacket suite. After exploitation, an attacker can obtain the target computer's credentials.
Windows
Create a new computer
This step can be skipped if a controlled SPN account already exists; otherwise, create a new computer using standin.
Create computer using standin
To write msDS-AllowedToActOnBehalfOfOtherIdentity attribute
Write using AdModule
Or
Write using standin
To get a TGT for the controlled SPN account
TGT using Rubeus
To get a service ticket for an impersonated user
TGS using Rubeus
To check admin access on the target
Check admin access
Linux
Creating a new Computer
This step can be skipped if a controlled SPN account already exists; otherwise, create a new computer using impacket-addcomputer.
To write msDS-AllowedToActOnBehalfOfOtherIdentity attribute
To get a service ticket
To execute on the target machine
Example:
To create a new computer
To write msDS-AllowedToActOnBehalfOfOtherIdentity Attribute
Add computer & rbcd
To get a service ticket
Getting TGS
Then
Execute on target machine using psexec
Mitigation
Access Control Entries identified as dangerous should be removed by following the steps below.
1. Open Active Directory Users and Computers and enable the 'Advanced Features' option.
2. Double-click the affected object and open the Security tab.
3. In the Security tab, click the 'Advanced' button, then edit the dangerous object's Access Control Entry.
4. Remove the Write msDS-AllowedToActOnBehalfOfOtherIdentity permission from the ACE.
5. Click OK and Apply to save your changes.
ADUC
Detection
Adding new Access Control Entries to Active Directory objects updates the ntSecurityDescriptor attribute on those objects.
These changes can be detected using Event IDs 5136 and 4662 to identify dangerous modifications to objects.
function Find-AddAllowedToAct {
[CmdletBinding()]
param ([string]$Target = $null,[string]$SearchBase = $null,[string]$OutputPath = "AddAllowedToAct.csv")
Import-Module ActiveDirectory
Write-Host "Searching for permissions on the msDS-AllowedToActOnBehalfOfOtherIdentity attribute..."
$AccessControlType = [System.Security.AccessControl.AccessControlType]::Allow
$ActiveDirectoryRights = [System.DirectoryServices.ActiveDirectoryRights]::WriteProperty
# Guid of Write msDS-AllowedToActOnBehalfOfOtherIdentity
$AddAllowedToActPermissionGuid = "3f78c3e5-f79a-46bd-a0b8-9d18116ddc79"
$foundAcls = @();$objectsToScan = @()
try {
if ($Target) {
Write-Host "Searching for permissions on specific object: '$Target'."
$specificObject = Get-ADObject -Identity $Target -Properties servicePrincipalName, nTSecurityDescriptor -ErrorAction Stop
if ($specificObject) {
if ($specificObject.servicePrincipalName) {
$objectsToScan += $specificObject
} else {Write-Output "Object '$Target' does not have a Service Principal Name and is not a valid target for this check.";return}
} else {
Write-Output "Object '$Target' not found.";return}} else {
Write-Host "Searching for all Active Directory objects with a Service Principal Name."
$actualSearchBase = if ($SearchBase) { $SearchBase } else { (Get-ADRootDSE).DefaultNamingContext }
$objectsToScan = Get-ADObject -Filter 'servicePrincipalName -like "*"' -Properties servicePrincipalName, nTSecurityDescriptor -SearchBase $actualSearchBase -ErrorAction Stop
}
if (-not $objectsToScan) { Write-Output "No Active Directory objects with a Service Principal Name were found to scan.";return}
foreach ($obj in $objectsToScan) {
$ObjectDistinguishedName = $obj.DistinguishedName
try {
$acl = Get-Acl -Path "AD:$ObjectDistinguishedName"
foreach ($ace in $acl.Access) {
if ($ace.AccessControlType -eq $AccessControlType -and ($ace.ActiveDirectoryRights -band $ActiveDirectoryRights) -and ($ace.ObjectType -eq $AddAllowedToActPermissionGuid) -and -not $ace.IsInherited -and -not $isExcluded) {
$foundAcls += [PSCustomObject]@{
'Vulnerable Object' = $ObjectDistinguishedName
'Internal Threat' = $ace.IdentityReference.Value # Get the string representation
}}}}
catch {Write-Warning "Could not retrieve ACL for '$ObjectDistinguishedName': $($_.Exception.Message)"}}}
catch {Write-Error "Failed to retrieve Active Directory objects: $($_.Exception.Message)";return}
if ($foundAcls.Count -gt 0) {
Write-Host "Found $($foundAcls.Count) Active Directory object(s) with 'WriteProperty' permissions on the RBCD attribute"
try {
$foundAcls | Sort-Object -Unique 'Vulnerable Object', 'Internal Threat' | Export-Csv -Path $OutputPath -NoTypeInformation -Encoding UTF8
Write-Output "Results exported successfully to '$OutputPath'"
} catch {Write-Error "Failed to export results to CSV file '$OutputPath': $($_.Exception.Message)" }
} else {Write-Output "No Active Directory objects found with 'WriteProperty' permissions on the RBCD attribute"}}
