msDS-AllowedToActOnBehalfOfOtherIdentity is a directory attribute that allows one principal to act on behalf of another in constrained delegation scenarios. If an attacker can write to it, they may impersonate users to targeted services. Administrators should tightly control write permissions, review delegation settings, and monitor for unexpected changes to this attribute.
How the attribute works in practice
msDS-AllowedToActOnBehalfOfOtherIdentity is the attribute that makes resource-based constrained delegation possible. Instead of trusting a service account to delegate broadly, the target service stores an access control list that says which security principals may act on behalf of other users to that specific resource. That makes delegation local to the service, not global to the directory.
When configured correctly, it lets a delegated service obtain service tickets for users to the target service through the Kerberos S4U flow. The critical point is that the right to delegate is controlled by write access to the target object, so the security of the attribute depends on who can modify it and on how tightly the target service’s ACLs are protected.
Because the trust decision is recorded on the resource itself, this attribute can be easier to scope than older delegation models, but it is also easy to abuse if an attacker gains write permissions on a computer object or service account. NHIMG’s Kerberos Delegation Security Guide is the best place to map that trust model against constrained delegation, S4U, and RBCD abuse paths.
Why write access is the real security boundary
The attribute does not become dangerous because delegation exists. It becomes dangerous when a principal can add or replace allowed delegates and therefore choose who can impersonate users to the service. In practice, that means the write permission itself is the high-value control, not just the presence of the attribute.
This is why administrators should treat object ownership, ACL inheritance, and delegated admin roles as part of the same control surface. If a low-trust team, automation account, or compromised operator can edit the attribute, they can often turn a legitimate service into a delegation target for impersonation.
That control boundary should be reviewed alongside broader identity hardening, including service account governance and detection of unexpected delegation changes. The Identity Threat Detection and Response Guide is a useful companion when you need to connect delegation abuse to identity attack detection and response.
Where abuse shows up and what to check first
The most practical failure mode is not a broken configuration at the moment of setup, but a later change that quietly expands who can impersonate users. Watch for newly modified delegation attributes, especially on computer objects and service accounts that were not expected to participate in constrained delegation.
Also check whether the target service actually needs this trust relationship. If the service does not need to accept delegated access, the safest posture is to remove the delegation path entirely and keep the object from becoming a standing impersonation bridge.
For defenders, the detection value is in correlating delegation changes with privileged directory writes, service account changes, and unusual service-ticket activity. That is the kind of pattern that can indicate an attacker is preparing lateral movement through a trusted service rather than trying to break authentication directly.
Risk and Threat Considerations
Misuse of this attribute can create direct impersonation risk: a writeable delegation target can let an attacker present themselves as another user to the service, which may expose data, actions, or downstream trust relationships that the user normally controls.
Failure mechanism: An attacker who can write the attribute adds a principal they control, then uses delegated Kerberos flows to obtain access as a victim user against the targeted service, often without needing the victim’s password.
Impact: The result can be unauthorized access, privilege misuse inside the service, and movement from a single compromised object to broader identity abuse if the service is trusted by other systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Write access to the delegation attribute must be tightly limited. |
| AU-2 — Event Logging | Unexpected delegation changes need audit visibility to detect abuse. | |
| IA-5 — Authenticator Management | Delegation abuse can expose service credentials and access paths. | |
| Recommendation — Restrict attribute write rights to the smallest set of trusted admins. Log directory writes that change delegation-related attributes. Rotate exposed service credentials after delegation abuse is suspected. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The core issue is controlling who can modify the delegation setting. |
| Recommendation — Review and remove unnecessary write access to delegation-bearing objects. | ||
| MITRE ATT&CK | T1134 — Access Token Manipulation | RBCD abuse enables impersonation by leveraging trusted identity flows. |
| Recommendation — Hunt for impersonation and delegation abuse patterns on trusted services. | ||
Practitioner Guidance
What to verify: Confirm who can write the attribute on every object that uses resource-based constrained delegation, and treat inherited ACLs as part of that review. If you cannot explain why a principal needs write access, assume the exposure is too broad.
What to prioritise: Start with services that are high-value, high-trust, or exposed to delegated administration, because those objects create the highest blast radius if the attribute is modified maliciously or accidentally.
Common mistake: Teams often review whether delegation is “enabled” but do not review whether the right to change the delegation list is tightly controlled. That is the more important question for this attribute.
Practitioner takeaway: Treat the write permission on msDS-AllowedToActOnBehalfOfOtherIdentity as a privileged trust boundary, because whoever controls it effectively controls who can impersonate users to that service.