Category: Directory Services

Organizational Unit

Also known as: OU, OU container

Simply put

An organizational unit (OU) is a container used to group related items, such as user accounts, computers, or cloud accounts, so they can be organized and managed together as a single unit. Grouping items this way makes administration simpler and lets administrators apply consistent management to everything in the container. The exact objects an OU can hold and how it is used depend on the platform.

Formal definition

An organizational unit (OU) is a logical container construct used to organize and delegate administration over grouped objects within a directory or account-management hierarchy. In Microsoft Active Directory, an OU is a container within a domain that can hold objects such as users, groups, and computers, and is commonly used as a scope for delegated administration and, depending on configuration, for policy application. The term is also used outside Active Directory: Microsoft Entra Domain Services supports creating custom OUs within a managed domain, and AWS Organizations uses OUs to group AWS accounts for administration as a single unit. IBM documentation additionally describes an OU as a construct representing an organization whose resources are logically separated from those of other, similar organizations. Precise capabilities, including which object types an OU may contain and what management functions it scopes, vary by platform and deployment.

Why it matters

Organizational units are foundational to how administrators impose structure on otherwise flat collections of directory or account objects. By grouping related users, computers, groups, or cloud accounts into containers, administrators can reason about and manage large populations as coherent units rather than as individual objects. This structural clarity underpins both operational efficiency and the ability to reason about who administers what within a directory or account hierarchy.

The more consequential value of OUs lies in delegated administration. In Microsoft Active Directory, an OU is commonly used as a scope for delegating administrative control, so that responsibility over a subset of objects can be granted without handing over domain-wide authority. In AWS Organizations, grouping accounts into OUs allows administration as a single unit, which simplifies the management of many accounts. A poorly designed OU structure can therefore complicate delegation and management, while a well-planned one supports least-privilege administration and consistent handling of grouped resources.

Because the exact capabilities of an OU, including which object types it may contain and what management functions it scopes, vary by platform, treating OUs interchangeably across Active Directory, Entra Domain Services, and AWS Organizations can lead to misconfigured delegation or policy scoping. Understanding the platform-specific semantics is important for administrators who rely on OUs as a boundary for administrative control.

Who it's relevant to

Active Directory administrators

Administrators who manage Microsoft Active Directory use OUs as containers for users, groups, and computers, and commonly as the scope for delegating administrative control over a subset of objects. Depending on configuration, OUs may also serve as a scope for policy application, making OU design central to how administration is structured within a domain.

Cloud platform and AWS Organizations administrators

Teams managing AWS accounts use OUs within AWS Organizations to group accounts and administer them as a single unit, simplifying management across many accounts. Those working with Microsoft Entra Domain Services may create custom OUs within a managed domain. In both cases, the platform-specific semantics of the OU differ from Active Directory and should be understood on their own terms.

Security architects and identity governance leads

Because OUs frequently serve as a boundary for delegated administration, architects and governance leads concerned with least-privilege administration need to account for how OU structure shapes who can administer which objects. A clear OU design supports scoped delegation, while an unclear one can obscure administrative reach across grouped resources.

Inside OU

Container object

An OU is a container within a directory (such as an LDAP directory or Active Directory) that holds other objects like users, groups, computers, and nested OUs, allowing hierarchical organization of directory entries.

Distinguished Name (DN) component

An OU typically appears as an 'ou=' component in an object's Distinguished Name, contributing to the hierarchical path that uniquely identifies entries within the directory tree.

Administrative delegation boundary

In many deployments, an OU serves as a scope to which administrative control can be delegated, letting specific administrators manage the objects contained within a particular OU without granting directory-wide privileges.

Policy application scope

Depending on the directory platform, OUs can act as a point at which configuration or management policies are applied to the contained objects; the exact mechanism and behavior vary by vendor and configuration.

Nested hierarchy

OUs can contain child OUs, forming a tree structure that models organizational, geographic, or functional groupings within the directory.

Common questions

Answers to the questions practitioners most commonly ask about OU.

Do Organizational Units function as security groups for assigning permissions?

