How to Create Active Directory Organizational Units

Create and structure Active Directory organizational units, delegate administration, apply Group Policy, and avoid treating OUs as security boundaries.

Type
Tutorial
Level
Intermediate
Technologies
Active Directory
On this page

What is an Organizational Unit in Active Directory?

An Organizational Unit (OU) is a core container object in Active Directory (AD) designed to logically group users, computers, groups, and other OUs within a domain. OUs provide the backbone for organizing directory resources, enabling delegation of administrative tasks and application of Group Policy Objects (GPOs) in a controlled, hierarchical structure.

While groups in AD are used for assigning resource permissions, OUs are strictly for administrative organization and management. OUs allow granular administration—meaning tasks like user account management, computer policy configuration, and password resets can be delegated to appropriate administrators or teams without granting excessive rights over the entire domain.

OUs are distinct from default containers such as "Users" or "Computers." Only OUs allow for direct application of GPOs and assignment of custom delegation. This makes them essential for structuring secure, easily managed, and policy-enforced Active Directory environments.

Step-by-Step: Creating Organizational Units (GUI and PowerShell)

Creating OUs with Active Directory Users and Computers (ADUC)

  1. Open ADUC: Start 'Active Directory Users and Computers' with an account that has rights to create OUs.
  2. Navigate to the Desired Location: In the left-hand pane, right-click the domain or the parent OU where you want the new OU to reside.
  3. Select "New" → "Organizational Unit": This opens the new OU dialog.
  4. Name the OU: Provide a clear, descriptive name. AD does not allow duplicate OU names at the same hierarchical level.
  5. Enable 'Protect container from accidental deletion': Ensure this option is checked. It prevents administrators from inadvertently deleting the OU and all its contents.
  6. Finish Creation: Click 'OK' to create the OU. The new OU now appears in the selected location.

Creating OUs with PowerShell

For automation or bulk scenarios, PowerShell simplifies OU deployment using the New-ADOrganizationalUnit cmdlet:

powershell
New-ADOrganizationalUnit -Name "Finance" -Path "DC=example,DC=com" -ProtectedFromAccidentalDeletion $true -Description "Finance department OU"
  • -Name: The OU's name.
  • -Path: Distinguished Name (DN) of the parent OU or domain.
  • -ProtectedFromAccidentalDeletion: Sets the recommended protection flag.
  • -Description: Optional administrative description for documentation.

Bulk creation is achieved by scripting multiple calls to this cmdlet with different parameters.

OUs vs. Groups and Default Containers

OUs vs. Groups

  • OUs exist to define the logical and administrative structure of AD. They form the hierarchy, allow for delegation, and provide the boundary for GPO application.
  • Groups (security or distribution) are used to collect users or computers for permission assignment to resources such as file shares, printers, or applications.
  • Distinct Function: While OUs organize and delegate, groups authorize and grant access. OUs cannot be added to access control lists (ACLs), and groups cannot be linked to GPOs or delegated administrative control in the same way.

OUs vs. Default Containers

  • The built-in containers "Users" and "Computers" are not OUs. Default containers:
    • Cannot have GPOs linked directly to them.
    • Do not support custom delegation of administrative rights.
    • Should be avoided for production use; move objects to custom OUs for policy and delegation needs.

Common Misuse

  • Placing objects only in default containers undermines manageability—objects there cannot be governed by GPOs or finely delegated. A sustainable AD design always utilizes custom OUs for administrative targets and policy application.

Delegating Administration with OUs

Why Delegate Using OUs?

Delegation enables the assignment of specific administrative tasks—such as resetting user passwords, managing computer objects, or modifying group membership—to non-domain-admin users, limited to the scope of a particular OU.

This is essential for:

  • Managing large or distributed organizations.
  • Enforcing least-privilege administration.
  • Supporting tiered operational models (e.g., helpdesk staff vs. server admins).

How to Delegate Control

  1. Right-click the Target OU in ADUC: Select 'Delegate Control' to launch the Delegation of Control Wizard.
  2. Select Users or Groups: Designate the accounts to which you wish to delegate control.
  3. Choose Tasks: Select from predefined common tasks (like 'Reset user passwords and force password change at next logon') or create custom permissions.
  4. Finish Delegation: The wizard applies the delegated permissions as defined.

Delegation Boundaries and Limitations

  • Only permissions for objects within the delegated OU are affected—delegates cannot manage objects outside this scope.
  • Delegation cannot prevent forest- or domain-level administrators from accessing or controlling all OUs.
  • Proper delegation design requires the OU to contain only the objects that the delegate should control.

Best Practices for OU Structure and Management

Structure for Delegation and Policy

  • Separate users, computers, and service accounts: Create top-level OUs such as "Users," "Computers," and "Service Accounts" to align with unique policies and delegation needs.
  • Design for administrative boundaries: Structure OUs so each contains objects managed by the same role or team.
  • Support Group Policy: Place objects requiring similar policy configurations together.
  • Limit nesting: Deep hierarchies are difficult to manage and troubleshoot. Keep structures as flat as possible while reflecting necessary administrative divisions.
  • Do not mirror the org chart: Avoid letting short-term business structures dictate OU layout; organizational units should support administration, not bureaucratic reporting lines.
  • Protect OUs from accidental deletion: Always enable this for each OU.
  • Document purpose and ownership: Use descriptions and maintain separate documentation to clarify each OU's function and delegated responsibilities.

Example Structure

  • OU=Users
  • OU=Workstations (or Computers)
  • OU=Servers
  • OU=ServiceAccounts
  • OU=Admins

Further child OUs may reflect business units or locations as needed, but always with an eye toward simplicity and clear delegation.

Common Mistakes and Misconceptions

  • Using default containers: GPOs and delegation cannot be applied—migrate objects to OUs for management.
  • Treating OUs and groups as interchangeable: Only OUs can be used for delegation and policy linking; only groups can assign resource access.
  • Mimicking company org chart: Leads to excessive, fragile complexity. Instead, design for delegation boundaries and policy application.
  • Excessive OU nesting: Causes confusion, increases troubleshooting time, and complicates delegation.
  • Neglecting accidental deletion protection: OUs deleted by mistake can cause major disruptions; always enable this setting.
  • Assuming delegation is absolute: Delegates are restricted to the OU, but domain admins or higher can always override.

References and Further Reading

  • Microsoft Docs: Create an Organizational Unit (OU) in a Microsoft Entra Domain Services managed domain
  • New-ADOrganizationalUnit (Active Directory) PowerShell documentation
  • Delegating Administration by Using OU Objects
  • Creating an Organizational Unit Design
  • New-ADGroup (ActiveDirectory) distinction reference
  • Delegation of Control in AD DS on Windows Server

Sources

Related resources