My original lab AD structure was built out of instinct and reinforced by what I’ve witnessed across ten-plus years administering environments of all sizes. I had root-level OUs organized by department, with users, devices, and groups nested within. That approach felt natural, and it matched what I’d seen work in production. One thing I knew going in: you never use the default containers. Anything sitting in the built-in Users or Computers container is an administrative liability waiting to happen.
Before I ran the restructure script, though, I started thinking about my current production environment and the goals on the horizon. The one that mattered here was our intent to move to Entra ID for identity management and step away from on-premises AD entirely. Line of sight to domain controllers has become a genuine obstacle in my professional life. We’re contending with users who spend approximately five minutes in the office before jetting off to wherever it is they plan to be. So why would I subject my homelab and its imaginary userbase to the same constraints? And for that matter, why were we doing it this way in the first place?
The simplest answer is that Group Policy targeting was easiest when it was pointed at OUs. If you had a policy, like file server access and drive mapping, that was largely dependent on which department a user worked in, it was easier to create that OU and drop everyone who needed access into it. Access controls could be created and maintained with minimal overhead, and in the case of file shares in particular, enumerated ACLs handled the fine-grained permissions once the OU scoped the policy. It worked. For a long time it worked well.
Why Microsoft’s guidance has shifted
Microsoft’s guidance on identity and access management has shifted decisively. Their own OU design documentation now points to two specific use cases for OU structure: delegation of administrative access, and application of the handful of Group Policies you may retain after moving into the cloud. That second point is worth sitting with. When Intune takes over policy delivery, policies target groups, not OUs. The department-driven OU hierarchy that made GPO management tractable suddenly has no remaining function for most user and device objects. What it does do is add maintenance overhead and create a structure that’s harder to extend cleanly into a hybrid or cloud-first model. The security case is compelling too, and deserves its own post, but even from a pure operational standpoint the math stops working in favor of deep nesting.
The new structure
The decision, then, was to flatten. In place of multiple nested OUs mirroring the org chart, the new structure distills down to four root-level OUs and twenty-one nested OUs. Administrative accounts live in their own segmented hierarchy where they belong. Everyone else, from CEO to receptionist, lands in _Identity > Users. Coming from years of hyper-segmentation, it feels almost subversive. But even before your first cloud migration, you’ll find it to be a more logical and defensible design.
Access by group membership, not location
In all of this design, however, I remembered exactly why I personally enjoyed the old OU design. At a glance, I could look at a user’s object path and have a general idea of their workload. If Mabel Jenkins joins Mad Miller Labs as an HR Associate, I know that at minimum she would belong in the HR OU and be automatically granted rights that would make sense for her role. How could I scope access, rights and roles in such a way that made sense to Engineering and Help Desk?
Access instead is dictated by Security Group membership. In Mad Miller Labs, this translated to a nomenclature leveraging two prefixes, three functions and twelve scopes.
| Prefix | Meaning |
|---|---|
| SG | Security Group |
| DL | Distribution List |
| Function | Meaning |
|---|---|
| Access | Grants permission to a resource |
| Policy | Controls GPO or configuration scope |
| Role | Delegates an administrative capability |
| Scope | Meaning |
|---|---|
| Global | Applies org-wide |
| InfoServices | IT Department |
| HelpDesk | Help Desk team |
| Systems | Systems Engineering |
| Networking | Networking team |
| Developers | Development team |
| HR | Human Resources |
| Legal | Legal |
| Marketing | Marketing |
| Engineering | Engineering |
| Executive | Executive Staff |
| Finance | Finance |
Using this as a blueprint, access can be scoped truly by focus and allows a more personalized experience:
The naming convention does what the OU path used to do, but in a form that travels. A Help Desk technician looking for every resource scoped to HR doesn’t need to know the org chart, they search for SG-Access-HR-* and the answer is right there. Mabel Jenkins lands in _Identity > Users like everyone else, and her access follows from group membership, not her location in the tree. That’s actually easier to audit, easier to extend, and easier to explain to a security team.
Why this matters for Entra
What this structure is really doing is separating two concerns that department-based OUs quietly conflated: where an object lives, and what it can do. The location used to carry meaning it was never designed to carry. Flattening forces that meaning into groups, where it was always more appropriate, and leaves the OU hierarchy to do the two things it was actually built for: administrative delegation and GPO scope.
When Entra Connect Sync enters the picture, this pays off immediately. Sync rules target OUs and group memberships. A clean, flat structure with well-named groups gives you precise control over what gets synced, to whom, and with what attributes. A department-driven hierarchy tends to produce sync configurations that are either too broad or painfully over-filtered, because the OU boundaries don’t map cleanly to what Entra actually needs.
That migration is still on the horizon for Mad Miller Labs. But the structure is ready for it, and that was the point.
This came up during the build-out of Mad Miller Labs, a home lab enterprise merger simulation running Nutanix CE 6.8.1 on a Dell PowerEdge R640. More posts from the build as the lab grows.