Account Operators is pre-privileged access, not a harmless AD role

At a glance

What this is: This article explains why the Active Directory Account Operators group is dangerous: it can reshape identities, credentials, group membership, and delegation paths across the domain.

Why it matters: IAM and AD teams need to treat delegated directory administration as an identity risk, because broad object control can become an escalation path without ever touching Domain Admin directly.

Context

Account Operators is an Active Directory delegated administration group, but the practical question is not what the label says. The security question is what that role can do to identities, credentials, and group relationships across the domain, because those are the controls attackers manipulate first.

The governance gap here is a common one: teams often assume that if a group cannot directly edit protected admin groups, it is safe enough. In reality, control over users, computers, passwords, SPNs, and nested groups can still produce privilege escalation, persistence, and operational disruption.

For directory teams, this is an identity governance problem as much as an access control problem. The article shows why pre-privileged access in Active Directory deserves the same scrutiny as explicitly privileged roles, especially where lifecycle controls and delegated rights are loosely managed.

Key questions

Q: What breaks when Account Operators is left enabled in Active Directory?

A: Broad identity-write access becomes a privilege pathway, not just an administrative convenience. Attackers can reset passwords, create backdoor accounts, alter group membership, and prepare delegation abuse without touching Domain Admins directly. That is why the role should be treated as pre-privileged access with escalation potential, not as a low-risk support group.

Q: Why can Account Operators increase escalation risk even without Domain Admin membership?

A: Because privilege in Active Directory comes from control over identities, not just from formal admin labels. A member can create backdoor accounts, modify group membership, reset passwords for useful targets, and prepare Kerberoasting or delegation abuse. Those actions create access paths that can outlive the original account compromise and widen the blast radius.

Q: What are the signs that display specifier abuse may be happening in Active Directory?

A: Look for unexpected changes to display specifier objects in the Configuration partition, especially edits to multi-valued menu attributes on object classes such as user. Suspicious additions that mimic legitimate admin actions, unusual scripts or UNC paths, and changes with no clear business justification are strong indicators that the feature is being abused.

Q: Should organisations treat Account Operators as Tier 0 access?

A: Yes, when the role can rewrite authentication, delegation, and group structure across the domain. Even if it cannot directly touch protected admin groups, it can still generate pathways into them. Organisations should govern it like high-risk access, with tight delegation, strong monitoring, and a bias toward removal where the role is not strictly required.

Technical breakdown

What Account Operators can change in Active Directory

Account Operators is a built-in delegated group that can create, modify, and delete many user, group, and computer objects in the domain. That includes password resets, account enablement or disablement, SPN edits, and non-protected group membership changes. The important technical point is that privilege in Active Directory is not limited to direct membership in a top-tier admin group. Control over objects that define authentication, delegation, and group nesting can be enough to reshape the trust fabric and create escalation paths.

Practical implication: inventory what this group can alter in your directory and treat those objects as attackable control points, not routine support functions.

Why AdminSDHolder does not remove the risk

Protected groups such as Domain Admins are guarded by AdminSDHolder and SDProp, but that protection is not instantaneous. SDProp restamps protected ACLs on a cycle of about 60 minutes by default, which means there is a window where newly changed or drifted permissions can still be abused. In identity governance terms, this is an eventual-consistency problem: the directory corrects itself later, not at the moment of misuse. That delay creates time for backdoor creation, secret exposure, or follow-on privilege actions before investigators see the final state.

Practical implication: monitor for short-lived changes and rapid add-remove patterns around protected objects, because the risky state may disappear before standard reviews catch it.

How Account Operators enables realistic escalation paths

The abuse paths are straightforward once a threat actor controls an Account Operators credential. They can create backdoor users, reset passwords for service or delegated admin accounts, edit SPNs to create Kerberoastable targets, and create computer objects that support delegation abuse such as resource-based constrained delegation. None of those steps require direct Domain Admin membership at the outset. The mechanics matter because attackers often work through identity relationships, not obvious admin banners. That makes this group a privilege amplifier across the identity plane rather than a narrow administrative convenience.

Practical implication: correlate Account Operators activity with account creation, password resets, SPN edits, and computer object creation to spot early-stage escalation.

Threat narrative

Attacker objective: The attacker wants to convert delegated directory control into durable privilege, persistence, and lateral movement across Active Directory.

1. Entry occurs when an attacker compromises an Account Operators credential or account with delegated directory rights.
2. Credential or object abuse follows as the actor creates users, resets passwords, edits SPNs, or creates computer accounts to prepare escalation paths.
3. Escalation happens through nested group manipulation, delegation abuse, or Kerberoasting setup that turns directory control into broader access.
4. Impact is domain-level persistence and privilege expansion without ever needing obvious Domain Admin membership first.

