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

At a glance

What this is: This is an analysis of why the Active Directory Account Operators group is more dangerous than many defenders assume, because it can change identities, passwords, groups, and delegation paths across the domain.

Why it matters: It matters because IAM, PAM, and AD teams often underestimate groups that sit just below obvious admin tiers, even though they can still create escalation paths, persistence, and rapid compromise of the identity plane.

👉 Read Semperis's analysis of Account Operators abuse in Active Directory

Context

Account Operators is a delegated Active Directory role that can create, modify, and delete many identity objects, which means it sits closer to privileged access than its name suggests. In identity systems, the ability to change users, groups, service attributes, and computer objects is itself a security control boundary.

The governance gap is not only about whether the group can touch Domain Admins directly. It is about how much of the directory's trust fabric becomes writable once a member is compromised, and how quickly that can translate into password resets, group changes, delegation abuse, and persistence.

Semperis frames this as a dangerous underestimation problem, which is typical in enterprises that focus on obvious admin groups while overlooking lower-visibility delegated roles.

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 AdminSDHolder still leave a short exposure window for defenders?

A: Because protection is enforced by SDProp on a cycle, not continuously. That means a compromised identity can sometimes act, create persistence, or modify access state before the protected ACL is re-stamped. The practical issue is timing, not whether the protection exists at all.

Q: What are the signs that Account Operators abuse is underway?

A: Look for unusual account creation, password resets, SPN edits, nested group changes, and rapid add-and-remove membership activity from a member of the group. Those actions are especially suspicious when they target service accounts, delegated admins, or computer objects that were created recently.

Q: How should defenders reduce the risk from delegated Active Directory roles?

A: Use object-specific delegation instead of broad built-in groups, remove unused privileged memberships, and baseline every identity-changing action that a delegated role can perform. When the role can rewrite identity state, governance has to focus on what it can change, not just what its name implies.

Technical breakdown

What Account Operators can change in Active Directory

By default, Account Operators can create, modify, and delete many user, group, and computer objects in the domain. That includes password resets, account enablement and disablement, SPN changes, and non-protected group membership changes. The danger is not a single permission, but the combined ability to reshape identity state across large parts of the directory. In Active Directory, those actions are enough to create new access paths, alter authentication behaviour, and prepare later escalation without needing Domain Admin membership.

Practical implication: map every identity-changing permission granted to this group and treat each one as a potential escalation primitive.

Why AdminSDHolder does not eliminate the risk

Protected groups such as Domain Admins are shielded by AdminSDHolder, but that protection is not continuously enforced in real time. The SDProp process re-stamps protected ACLs on a periodic cycle, typically about every 60 minutes. That creates an eventual-consistency window where a newly changed object, a drifted permission, or a short-lived privileged condition can be abused before the protective ACL is re-applied. Defenders often assume the protection is immediate, but the operational gap is what attackers try to exploit.

Practical implication: monitor for short-lived privilege changes and protected-object ACL drift, not just final group membership state.

How identity object abuse turns into escalation

Once a threat actor has Account Operators-level access, they can use identity lifecycle actions as attack steps. Creating a backdoor account, resetting a service account password, adding an SPN to create a Kerberoastable target, or creating computer objects for delegation abuse are all realistic abuse paths. The technical pattern is distributed write access across the identity plane. That makes the role dangerous even when it cannot directly edit crown-jewel groups, because the attacker can pivot through the objects that those groups depend on.

Practical implication: correlate object creation, password reset, SPN modification, and nested group changes as one abuse chain.

Threat narrative

Attacker objective: The attacker wants to convert delegated identity control into durable access and escalation without needing obvious Domain Admin membership.

1. Entry occurs when an attacker compromises an Account Operators credential or session and gains delegated identity-management rights across the domain.
2. Escalation follows through password resets, backdoor account creation, SPN manipulation, or computer object abuse that enables indirect privilege growth.
3. Impact is achieved when the attacker persists through newly created identities, delegation paths, or hidden admin relationships that survive routine review.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Account Operators is pre-privileged access, not a harmless delegated role. The group can alter the objects that define trust, authentication, and access in Active Directory. That means it sits on the path to privilege even when it is not itself the final privileged destination. Practitioners should classify it as an escalation-sensitive identity role, not as routine support access.

