Delegating OU permissions with minimal risk: the expert’s comparison guide

Why OU delegation matters now

Modern AD estates are bigger, more hybrid, and more frequently touched by non-admins than ever. Help desks need to reset passwords; joiners–movers–leavers (JML) processes need to create, disable, and move accounts; app teams must manage service identities. If you solve all of that with broad groups like Account Operators or (worse) Domain Admins, you raise your blast radius and make incident response harder.

Delegation is the antidote: grant the smallest necessary set of rights, aimed at the smallest necessary scope, and do it to groups—not people. Microsoft recommends designing your OU structure to enable delegation and to avoid modifying default containers like Users or Computers; create new OUs and delegate those instead. See: Microsoft Learn — Delegating administration by using OU objects.

Done well, delegation shortens queue times, reduces standing privilege, and keeps Tier-0 untouched. Done poorly, it creates invisible power pockets, inheritance surprises, and AdminSDHolder headaches.

The common view—and why it’s incomplete

Most teams think delegation = “right-click OU → Delegate Control… → pick a task.” That wizard is a fine starting point. It wraps common, pre-canned ACEs and applies them to the OU scope. But wizard-only delegation misses three realities:

• Scope isn’t just hierarchy. Inheritance interacts with protected objects (AdminSDHolder), blocked inheritance on child OUs, and object-specific ACEs. Your “simple” delegation may not reach some objects—or may reach more than intended.
• Tasks are composite. “Reset passwords” also requires “read user properties” and “write pwdLastSet,” and “unlock account” touches lockoutTime. The wizard hides that complexity, which is good—until it isn’t.
• Verification is not optional. You must check the Security tab (with Advanced Features enabled in ADUC) and/or read ACLs programmatically to confirm the resulting ACEs say what you think they say.

How safe delegation really works

• Least privilege is scope × task. Risk equals what you can do times where you can do it. Reduce either factor and you reduce blast radius. Design OUs for delegation (separate account OUs from resource OUs; isolate servers from workstations; segregate service accounts).
• Groups, never individuals. Humans change roles; groups represent roles. Delegate to a group, manage membership via JML controls, and audit group changes as the change surface.
• Inheritance drives reach. ACEs on a parent OU propagate to children unless inheritance is blocked or the ACE applies to specific object classes. Protected groups and their members ignore your OU permissions due to AdminSDHolder.
• Tiering contains damage. A tiered model (e.g., Tier-0 DCs & identity services; Tier-1 servers; Tier-2 workstations) plus OU-scoped delegation prevents workstation rights from touching server OUs and neither from touching Tier-0.

Comparison: wizard-only vs ACL-aware vs tiered delegation by design

1) Wizard-only (quick wins, hidden edges)

Pros: Fast, standardized tasks, low cognitive load, ideal for common help-desk scenarios.

Cons: Less transparency; difficult to reason about composite rights; easy to over-scope if you run it at a high OU; brittle if your OU tree is messy or inheritance is blocked. AdminSDHolder will silently nullify parts of your plan for protected users.

2) ACL-aware (explicit ACEs, programmatic checks)

Pros: Precise, reviewable, scriptable (e.g., dsacls or PowerShell). Works well for audit and repeatability; you can diff permissions, export ACLs, and reapply during DR.

Cons: Steeper learning curve; easy to misconfigure object-specific ACEs if you guess at GUIDs; understanding inheritance flags matters.

3) Tiered delegation by design (prevent, don’t detect)

Pros: Minimizes cross-tier reach by OU and admin workstation hygiene; even a compromised Tier-2 admin account can’t touch Tier-1 or Tier-0. Recommended by identity security leaders.

Cons: Requires organizational discipline; you must pair OU structure with workstation tiering, identity isolation, and PAM.

The step-by-step blueprint you can copy (hero section)

0) Prerequisites

• Create a role group (e.g., GG_Helpdesk_PasswordReset_Move) in a Groups OU.
• Example OU tree:
  • OU=Corp,DC=example,DC=com
  • OU=Users,OU=Corp → OU=HR, OU=Finance, …
  • OU=Workstations,OU=Corp → OU=Onboarding, OU=InService
