This topic has come up for as long as Active Directory (AD) has been around: how do you create an OU structure that makes sense? When it really comes down to it, there are only three things that matter in an OU structure: finding things, assigning permissions, and applying policies.
Finding Things:
We all know that you can search AD to find users and computers, but sometimes it’s nice to just be able to click on a location and see what’s in there, or easily validate that a user/computer is in the OU you think it is. This is one of the biggest reasons to sort users/computers into a logical OU structure.
Applying Policies:
Applying GPOs to OUs without having to do filtering makes your life a lot easier. For example, setting a new screen timeout policy for all computers in Houston, but no other location. If your computers are organized by location, you can easily do that. If they’re organized by business unit, that might be very difficult. You can technically assign policies through AD sites (think Sites and Services), but as a whole, it’s not favored by most people and can make troubleshooting very difficult as 99% of people don’t do it that way.
Assigning Permissions:
If you have multiple admins at different levels of the organization, then the permissions can also be assigned at the OU level. For example: Bob can create, delete, and assign permissions to anything in Kentucky, but not to any other state.
Picking an OU Hierarchy:
There are three basic hierarchies that people use for their OUs. We’ll explain each and then the pros and cons for them.
- Location First
Location keys on the locality of users/computers as the main differentiator. In this model the top level would define locations. This may be separate locations in a city, cities in a state, states in a country, or countries. For example:
Obviously, it doesn’t have to be this detailed for an organization. For example, if you’re only in the US, there’s no reason to have a North America or a United States level in your hierarchy. Below this level you can break it out by users, computers and servers, or by department.
Pros:
-
- Easy to assign policies at a location. EX: All of the Plantside location has a screen timeout of 15 minutes.
- Easy to see all users/computers at a location, or a state, or a country.
- Often lines up with where delegated permissions need to be assigned.
Cons:
-
- If you need to assign policies based on departments or type of users, this can make a complicated hierarchy. EX: If accounting is at five locations, there will end up being a lot of different accounting OUs under this structure if we want to give them specific policies.
- Assigning higher level permissions will hit both users and computers. EX: assigning a policy at the Kentucky level will apply to both users and computers at the lower levels.
- Users and Computers
Splitting out by users/computers at the top level allows for easier global policy assignments to users/computers at each level as it’s pre-split by appropriate type.
In this case, since everything is pre-broken out by desktops/laptops, servers, and users at the top level, it makes it easy to assign policies based on granular computer/user usage.
Pros:
-
- Granularly broken different type/departmental use. EX: you can assign a policy to mobile laptops or to accounting users without necessarily overlapping.
- Easy to assign permissions globally through the company
Cons:
-
- Easy to create accidentally conflicting assignments based on what type of device a user is using.
- When users log into different machines than normal, difficult to figure out which policies they will get
- Difficult to assign permissions to certain groups at certain locations. EX: if accounting in Kentucky has different needs than accounting in Canada.
- Can be difficult to delegate permissions to lower level admins.
- Department
Breaking out by department makes assigning permissions based on job role much easier. The top level is just a department and then you can assign policies or management granularly based on where someone works.
Pros:
-
- Easy to assign permissions based on the job role that someone has. EX: Want all accounting computers in the world to lock the screen after 5 minutes?
- Easy to have department-based permission delegation. EX: bob deals with all accounting user adds/removes.
Cons:
-
- Difficult to assign policies based on a location without going through multiple sub-folders
- Most organizations don’t assign policies exclusively based on department
So, what’s the ‘right’ answer?
Well, it’s almost always a hybrid of multiple different things and depends exclusively on what you’re trying to accomplish. Do you have domestic as well as international IT staffs that need to control their respective locations, but policies that need to be assigned to specific departments? Maybe you make your top-level division continent, then country, then department, then computers and users. That allows for permissions to be assigned to the continent/country for delegated administration, then departmental policies, then users and computers below that. If you care about specific states/cities, you can include that as well.
Have specific policies that need to be assigned based on the type of user regardless of location but also have some policies that need to be assigned based on location or work role? Perhaps you’ll have a top-level designation of type of user followed by location. For example, a top level of mobile users, desktop users, and work from home users, followed by departmental then location.
What the design really comes down to is thinking through where you want to assign permissions and policies to users. Don’t worry about the most extreme edge cases that you’ve never ran into but can imagine. There will always be exceptions to every design you can think of. If you can accommodate 90% of your normal use cases, that last 10% can be clarified with filters and other things.