No. An OU is a container used to organize objects such as users, groups, and computers within a directory hierarchy; it is not a security principal and is not used to grant access itself. In most directory implementations, authorization is handled through group memberships or role assignments, while OUs primarily support administrative structure. Conflating an OU with a security group blurs the separation between organizing objects and enforcing access, so permissions should generally be assigned via groups rather than by placing objects into an OU.

Does moving a user into a different OU automatically change what that user can access?

Not directly. Moving an object between OUs changes its position in the hierarchy and can alter which policies applied at the OU level take effect, but the OU move itself does not authorize or deauthorize access. Any change in effective access typically depends on how policies, group memberships, or inherited settings are configured relative to that OU. The identification and authentication of the user remain unchanged by the move; only authorization-relevant configuration tied to OU placement may shift, depending on the deployment.

How should OU structure be designed to support delegated administration?

OUs are commonly used as boundaries for delegating administrative control, so a structure that groups objects by administrative responsibility often works well. In many deployments, administrators grant control over specific OUs to particular teams so those teams can manage only the objects within their scope. Designing the hierarchy around who administers what, rather than around every organizational nuance, typically keeps delegation manageable and reduces the risk of over-broad administrative rights.

How do policies applied at the OU level interact with nested OUs?

Policies scoped to an OU can apply to objects within that OU and, depending on configuration, to objects in nested child OUs through inheritance. The exact precedence and inheritance behavior vary by directory platform and can be affected by settings that block or enforce inheritance. When planning nested OUs, it is generally worth mapping how policies accumulate down the hierarchy so that unintended settings do not reach objects in deeper OUs.

What are the considerations when moving objects between OUs?

Before moving an object, it is useful to review which OU-scoped policies, delegated permissions, and inherited settings differ between the source and destination OUs, since those may change once the object is relocated. Group memberships typically remain with the object, but policy application tied to OU placement may change depending on configuration. Testing moves in a controlled scope first can help confirm that effective settings behave as expected in your particular environment.

How should OU design relate to provisioning and lifecycle processes?

In many environments, provisioning systems place newly created accounts into a specific OU based on attributes such as department or location, which can then drive OU-scoped policy application. Keeping OU structure aligned with the attributes available during provisioning generally makes automated placement more predictable. Note that lifecycle actions such as access reviews and certification are governance concerns handled separately from OU placement, so OU design supports organization but does not by itself perform governance functions.

Common misconceptions

An OU is the same thing as a security group and can be used to assign permissions to its members.

An OU is an organizational container used for structuring the directory and, in many deployments, for delegation and policy scoping. Groups are the constructs typically used to assign permissions or entitlements. Placing a user in an OU does not, by itself, grant that user the access associated with a group.

OUs are an access control model that determines what principals may do.

OUs relate to directory structure and administrative scoping, not to authorization decisions themselves. Authorization is generally handled by access control models such as RBAC, ABAC, or others, and by the enforcement mechanisms that evaluate policy, rather than by an object's OU placement.

OU behavior is identical across all directory platforms.

The precise capabilities of an OU, including how policies are applied and how administration is delegated, vary by vendor, directory implementation, and deployment configuration, so behavior should be validated against the specific platform in use.

Best practices

Design the OU hierarchy to reflect a stable dimension of the organization (such as administrative or delegation boundaries) rather than volatile attributes, since restructuring OUs can be disruptive in most deployments.

Use OUs for structure and administrative delegation, and use groups for assigning permissions and entitlements, keeping these concerns separate rather than overloading OUs with authorization semantics.

Scope administrative delegation to specific OUs to grant least-privilege management authority, avoiding broad directory-wide administrative rights where narrower delegation suffices.

Validate how policy application and delegation actually behave on your specific directory platform, since these mechanisms vary by vendor and configuration.

Keep the OU tree as shallow and consistent as practical to simplify delegation, policy scoping, and troubleshooting.

Document the intended purpose of each OU and the delegation and policies applied to it, so administrators can reason about the effect of placing objects within it.