Active Directory Delegation: Design OU permissions without creating shadow admins

Most Active Directory shadow admins were never meant to be admins: they are the residue of delegation done one ticket at a time, with no model behind it. A help desk group given Full Control on the domain root to reset passwords, a provisioning service account with rights on every OU, or a workstation build team that can write to any computer object will each, sooner or later, sit on an attack path to Domain Admins. This guide is about designing delegation properly from the start: a role catalogue, an OU structure built for delegation, task-scoped permissions with controlled inheritance, a help desk model that cannot reach privileged accounts, and a delegation register that keeps the model honest. It is written for Active Directory architects and identity engineers. Cleaning up rights that already exist is covered in the Active Directory ACL and Delegation Hygiene Guide; this page focuses on the target design.

Key takeaways

• Delegate to groups, on OUs, for tasks. Microsoft's model is three steps: put the people in a security group, put the objects in an OU, delegate the task on that OU to the group. Every design decision builds on that.
• The OU tree is the permission boundary. Design OUs around who administers what, not around the organisation chart, or delegation will never be clean.
• Scope inheritance to the object class. A password reset right should apply to descendant user objects only, never to "This object and all descendant objects".
• Privileged objects sit outside delegation. Protected accounts and groups are reset to the AdminSDHolder template every 60 minutes by default, and Tier 0 objects belong in OUs only Tier 0 administrators control.
• A delegation you cannot explain is a shadow admin. Keep a register mapping every non-default access control entry to a role, owner and approval.

Why delegation design creates or prevents shadow admins

A shadow admin is an account or group that can reach domain control without being a member of Domain Admins, Enterprise Admins or Administrators. In delegation terms, that happens when a right granted for one task also allows a more powerful one: resetting a password of a user who is an administrator, writing group membership on a privileged group, linking a Group Policy Object to an OU containing servers, or changing the permissions of an OU itself. MITRE ATT&CK catalogues the resulting abuse as T1222.001 Windows Permissions (File and Directory Permissions Modification), T1098 Account Manipulation and T1484.001 Group Policy Modification.

Microsoft distinguishes broad privilege (rights across many objects, such as a help desk resetting passwords for thousands of users) from deep privilege (powerful rights over a narrow scope, such as administrator rights on one server). Good delegation design keeps broad roles shallow and deep roles narrow. The failure mode is a role that is both broad and deep.

Two implicit behaviours make this matter more than it seems:

• Creators get control: Microsoft notes that creating an object in an OU implicitly grants the creator the ability to manipulate any attribute of that object, and creating a container lets the creator create and manipulate objects inside it. A delegated "create computer objects" right therefore also yields broad control over the computers created.
• Owners get implicit rights: the object owner holds implicit READ_CONTROL and WRITE_DAC, so it can rewrite the object's permissions. The well-known OWNER RIGHTS principal (S-1-3-4) lets you suppress those implicit rights where ownership by a delegated group is unavoidable.

Building a role catalogue

Microsoft recommends implementing roles as AD DS security groups and, for each role, defining day-to-day versus infrequent tasks, the systems where the role applies, who the members are and how membership is managed. Write the catalogue before touching any ACL.

Practical rules for the catalogue:

• One task, one group: keep task groups separate even when the same team holds several. A team is a member of several role groups; it is not itself the delegated principal.
• Use an access group model: grant rights to domain local groups and put role (global) groups into them, so the ACL never changes when the team changes.
• Name for intent: a name such as ROLE-HD-PwdReset-Staff makes an unexpected ACE obvious during review.
• Account for service accounts: Microsoft warns that if a product relies on placing its service accounts in highly privileged groups, the attack surface has only been shifted. Give provisioning and synchronisation accounts their own role groups, scoped like any human role. See the Group Managed Service Accounts (gMSA) Guide.

Designing the OU structure for delegation

Microsoft advises that service administrators keep control of the default containers and OUs created at installation, and that you create new OUs, move objects into them and delegate those. Default containers such as CN=Users and CN=Computers cannot have Group Policy linked and are poor delegation boundaries, so redirect new objects into managed OUs.

A structure that delegates cleanly usually has:

