If you're a Windows Systems Administrator, then you've probably had to manage Active Directory Users and Computers. To the uninitiated, it can seem simple - it's just a bunch of computers and users in a folder-like structure known as Organizational Units (OUs). However, understanding the hows and whys of designing the structure in certain ways to meet your company needs is an important consideration. If it's not done right from the start, it can be a project in itself to unravel the resulting mess to bring it all back to a manageable state.
The main considerations on how to structure OUs come down to three areas; ease of management, permissions and group policies.
Most commonly, the OU structures people use are flat (no sub OUs), geo-based, department-based, or role-based. Often there’s a mix of these structures rather than a single style chosen for the entire environment.
Permissions
Delegation of control works like most security methodology - apply the settings at the top level OU that you want to start at, and it will flow down to all child OU and objects inside them. Without a well thought out OU structure, this can get messy quickly. You can deny inheritance on OUs so they don't get the security settings above them which is required in some scenarios, but can add to the complexity of managing permissions.
Having your helpdesk have access to reset user passwords might be fine for standard staff, but you may not want them to be able to do it for any account that has higher level access (especially domain administrator). Having different account types in different OUs gives you the flexibility of different access levels and permissions. The same applies to computers and can avoid human error occurring when someone goes to disable or reset a computer account - something you generally don't want to happen on a production server.
It's also worth mentioning that ideally, you should create a dedicated security group for each set of permissions used for Active Directory, then add the users who need that access into the group. It might seem like more work at the time, but it's very easy to manage and work out who has access to what. If you've had to manage file shares and permissions before, similar logic applies.
Group Policies
Similarly to permissions, Group Policies get applied to an OU and feed through to all child OUs, unless they are configured to block inheritance. For example, your server group policies may be very different to your end user computer group policies. Because of these different security requirements, it makes much more sense to have servers as a different higher-level OU. You may have some global settings you want to apply to every computer object (such as a password policy), and then extra settings that only apply to Workstations.
You may also want to break those down again further to geographical locations; site settings can then be applied such as pointing workstations in the New York OU to the New York WSUS server.
Here's an example design using the above criteria, but again you'll need to decide what's best for your situation and requirements:
One other point to mention is that by default, top level folders called 'Users' and 'Computers' are created. Don't use these as they're not proper OUs, but there for legacy reasons.
Ease of Management
This is a consideration around the naming conventions and design make the objects inside it simple to find. Having Computer objects go into an OU called Computers makes sense in this aspect, but it probably makes sense to separate servers and clients. You may want separate OUs for Security Groups, Distribution Lists, service accounts, standard user accounts, admin accounts and so on. This also means that when a new object is created, anyone can easily work out based on the design where the object should go.
This really only applies after the other two considerations have been decided, and hopefully most of those choices will already lead to a well laid out structure.
Conclusion
If you've already got an existing mess and want to start again, create a new top-level OU and create a design there of what you're after. Once you have that design in place, make sure everyone agrees and is happy with it. From there, you can link or re-design your Group Policies and link them as required, and finally start moving objects across. If anything goes wrong, you can always move the objects back and work out what the problem was. Keep migrating until everything is moved, and then finally you can start to remove the old OU structure.
For those designing a brand new OU structure, don't get too caught up in the design; as long as your objects are broken up logically, it won't be overly difficult to move OUs around. Put in a bit of effort at the start and you should have an easy to navigate and use result.
This is also an ongoing task – maintenance and reviews are necessary to keep your environment clean as well as secure. Having a user or computer in the wrong OU is more than just untidy, it may be applying different Group Policies that don’t lock down the environment in the way you expect. It’s worth investigating automation in this area too, and Adaxes can help with controlling workflows, business rules and scheduled tasks to prevent mistakes.
Adam is an IT expert from Australia who has been working in the industry for over 15 years with a systems, infrastructure and operational service background, mainly focusing on Microsoft-based systems, including Active Directory, Exchange and Office 365.