• Do not delegate in default containers (Users, Computers).

1) Delegate password reset & unlock — wizard method (scoped)

1. In ADUC, enable View → Advanced Features.
2. Right-click OU=HR,OU=Users,OU=Corp,... → Delegate Control.
3. Add GG_Helpdesk_PasswordReset_Move.
4. Select Reset user passwords and force password change at next logon.
5. Finish, then verify in HR OU → Properties → Security → Advanced that the group has the Extended Right: Reset Password and write on pwdLastSet.

Why only HR? Limit the task to one department’s OU to respect least privilege. If support needs broader coverage, create additional role groups per scope, not one mega-group.

2) Delegate moving computer objects between two OUs — ACL method (precise)

The wizard lacks a turnkey “move” task. Moving requires Create Child in the destination and Delete Child in the source for the computer class. Use dsacls from an elevated prompt:

:: Grant create/delete computer objects within Onboarding and InService
dsacls "OU=Onboarding,OU=Workstations,OU=Corp,DC=example,DC=com" /I:S /G "DOMAIN\GG_Helpdesk_PasswordReset_Move:CC;computer"
dsacls "OU=InService,OU=Workstations,OU=Corp,DC=example,DC=com"   /I:S /G "DOMAIN\GG_Helpdesk_PasswordReset_Move:CC;computer"

dsacls "OU=Onboarding,OU=Workstations,OU=Corp,DC=example,DC=com" /I:S /G "DOMAIN\GG_Helpdesk_PasswordReset_Move:DC;computer"
dsacls "OU=InService,OU=Workstations,OU=Corp,DC=example,DC=com"   /I:S /G "DOMAIN\GG_Helpdesk_PasswordReset_Move:DC;computer"

CC = Create Child, DC = Delete Child, and ;computer scopes to the computer object class. /I:S enables inheritance where applicable. Verify via ADUC Advanced Security.

3) Block risky edges

• No Full Control and no Write DACL: Ensure the role group does not have WRITE_DAC or WRITE_OWNER. These allow ACL manipulation and privilege escalation. Avoid Full Control grants, especially where CREATOR OWNER can inherit extra power.
• AdminSDHolder reality check: Members of protected groups (and their members) will ignore OU-scoped delegation. If help desk can’t reset a VIP user, check AdminSDHolder. Don’t weaken it; fix group memberships and process.

4) Programmatic verification (PowerShell)

Import-Module ActiveDirectory

# Get the OU's ACL via ADSI and list ACEs for your role group
$ou = "OU=HR,OU=Users,OU=Corp,DC=example,DC=com"
$de = [ADSI]"LDAP://$ou"
$acl = $de.ObjectSecurity.Access

$acl |
  Where-Object { $_.IdentityReference -like "*GG_Helpdesk_PasswordReset_Move" } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType, InheritanceType, InheritedObjectType |
  Format-Table -Auto

Confirm you see ExtendedRight for user password reset and write on pwdLastSet. Repeat for computer OUs to confirm CreateChild/DeleteChild for the computer class. (Map GUIDs to friendly names via the AD schema if needed.)

5) Audit and rollback posture

# Quick ACL export for drift detection
$ous = @(
  "OU=HR,OU=Users,OU=Corp,DC=example,DC=com",
  "OU=Onboarding,OU=Workstations,OU=Corp,DC=example,DC=com",
  "OU=InService,OU=Workstations,OU=Corp,DC=example,DC=com"
)

$report = foreach ($dn in $ous) {
  $acl = ([ADSI]"LDAP://$dn").ObjectSecurity.Access
  foreach ($ace in $acl) {
    [pscustomobject]@{
      OU                 = $dn
      Identity           = $ace.IdentityReference
      Rights             = $ace.ActiveDirectoryRights
      ObjectType         = $ace.ObjectType
      Inheritance        = $ace.InheritanceType
      InheritedObject    = $ace.InheritedObjectType
      IsInherited        = $ace.IsInherited
    }
  }
}
$report | Export-Csv "C:\Temp\ou-acl-baseline.csv" -NoTypeInformation