1. A Tier 0 branch: privileged accounts, privileged groups, Tier 0 servers (AD CS, synchronisation, federation) and their service accounts, administered only by Tier 0 administrators. Microsoft's enterprise access model calls this the control plane. See the Tiered Administration and Enterprise Access Model Guide.
2. Separate branches by object type and administrator: users, groups, workstations, servers and service accounts in different OUs, because the teams that manage them differ.
3. Location or business unit below object type, only where administration differs: regional help desks need regional OUs; a single central help desk does not.
4. A staging OU: for newly joined computers, with restrictive GPOs, from which a build process moves them on.
5. A shallow depth: three or four levels keep inheritance understandable. Every extra level is another place an inheritable ACE can hide.

Decision guidance: in a single domain run by a small team, a flat structure with two or three role groups and no regional split is safer than a granular model nobody maintains. In large estates, multi-region help desks, outsourced desktop support and automated provisioning need the full role catalogue, OU separation and automation that applies the ACEs from code.

Setting permissions: scope, inheritance and tools

The Delegation of Control Wizard in Active Directory Users and Computers offers common tasks (for example resetting user passwords and forcing a change at next logon, creating and managing user accounts, modifying group membership, and managing Group Policy links) and a custom task option. It is convenient but only adds entries: Microsoft notes you cannot use the wizard to review delegated access afterwards (that is done in Advanced Security Settings), so it cannot be your record of what is delegated.

Apply ACEs from scripts held in version control rather than by hand, so the intended state can be reapplied and compared. Read-only tools such as dsacls or PowerShell Get-Acl on AD: paths let you diff live permissions against the register.

Protected objects and AdminSDHolder

Members of protected groups, including Account Operators, Administrators, Backup Operators, Domain Admins, Enterprise Admins, Print Operators, Schema Admins and Server Operators, take their permissions from the AdminSDHolder object (CN=AdminSDHolder,CN=System,DC=...). The SDProp process on the PDC emulator compares them every 60 minutes by default and resets any difference, and protected objects have inheritance disabled. Two consequences for design:

• Delegations do not stick on privileged users: any OU delegation that reaches a protected account is overwritten. That is a feature: do not work around it by adding ACEs to AdminSDHolder, which would apply them to every protected object.
• Privileged accounts in a delegated OU are a smell: even though SDProp protects them, put them in the Tier 0 branch so nothing in the delegation model needs to reason about them.

Built-in operator groups are not a delegation model

Microsoft's descriptions show why. Account Operators can create, modify and delete users, groups and computers in all containers and OUs except the Builtin container and Domain Controllers OU, and can sign in locally to domain controllers; Microsoft's group reference marks management of the group as not safe to delegate to non-service admins. Server Operators can administer domain controllers, Backup Operators can override security restrictions to back up and restore files, and Print Operators can load and unload device drivers on domain controllers. Keep these groups empty and replace their use with scoped role groups.

Help desk delegation

Microsoft's help desk example combines delegation on user objects for password resets with rights to connect remotely to users' computers. Design it as two or three separate roles:

• Password and unlock role: Reset Password plus write lockoutTime and pwdLastSet, scoped to descendant user objects in standard user OUs only. Service accounts, administrators and executives sit in other OUs.
• Workstation support role: local administration through Windows LAPS read permission on workstation OUs, never through membership of a domain group that is local administrator everywhere. Find-LapsADExtendedRights shows who can read confidential LAPS attributes on an OU. See the Local Administrator Password Solution (LAPS) Guide.
• Group membership role: write member on named application groups only.

Pair the technical scope with identity verification before any reset, because a perfectly scoped reset right still hands over an account if the caller is an impostor. See the Account Recovery and Help Desk Security Guide and the Help Desk Identity Verification Policy Template.

Documentation and the delegation register

The register is what turns delegation from a set of ACEs into a model. For each delegation record:

• Role group and member source: which team or process populates it and who approves membership.
• Target: OU distinguished name, object class, rights or properties, and inheritance setting.
• Business owner and technical owner: named people, reviewed at least annually.
• Approval and change reference: the ticket or design decision that created it.
• Review date: when it was last confirmed as still needed.