Breaches seen in the wild

• Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.
• Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Account Operators is pre-privileged access, not a benign support role: The group’s power comes from control over identities that carry privilege, not from a visible admin label. In Active Directory, object control over users, groups, computers, passwords, and SPNs is control over the trust fabric itself. The practical conclusion is that delegation reviews must focus on what a role can rewrite, not just what it is named.

Pre-privileged access is where escalation really begins: Mature identity programmes often overfocus on the highest tier groups and underfocus on the groups that can shape those tiers indirectly. Account Operators can reset credentials, seed backdoor principals, and alter group structure in ways that create privilege pathways without touching Domain Admin directly. That means privilege governance has to inspect intermediate control points, not only crown-jewel groups.

Administrative restrictions do not remove attack utility when the object graph is writable: Being blocked from direct modification of protected groups does not eliminate abuse if the actor can create alternative paths to the same outcome. SPN manipulation, computer object creation, and delegated group membership changes are enough to generate reusable access and escalation options. Practitioners should treat the object graph as the real security boundary.

AdminSDHolder creates eventual protection, not immediate safety: The 60-minute SDProp cycle means protected state can lag behind real-world abuse. That is a governance assumption failure: defenders often behave as though protected objects are continuously enforced when the directory only converges later. The implication is that short-lived identity changes must be monitored as first-class security events, because they can still produce lasting compromise.

Named concept: privilege amplification through identity control: This article shows a specific failure mode where delegated directory rights become a force multiplier for escalation. The group does not need to be top-tier on paper to behave like Tier 0 in practice. The practitioner takeaway is to classify any role that can rewrite authentication or delegation paths as high-risk access, regardless of its title.

What this signals

Delegated directory roles can function as privilege amplifiers: Security teams should stop classifying roles only by whether they directly modify Domain Admin. If a role can change passwords, group membership, SPNs, or computer objects, it can still create escalation paths that behave like privileged access in practice.

Identity lifecycle controls are the detection surface that matters most: For this kind of abuse, the most valuable telemetry is not just authentication failure data, but account creation, password reset, SPN change, and membership change events. Those lifecycle signals show when a supposedly delegated role has crossed into privilege shaping.

Short-lived abuse is harder to catch than static privilege: The AdminSDHolder cycle means the directory may correct the state after the useful work is done. Programme owners should therefore tune monitoring around transient changes, not only around who is privileged at the end of the hour.

For practitioners

• Empty the Account Operators group Remove all membership where possible and keep the group empty unless there is an explicit, documented operational need that cannot be met through narrower delegation.
• Replace broad delegation with scoped OU permissions Use targeted delegation on only the OUs and object classes that require management so the role cannot rewrite unrelated identities, groups, or computer objects.
• Watch for identity lifecycle abuse signals Alert on account creation, password resets, account enablement, SPN changes, and unusual group membership edits performed by this group or by accounts it touches.
• Restrict computer account creation Lower MachineAccountQuota where appropriate and prevent Account Operators from creating computer objects that could support delegation or impersonation paths.
• Tighten protected-object monitoring Correlate ACL changes on AdminSDHolder and protected groups with rapid privilege changes so short-lived abuse does not disappear between review cycles.

Key takeaways

• Account Operators is dangerous because it can reshape identities and delegation paths, which are the real levers of privilege in Active Directory.
• The article shows that password resets, SPN edits, computer account creation, and group changes can all become escalation paths without direct Domain Admin membership.
• Defenders should remove the group where possible and monitor identity lifecycle events, protected-object changes, and transient privilege activity when they cannot.

Key terms

• Account Operators: A built-in Active Directory delegated administration group that can manage many identity objects across the domain. Its members can often create, modify, and delete users, groups, and computers, which makes the role a security boundary rather than a simple support function.
• AdminSDHolder: A protected Active Directory object that stamps security settings onto highly privileged groups and accounts. It exists to keep critical administrative principals from inheriting weaker permissions that apply elsewhere in the directory. Changes to this template affect how sensitive objects are protected and who can read their memberships.
• SPN Abuse: A misuse pattern where an attacker alters service principal names to create or expose Kerberoastable targets. In directory environments, SPN changes matter because they can turn an otherwise ordinary account into a credential collection or escalation opportunity.
• Privilege Amplification: A condition where a low-trust input path can influence a high-trust action path. In agentic systems, that happens when model-facing content can shape commands, commits, or credential use, allowing an attacker to get more impact than their direct access should permit.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.