Notifications
Clear all
Topic starter
02/09/2026 1:29 pm
TL;DR: Account Operators in Active Directory can create and modify users, groups, and computers, reset passwords, edit SPNs, and shape delegated access paths, according to Semperis. That makes the group a privilege amplifier across identity lifecycle controls, and defenders should treat it as pre-privileged access rather than a routine support role.
NHIMG editorial — based on content published by Semperis: Account Operators abuse paths, detection, and mitigation in Active Directory
Questions worth separating out
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.
Q: Why can AdminSDHolder still leave a short exposure window for defenders?
A: Because protection is enforced by SDProp on a cycle, not continuously.
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.
Practitioner guidance
- Empty the Account Operators group Remove membership wherever possible and keep it empty unless a documented operational need exists.
- Tighten computer account creation rights Reduce MachineAccountQuota to zero where appropriate and restrict which identities can create new computer accounts.
- 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.
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
👉 Read Semperis's analysis of Account Operators abuse in Active Directory →
Account Operators in Active Directory: what makes this group dangerous?
Explore further
02/09/2026 1:30 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Account Operators is pre-privileged access, not a harmless AD role
