Who is accountable for reviewing and restricting delegation permissions in Active Directory?

Why This Matters for Security Teams

Delegation in active directory is not just an administration setting. It is an authorization boundary that can let one account act on behalf of another, sometimes across highly privileged objects. That makes ownership clear in principle, but accountability shared in practice: directory administrators may configure it, while security governance must verify that the delegation model still matches least privilege and approved change control. The risk is especially high where Resource-Based Constrained Delegation, service accounts, and legacy admin groups overlap.

NHIMG research shows why this matters: 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That pattern is visible in incidents like the Cisco Active Directory credentials breach, where directory exposure quickly becomes a broader identity failure. The operational question is not whether delegation exists, but whether anyone is continuously reviewing who can assign it, inherit it, or abuse it. The OWASP Non-Human Identity Top 10 also treats over-privileged machine identities as a primary control gap. In practice, many security teams discover delegation drift only after a privileged path has already been used, rather than through deliberate review.

How It Works in Practice

Accountability should be split into three layers. Identity and directory administrators own the technical configuration, security engineering defines guardrails, and governance or risk teams verify the control stays aligned with policy. That means documenting who can modify delegation settings, who approves exceptions, and how often sensitive objects are reviewed. For AD, that includes constrained delegation, unconstrained delegation, and Resource-Based Constrained Delegation, especially when those settings apply to servers, tier-0 assets, or service accounts that can impersonate users.

In practical terms, a defensible review process usually includes:

• Inventorying all accounts and computer objects with delegation enabled.
• Separating approved business use from inherited or stale delegation rights.
• Monitoring changes to sensitive attributes such as servicePrincipalName, msDS-AllowedToDelegateTo, and msDS-AllowedToActOnBehalfOfOtherIdentity.
• Restricting who can create or edit delegation on critical objects through least-privilege admin roles.
• Alerting on new delegation paths that cross trust boundaries or high-value administrative tiers.

NIST guidance on access control and continuous monitoring supports this model, particularly in NIST SP 800-53 Rev. 5 Security and Privacy Controls, where configuration management and access enforcement are expected to be auditable. For a broader NHI lens, NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks explains why service account privilege sprawl is so often missed until incident response. These controls tend to break down in large, hybrid AD environments because delegation is inherited through legacy groups, nested permissions, and application owners outside the security team.

Common Variations and Edge Cases

Tighter delegation review often increases operational overhead, so organisations must balance change speed against the risk of invisible privilege paths. The main tradeoff is between admin convenience and the need to prove that impersonation rights are still justified.

One common edge case is application dependency. Some workloads require delegation to function, but that does not mean the configuration should be permanent or broadly scoped. Best practice is evolving toward narrowly scoped approvals, explicit expiry dates, and recurring recertification for any delegation used by critical services. Another edge case is RBCD on server objects. If application or platform teams can modify those objects without security oversight, the control can be bypassed even when traditional user-based reviews look clean.

Where there is no universal standard yet is the exact frequency of delegation recertification. Current guidance suggests using risk-based intervals: more frequent reviews for tier-0 systems, less frequent reviews for low-impact application tiers, and immediate review after any domain trust, admin group, or service ownership change. NHIMG’s Ultimate Guide to Non-Human Identities is useful here because it frames delegation as part of the broader NHI lifecycle, not a one-time directory exception. When delegation permissions are not tied to an accountable owner, the directory eventually accumulates privileges that no one can explain, much less defend.

Related resources from NHI Mgmt Group

• Who should be accountable for controlling sensitive password-option delegation in Active Directory?
• Who is accountable for hardening Active Directory compatibility settings when legacy defaults remain enabled?
• How should security teams reduce Tier 0 risk from misconfigured Active Directory permissions?
• Who is accountable for preventing Domain Controller compromise in Active Directory environments?