FFoundationalActive Directory
Organizational Units and Group Policy Fundamentals
Organizational Units are the containers Active Directory uses to organize objects and delegate administration, and they are also the anchor points where Group Policy attaches. This lesson explains what an OU actually is, how it differs from a group, and how the OU/domain/site hierarchy becomes the map that Group Policy is delivered against.
This lesson builds on
Why it matters
Before you can reason about how Group Policy actually behaves, you need to understand what it attaches to. Group Policy Objects do not float freely in Active Directory; they attach to a specific point in the directory's container hierarchy, and that point is almost always an Organizational Unit. If you cannot explain what an OU is, how it differs from a group, and why it exists as a separate structure at all, then any explanation of GPO scope, delegation, or blast radius will be shallow, because you are describing the delivery mechanism without describing the map it is delivered onto.
This matters just as much for attackers as for defenders. Reading an environment's OU structure tells you how the organization has divided administrative responsibility and where policy is likely to be concentrated, before you look at a single GPO setting.
Key Concepts
- Organizational Unit (OU) — a container object inside a domain that holds and organizes other objects (users, computers, groups, and nested OUs) for the purposes of administrative delegation and policy targeting
- Single-parent containment — every object lives in exactly one OU at a time; this is a tree structure, not a tagging system, and it is what separates OU placement from group membership
- Delegation of administration — the ability to grant a specific account or team administrative rights, such as resetting passwords or creating computer accounts, scoped to a single OU rather than the whole domain
- GPO linking points — sites, domains, and OUs are the only three container types a Group Policy Object can attach to; a GPO does nothing until it is linked to one of these
- OU membership grants no access by itself — sitting inside an OU does not give an object any permissions; access comes from group membership and ACLs, while OU placement determines what administration and what policy reach that object
Theory
Core idea
An Organizational Unit is a container object that lives inside a domain and holds other objects: users, computers, groups, and even other OUs nested inside it. Administrators create OUs to mirror something about the organization, commonly departments, office locations, or device roles, so that objects with similar administrative needs sit together in the directory.
The defining property of an OU is single-parent containment. Every user account, every computer account, sits in exactly one OU at a time. If a computer moves from the Sales OU to the Finance OU, it leaves one and joins the other; it cannot be in both. This is fundamentally different from group membership, where an account can belong to dozens of groups simultaneously with no conflict.
OUs exist for two practical reasons. The first is delegation: an administrator can grant a helpdesk team the right to reset passwords for accounts inside one OU, without touching accounts anywhere else in the domain. The second is that OUs, along with domains and sites, are the only three container types a Group Policy Object can be linked to. A GPO on its own is inert. It becomes active for a set of users or computers only once it is linked to a site, a domain, or an OU, and from that point on it applies to every object contained inside that link. How that link resolves when multiple GPOs apply, and what settings a GPO can actually deliver, is covered where Group Policy Objects themselves are explained; this lesson is about the structure the policy attaches to.
Mental model
Picture a company's physical office building. Every employee has exactly one desk, and that desk sits on one floor, in one department's wing. That physical placement is like OU membership: singular, structural, and independent of anything else about the employee. The same employee might also belong to the book club, the safety committee, and the softball league, all at once, regardless of which floor their desk is on. Those memberships behave like groups: many-to-many, and unrelated to physical location.
Now imagine building management wants to post a notice that applies to everyone on the third floor. They do not walk around handing individual copies to committee members; they pin the notice to the third floor's bulletin board. Everyone whose desk physically sits on that floor sees it, regardless of which committees they belong to. A GPO linked to an OU works the same way: it applies to whoever's account sits inside that container, not to whoever happens to share a group membership.
This is also why delegation and Group Policy exposure travel together with OU placement rather than with group membership. Moving an account to a different OU changes both who can administer it and which policies reach it, in one move, because both things are anchored to the same physical location in the tree.
Common misunderstandings
- Assuming OU membership grants access by itself. Sitting inside an OU gives an object no inherent permissions. Access comes from group membership and ACLs. What OU placement controls is administrative delegation and Group Policy exposure, which are a different question from what the object can do.
- Treating OUs and groups as interchangeable ways to organize accounts. An account belongs to exactly one OU but can belong to many groups at once. If a design needs "everyone who should have this specific access, from anywhere in the org," that is a group problem. If it needs "everyone whose desk sits in this part of the structure," that is an OU problem. Conflating the two produces directory designs that are hard to administer and hard to enumerate correctly.
- Expecting delegated administration to cascade automatically the way GPO settings do. Nested OUs inherit linked Group Policy by default, but administrative delegation granted on a parent OU does not automatically extend to every child OU unless it was explicitly configured to propagate. Someone can have full rights over a parent OU and still have no rights over what got moved into a child OU beneath it.
- Believing OU boundaries are security boundaries. An OU is an organizational and administrative container, not an isolation mechanism. Placing a sensitive computer account in its own OU does not protect it from domain-wide group memberships, domain-linked GPOs, or an account with rights over a parent container further up the tree.
Real-world context
Real environments design their OU structure around whatever axis matters most to them: department, office location, device type, or, in more security-mature environments, administrative tier, separating domain controllers, servers, and workstations into their own top-level OUs so that delegation and Group Policy exposure can be controlled independently for each tier.
During enumeration, the OU hierarchy is one of the first things worth pulling, because it functions as a map before any specific GPO or ACL has been examined. It tells you which parts of the domain are administered by which teams, where nested OUs suggest a more granular delegation model, and which containers are likely to have policy concentrated on them because of what sits inside. That map is what you then overlay with actual GPO links and delegated permissions to understand where the real exposure is.
When you communicate this to a client or an interviewer, the useful framing is that the OU tree is the organization's own answer to "how do we want to slice this domain up," and every downstream decision about delegation and policy targeting inherits that slice. A messy or overly flat OU structure usually means messy, overlapping delegation and policy scope as well.
Communication
Interview answer
An Organizational Unit is a container inside a domain that holds users, computers, groups, and other OUs, and every object belongs to exactly one OU at a time. That single-parent structure is what separates OUs from groups, where membership is many-to-many. OUs exist for two reasons: they are the unit of administrative delegation, letting you grant rights over a subset of the domain without granting them domain-wide, and they are one of the three container types, alongside sites and domains, that a Group Policy Object can be linked to.
A GPO does nothing until it is linked to one of those containers. Once linked, it applies to every object physically contained inside it. What I want to be careful not to conflate is OU placement with access. Sitting in an OU grants no permissions by itself; it determines what administers you and what policy reaches you, while actual access still comes from group membership and ACLs.
Follow-up questions
- What is the practical difference between putting an account in an OU and adding it to a group?
- Why can a Group Policy Object only be linked to a site, a domain, or an OU, and not to a group?
- If delegated rights on a parent OU do not automatically extend to a child OU, what does that mean for auditing who administers a nested container?
- How would you use an unfamiliar domain's OU structure during the first hour of enumeration?
- Why is a tiered OU design (separating domain controllers, servers, and workstations) considered a stronger practice than a flat, department-only structure?