Detect drift by diffing current ACL exports with your baseline (e.g., in CI or a scheduled task). Rollback by reapplying the version-controlled dsacls commands.

6) Document the intent

• Group description: “Help desk can reset passwords & unlock users in HR OU; move computers between Onboarding and InService.”
• OU description: “Delegation: HR help desk has Reset Password and pwdLastSet write; no write-DACL rights.”

Inherent tendencies you must account for

• The wizard optimizes for convenience, not composability. It’s great for a few tasks but opaque at scale. Use dsacls + scripts for clarity.
• Protected objects break mental models. AdminSDHolder resets ACLs hourly on protected accounts and disables inheritance. This is by design to protect Tier-0.
• Inheritance surprises cut both ways. You might think rights don’t flow (because a child OU blocked inheritance) or do flow (but an ACE was scoped to users only). Always check Applies to and Inherited from in Advanced Security.
• Tier violations are silent debt. Shortcuts like granting workstation admins server OU rights collapse your tiers and expand blast radius.

Mental models that make delegation click

• Scope lattice: Delegation is a coordinate of where (OU subtree) and what (task/extended rights). Never grant either axis broadly.
• Contract not capability: The ACL is a contract between owners and operators. Make intent explicit (names, descriptions, scripted ACEs) to simplify audits.
• Tier gates: Picture one-way gates between Tier-2 → Tier-1 → Tier-0. OU design and ACLs must respect those gates.
• Drift budget: Assume drift. Define a budget (e.g., max 5 non-standard ACEs per OU) and alert when exceeded.

Subtle mistakes we keep seeing (and how to correct them)

• Delegating at too high an OU. Teams run the wizard at OU=Users and accidentally include service accounts. Fix: Delegate at the smallest OU that satisfies the request (e.g., department OU) and replicate as needed.
• Using Full Control to “just make it work.” This grants WRITE_DAC/WRITE_OWNER and enables escalation. Fix: Use precise extended rights or dsacls with object-class scoping; deny write-DACL if necessary.
• Ignoring AdminSDHolder behavior. Help desk can’t reset VIP passwords, so someone proposes weakening AdminSDHolder. Fix: Don’t. Review privileged group membership; use privileged workflows (PAM/break-glass) for protected users.
• Delegating to individuals. People move; permissions don’t. Fix: Delegate to role groups and wire membership to JML automation.
• No verification loop. Teams never open the Security tab or export ACLs; later, nobody remembers why an ACE exists. Fix: Verify after every change; baseline and diff weekly.

Expert essentials checklist

• Delegate to groups only.
• Scope to the smallest OU that works.
• Prefer extended rights and object-class filters over Full Control.
• Verify with ADUC Advanced Security and PowerShell exports.
• Respect AdminSDHolder; don’t weaken Tier-0.
• Document intent; baseline ACLs and watch for drift.

Applications, consequences, and what’s next

Hybrid realities: In Entra ID hybrid, on-prem OU delegation underpins JML processes that sync to cloud. A clean OU model simplifies scoping of Entra Connect OU filters and downstream automation.

Service account regimes: Consider separate OUs for service accounts with distinct delegation for password management and SPN writes. Pair with monitoring for SPN changes.

Automated guardrails: At scale, delegation visualization and policy enforcement tools can help keep humans honest. If you must delegate across many domains, tooling reduces drift.

Forum-hardened patterns: Be cautious with OU creation rights. Granting the ability to create OUs can enable ACL tampering on those new OUs unless you constrain rights like WRITE_DAC.

Key takeaways & wrap-up

• Delegation is a design discipline, not a wizard click.
• Risk lives in scope × task. Shrink both.
• AdminSDHolder protects Tier-0; don’t fight it.
• Treat ACLs as code: script, baseline, diff, document.
• Verify relentlessly: Security tab + exported ACEs.

Call to action: Want a ready-to-use OU delegation starter pack (scripts, checklists, ACL baseline template)? Subscribe to our WAD newsletter to receive a downloadable bundle you can adapt to your environment.

Sources & further reading

• Microsoft Learn — Delegating administration by using OU objects
• Microsoft Learn — Delegating administration of account vs resource OUs