Organizational Units (OUs)
An Organizational Unit (OU) is a container object within a domain used to organize users, groups, computers, and even other OUs into a logical hierarchy that mirrors an organization's structure — by department, location, or function. Unlike the built-in containers AD creates automatically (like CN=Users or CN=Computers), OUs are the only containers that can have Group Policy Objects (GPOs) linked to them and administrative control delegated over them, which makes OU design one of the most consequential decisions in an AD deployment.
Cricket analogy: Similar to how a national cricket board organizes players into state teams and age-group squads — the grouping isn't just cosmetic, it determines which coach, which selection committee, and which training regimen applies to each group.
OUs vs Other Containers: Why Structure Matters
The default containers AD creates during promotion — CN=Users, CN=Computers, CN=Builtin — are technically container objects, not OUs, and critically, you cannot link a GPO to them or use the Delegation of Control Wizard on them the way you can with an OU. This is why best practice is to move newly created user and computer accounts out of those default containers and into a purpose-built OU structure almost immediately, since leaving accounts in CN=Users means they can never receive OU-scoped Group Policy.
Cricket analogy: Similar to how a player who hasn't yet been assigned to a specific state team sits in a general pool — they can't receive that state's specific training regimen or selection benefits until they're formally assigned into the team structure.
Delegating Administration at the OU Level
The Delegation of Control Wizard lets a domain admin grant specific, narrowly scoped permissions on an OU — such as 'reset passwords for users in this OU' or 'create and delete computer objects in this OU' — to a non-admin group, without granting Domain Admins-level rights. This follows the principle of least privilege: a help desk team responsible only for the Sales department can be delegated rights over just the Sales OU, meaning even if their credentials were compromised, the blast radius is contained to that one OU rather than the entire domain.
Cricket analogy: Similar to how a franchise might grant its physiotherapist authority over player fitness decisions specifically, without giving them any say over team selection or batting order — narrowly scoped authority, not full team control.
# Create a new OU with accidental-deletion protection enabled
New-ADOrganizationalUnit -Name "Sales" -Path "DC=contoso,DC=com" -ProtectedFromAccidentalDeletion $true
# Create a nested OU for computer objects within Sales
New-ADOrganizationalUnit -Name "Computers" -Path "OU=Sales,DC=contoso,DC=com"
# Move an existing user into the new OU
Move-ADObject -Identity "CN=Jane Doe,CN=Users,DC=contoso,DC=com" -TargetPath "OU=Sales,DC=contoso,DC=com"By default, New-ADOrganizationalUnit sets ProtectedFromAccidentalDeletion to $true, which places a deny-ACE against delete operations on the OU. This is why you sometimes can't delete an OU from the GUI until you first uncheck 'Protect object from accidental deletion' on its Object tab — it's a deliberate safety net, not a bug.
Designing an OU Structure and Applying Group Policy
GPOs are linked to OUs (also to domains and sites), and by default settings flow downward through nested OUs via inheritance — a GPO linked at the Sales OU applies to every user and computer in Sales plus any child OUs beneath it, unless that inheritance is explicitly blocked. Two common OU design philosophies exist: organizing by business function (Sales, Engineering, Finance) which aligns cleanly with how departments need different GPOs and delegated help desks, versus organizing by geographic location (New York, London, Tokyo) which aligns better when policies differ by site (like regional password complexity rules) rather than by role.
Cricket analogy: Similar to how a board's fitness mandate cascades from the national team down through every state academy beneath it, unless a specific state explicitly opts out with special dispensation for an injured player.
GPO inheritance can be blocked at a child OU with 'Block Inheritance,' and a specific GPO can be forced past a block with 'Enforced' — but overusing both makes policy behavior nearly impossible to reason about. Use gpresult /r or the Group Policy Modeling Wizard to verify actual applied policy on a target object rather than assuming inheritance behaves as designed.
- An OU is a container that organizes AD objects and, unlike default containers, can have GPOs linked and administration delegated to it.
- Default containers like CN=Users and CN=Computers cannot receive GPO links or Delegation of Control Wizard permissions.
- The Delegation of Control Wizard grants narrowly scoped permissions on an OU, following the principle of least privilege.
- New-ADOrganizationalUnit protects OUs from accidental deletion by default via a deny-ACE.
- GPOs linked to a parent OU are inherited by child OUs unless inheritance is explicitly blocked.
- Common OU design patterns organize by business function or by geographic location, chosen based on how policy needs to vary.
- Block Inheritance and Enforced settings should be used sparingly since overuse makes GPO behavior hard to predict.
Practice what you learned
1. What distinguishes an OU from a default container like CN=Users?
2. What does the Delegation of Control Wizard enable?
3. By default, what happens when you create a new OU with New-ADOrganizationalUnit?
4. How does GPO inheritance behave by default across nested OUs?
5. Which of these is a common OU design philosophy?
Was this page helpful?
You May Also Like
Users, Groups, and Computer Objects
The core AD object types — user accounts, security/distribution groups, and computer accounts — and how group scope and type govern permissions.
Installing AD DS and Promoting a Domain Controller
A walkthrough of installing the AD DS server role on Windows Server and promoting it into a new or existing domain controller.
Domains, Trees, and Forests
How Active Directory organizes multiple domains into trees and forests to model organizational and trust boundaries.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics