Your Active Directory structure defines your organization. Is it flexible? Does it easily adapt to innovation? Or is it rigid with boundaries preventing growth?
Think carefully about these questions. You can see just how important it is for you to have an Active Directory structure that exceeds the needs of your environment. Unfortunately, Active Directory organization is not a simple black and white choice.
Not all is lost though. Many core best practices have emerged over the years. In this guide, we will tie these thoughts together and explore a few innovative ways to organize Active Directory. These steps apply on both new domains or restructures on an existing domain.
Things you should not do in Active Directory organization
Let’s first talk about practices that should normally be avoided when organizing Active Directory. There are always exceptions to any rule (except the exceptions to any rule rule). If you have an extremely compelling reason to ignore any of this advice, do so.
Avoid using/tampering with the default containers or OUs in Active Directory. This includes the Computers and Users container. Do not group users and computers in the same OU. Separate these objects out into separate sub-OUs when applicable.
Security groups can be kept in separate OUs or in the OU (or sub-OU) of its members. Whoever is managing the objects should probably have permissions to manage the security group as well.
Finally, do not apply permissions where the scope is to a single object (computer or user). If you delegate control (ex: resetting user passwords), apply that permission to a security group. This is true even if that security group contains a single user. This removes hardcoded dependencies on objects that can change frequently.
Start your Active Directory structure off right
There are two prominent methods of organizing AD: location or logical. An Active Directory location based structure would include an OU for each physical site and could include sub-OUs for areas in those locations. An Active Directory logical based structure would an OU for each logical component of the organization. For example, Human Resources and Finance would each have an OU.
Both of these approaches can lead to greater management issues. These can be fixed by introducing two changes. First, two+ top-level object OUs should be created first. Second, a hybrid approach should be used to combine the benefits of both methods.
At a minimal, create two top level OU named something similar to Domain Computers and Domain Users. This can be seen in the screenshot below:
These two top level OUs give your domain a central repository for computer and user objects. When you have a single top level OU for these objects, you can easily apply settings across the entire object class (ex: apply a Group Policy setting to all computers). Another benefit is that scoping LDAP queries become a lot more efficient.
From here, your next level of OUs can be organized location based or logically based. I personally prefer location based as many of the additional configuration I do are linked to a location. If your site to site connections are not stellar, you may prefer to use Sites for these settings and to logically structure the sub-OUs. In the picture below, you can see an example location based structure. Corresponding OUs are also created under the Domain Users OU.
On our third level of OUs (the sub-OUs for the locations in my case), we can employ a hybrid organizational approach. We do this by creating an OU for each logical component of the site. For the Sterling site (as seen below), the three departments each receive a sub-OU.
We can apply settings and manage objects in three ways now.
- Domain Object Basis
- Location Basis
- Department per Location Basis
Creating Virtual OUs with Business Units
No Active Directory structure can be perfect. The more granular you become, the more objects that are excluded from actions. The less granular you are, the more inefficient your environment becomes. Security groups can help you strike a balance but they are perfect.
Let’s look at a practical example. Imagine the AD structure pictured above. Now try to easily apply a setting to every sales department computer but only to the sale department computers. It becomes a bit trickier now!
Business Units, a core component of Adaxes, provide virtual OUs for your objects. Business Units can make objects appear in more than one location. In fact, you can get as granular as you would like because the object never moves around in AD! These can provide that missing component that you need to manage any group of objects in any organization.
Learn more adout Adaxes Business Units and how they help in organizing your AD in this article
If you plan on tackling an AD re-org, let us know how you plan to tackle it! Feel free to ask for any guidance.
Joseph Moody is a network admin for a public school system and helps manage 5,500 PCs. He is a Microsoft Most Valuable Professional (MVP) in Cloud and Datacenter Management and blogs at DeployHappiness.com.