Designing OUs for delegated administration without creating attack paths

OUs serve administration, not the org chart

An organizational unit has two technical purposes: carrying delegated permissions and receiving Group Policy links. The org chart, on the other hand, changes with every reorganisation and is better reflected in user attributes (department, division) or in groups. A good structure therefore answers the question "who administers what, and with which policies?", not "who works where?".

In practice, you often find a first level by object type or administration tier, then a geographical or business split only where different admin teams justify it.

Separate tiers from the root

Tier 0 objects (domain admin accounts, privileged groups, AD CS, AD FS and Entra Connect servers, Tier 0 admin workstations) should live in a dedicated branch where no lower-tier delegation applies. If domain admin accounts sit in the same OU as regular users, the helpdesk that can reset passwords in that OU can, in theory, take over a privileged account. The same reasoning applies to Tiers 1 and 2: servers and their administrators do not share space with workstations.

Delegate to groups, never to people

Every delegation should be granted to a role group (for instance "Password Reset - HQ Users"), never to a named account. People change jobs; groups remain. An explicitly named group makes the delegation readable in ACLs and lets you review membership without touching permissions. Domain local groups work well as permission holders.

Delegate as narrowly as possible: resetting a password and unlocking an account do not require full control over user objects. The Delegation of Control Wizard offers common tasks, but it is better to define documented delegation models and apply them consistently.

Keep inheritance under control

Permissions set on an OU apply to all its descendants by default. A delegation granted on a top-level OU "to keep things simple" flows down to every child OU, including those created later. Several points deserve attention:

• moving an object from one OU to another changes its effective permissions: it is an operation to control, and the right to move objects is itself sensitive;
• members of protected groups are subject to the AdminSDHolder mechanism, which periodically overwrites their ACLs and disables inheritance; former members often keep that protection for no reason;
• an object's owner holds implicit rights: objects created by a helpdesk account remain its property, which opens unexpected paths;
• blocking Group Policy inheritance has nothing to do with permission inheritance: they are two separate mechanisms.

Document and review

An undocumented delegation becomes invisible after a few years. Keep a register linking each delegation to a group, an OU, specific rights, an owner and a review date. Compare it regularly with the actual ACLs, for example with dsacls or the PowerShell cmdlets that read ACLs, and remove orphaned entries (unresolved SIDs) or entries granted to named accounts. Also consider the default CN=Users and CN=Computers containers, which are not OUs: redirect the creation of new objects to managed OUs.

What an audit checks

• Tier 0 objects isolated in a branch with no lower-tier delegation;
• ACLs granted to named accounts or to orphaned SIDs;
• full control or generic write delegations on entire OUs;
• objects with adminCount=1 that are no longer members of protected groups;
• the existence and currency of a delegation register.