The AdminSDHolder protection model assumes time is on the defender's side. That assumption is weak because SDProp is eventually consistent, not instantaneous. A default 60-minute enforcement cycle creates a practical window for short-lived abuse, especially when attackers can create, modify, and then abandon evidence before review catches up. Defenders should treat delay as part of the attack surface, not as a minor implementation detail.

Identity lifecycle activity is the real detection surface for Account Operators abuse. Password resets, account creation, group changes, SPN edits, and computer object creation are not isolated events when they come from this role. They are indicators of an actor rewriting the identity plane. The right governance model is to watch the sequence, not the single event.

Delegated Active Directory administration fails when the delegation boundary is broader than the operational need. Account Operators demonstrates how a support role can become a lateral movement bridge if its write scope is not tightly bounded. The implication is that lifecycle governance must be object-specific, not group-name-specific.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most identity programmes still cannot see the full control surface they are trying to govern.
• For a lifecycle lens on the same problem, NHI Lifecycle Management Guide is the next resource to review.

What this signals

Account Operators is a reminder that identity risk often hides in delegated control, not in obvious admin labels. The governance problem is not whether a role sounds privileged enough. It is whether the role can rewrite authentication, membership, and delegation state faster than the review process can notice.

Delegation blast radius: when a role can reset passwords, create identities, and modify directory attributes, the blast radius is defined by the objects it can touch rather than the title attached to the group. That is why object-scoped delegation and protected review paths matter more than naming conventions.

Teams that manage AD security should align this with the NIST Cybersecurity Framework 2.0 and the NIST SP 800-53 Rev 5 Security and Privacy Controls for access control, auditability, and least privilege.

For practitioners

• Empty the Account Operators group Remove membership wherever possible and keep it empty unless a documented operational need exists. If delegation is required, replace broad membership with tailored OU-scoped permissions that match the actual admin task.
• Tighten computer account creation rights Reduce MachineAccountQuota to zero where appropriate and restrict which identities can create new computer accounts. This closes off a common path to delegation abuse and machine account pivoting.
• Monitor identity lifecycle events as an abuse chain Correlate account creation, password reset, SPN modification, group membership changes, and AdminSDHolder ACL changes for members of this group. Treat rapid add-and-remove patterns as high-signal abuse, not noise.
• Block interactive use on critical systems Deny interactive logon to domain controllers and critical servers for any remaining delegated admin identities. The goal is to reduce the chance that a compromised operator account can immediately pivot into privileged execution.

Key takeaways

• Account Operators is dangerous because it can alter identity state across the domain, which is enough to build escalation paths without obvious admin membership.
• The most important evidence of risk is operational, not theoretical: password resets, SPN edits, group changes, and computer object abuse are all realistic follow-on actions.
• Removing the group, narrowing delegation, and monitoring lifecycle events are the controls that most directly reduce the role's abuse potential.

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.
• SDProp: The Security Descriptor Propagator process in Active Directory that reapplies the AdminSDHolder security descriptor to protected objects. It closes permission drift on a schedule, which creates a practical delay between a risky change and the re-stamped protected state.
• Delegated administration: Delegated administration allows local operators to make approved configuration changes without waiting on a central platform team. It improves speed, but it only remains safe when permissions are narrow, changes are logged, and validation prevents policy drift.

What's in the full article

Semperis's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Active Directory event IDs for detecting Account Operators abuse across account creation, resets, and group changes
• Examples of short-window SDProp timing issues and how protected-object drift can appear during investigations
• Specific monitoring focus areas for SPN changes, AdminSDHolder ACL changes, and computer object abuse paths
• Recommended delegation and tiering changes for organisations that cannot remove the group immediately

👉 Semperis's full post covers the detection events, SDProp nuance, and hardening steps in more operational detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.