Organizational Units and Group Policy Fundamentals Brief
What It Is
An Organizational Unit is a container object that lives inside a domain and holds users, computers, groups, and other OUs nested inside it. Its defining property is single-parent containment: every object sits in exactly one OU at a time, unlike group membership, which is many-to-many. OUs exist for two reasons: they are the unit of administrative delegation, 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 three.
Mental Model
Picture an office building where every employee has exactly one desk, on one floor, in one department's wing. That 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. When building management posts a notice on the third floor's bulletin board, everyone whose desk sits on that floor sees it, regardless of committee membership. A GPO linked to an OU works the same way: it applies to whoever's account sits inside that container.
Key Pieces
- OU: a container inside a domain holding users, computers, groups, and nested OUs
- Single-parent containment: every object belongs to exactly one OU at a time, unlike many-to-many group membership
- Delegation: an administrator can grant rights scoped to one OU without touching accounts anywhere else in the domain
- GPO linking points: a Group Policy Object can only be linked to a site, a domain, or an OU; it is inert until linked
- Nested OUs inherit linked Group Policy by default, but delegated administration does not cascade automatically
- OU placement grants no access by itself; access comes from group membership and ACLs
Interview Phrasing
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. 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.
Common Pitfalls
- Assuming OU membership grants access by itself: it grants no permissions; access comes from group membership and ACLs
- Treating OUs and groups as interchangeable: an account belongs to one OU but can belong to many groups at once
- Expecting delegated administration to cascade to child OUs automatically the way linked Group Policy does: it does not unless explicitly configured to propagate
- Believing OU boundaries are security boundaries: an OU is an administrative container, not an isolation mechanism, and offers no protection from domain-wide group memberships, domain-linked GPOs, or rights held further up the tree
Practice Prompts
- Explain the practical difference between putting an account in an OU and adding it to a group
- Explain why a Group Policy Object can only be linked to a site, a domain, or an OU, and not to a group
- Explain what it means for auditing that delegated rights on a parent OU do not automatically extend to a child OU
- Explain how you would use an unfamiliar domain's OU structure during the first hour of enumeration
- Explain why a tiered OU design, separating domain controllers, servers, and workstations, is considered stronger practice than a flat, department-only structure