Generate a list of non-default ACEs on each OU periodically and compare it with the register. Anything not in the register is either undocumented or unauthorised; both need action. The Active Directory ACL and Delegation Hygiene Guide covers reviewing and removing those entries; attack path tools covered in the BloodHound and Active Directory Attack Path Guide show whether any delegated group still reaches Tier 0.

Rolling out a new delegation model

1. Baseline: export current OU ACLs and run an attack path assessment so you know which groups reach Tier 0 today.
2. Design: write the role catalogue, OU structure and register. Have a second Tier 0 administrator review it.
3. Build in a lab: create OUs and apply ACEs from scripts; test each role with a test account, including negative tests (the help desk test account must fail to reset an administrator or service account password).
4. Pilot: move one region or business unit into the new OUs, add the new role groups, and leave the old rights in place for a short overlap.
5. Cut over: remove the old broad rights for the pilot scope, monitor tickets and failures for two weeks, then extend.
6. Roll back: keep the exported ACLs and the scripts that removed them, so the previous state can be restored per OU if a critical process breaks.
7. Lock in: set ms-DS-MachineAccountQuota to 0 once the join role works, since Microsoft notes users with delegated create rights are not limited by the quota, and the default of 10 lets any user add computers.

Detection and measurement

Enable Audit Directory Service Changes and add SACLs on the Tier 0 branch and on the OUs you delegate. Event ID 5136 records a directory object modification when the object's SACL audits writes to that attribute, so include nTSecurityDescriptor (permission changes) and gPLink in those SACLs. Group membership changes appear as 4728, 4732 and 4756. Alert on any permission change outside a change window and on membership changes to role groups. See the Active Directory Security Monitoring and Event IDs Guide.

Metrics that show the model is working:

1. Percentage of non-default OU ACEs that map to a register entry (target 100%).
2. Number of delegated groups with a path to Tier 0 in attack path analysis (target zero).
3. Number of ACEs granted to individual users rather than groups (target zero).
4. Members of Account Operators, Server Operators, Print Operators and Backup Operators (target zero outside documented exceptions).
5. Delegations past their review date.

Framework mapping

Common failure patterns

• Delegating at the domain root: a right meant for staff users also applies to service accounts, administrators and every future OU.
• Using Full Control as a shortcut: it includes changing permissions and taking ownership, so the delegated group can grant itself anything in scope.
• Service accounts in standard user OUs: the help desk can reset the password of a sync or backup account that holds powerful rights.
• Delegating to individuals: rights granted to a person survive their move or departure and never appear in group reviews.
• Treating the wizard as the record: without a register, nobody knows which ACEs are intended, so cleanup stalls.
• GPO rights without OU limits: edit rights on a GPO linked to server OUs give code execution on those servers. See the Group Policy Security Guide.

Practitioner checklist

• Write a role catalogue with tasks, scope, members and membership owner for every delegated role.
• Create a Tier 0 OU branch administered only by Tier 0 administrators and move privileged accounts and servers into it.
• Separate users, groups, workstations, servers and service accounts into different OUs.
• Grant rights only to role groups, scoped to a specific object class and the narrowest property or extended right.
• Split help desk rights into password reset, LAPS read and group membership roles, none reaching privileged or service accounts.
• Keep Account Operators, Server Operators, Print Operators and Backup Operators empty.
• Set ms-DS-MachineAccountQuota to 0 and delegate computer creation on a staging OU.
• Apply ACEs from version-controlled scripts and keep a delegation register reconciled with live ACLs.
• Audit permission changes with event ID 5136 and review the register at least annually.

Standards and references

• Microsoft Learn: Delegating administration by using OU objects
• Microsoft Learn: Implementing least privilege administrative models
• Microsoft Learn: Protected accounts and groups in Active Directory
• Microsoft Learn: Privileged accounts and groups in Active Directory
• Microsoft Learn: Active Directory security groups
• Microsoft Learn: Windows LAPS with Windows Server Active Directory
• Microsoft Learn: Default limit to number of workstations a user can join to the domain
• Microsoft Learn: Enterprise access model

Related NHI Mgmt Group resources: Active Directory ACL and Delegation Hygiene Guide · Tiered Administration and Enterprise Access Model Guide · BloodHound and Active Directory Attack Path Guide · Active Directory Security Checklist