The more granular you become, the more objects that are excluded from actions. No Active Directory structure can be perfect. We can apply settings and manage objects in three ways now. For the Sterling site (as seen below), the three departments each receive a sub-OU. We do this by creating an OU for each logical component of the site. On our third level of OUs (the sub-OUs for the locations in my case), we can employ a hybrid organizational approach.
Corresponding OUs are also created under the Domain Users OU. In the picture below, you can see an example location based structure. 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.
I personally prefer location based as many of the additional configuration I do are linked to a location. Another benefit is that scoping LDAP queries become a lot more efficient.įrom here, your next level of OUs can be organized location based or logically based. 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). These two top level OUs give your domain a central repository for computer and user objects. This can be seen in the screenshot below: Second, a hybrid approach should be used to combine the benefits of both methods.Īt a minimal, create two top level OU named something similar to Domain Computers and Domain Users. First, two+ top-level object OUs should be created first. These can be fixed by introducing two changes. For example, Human Resources and Finance would each have an OU.īoth of these approaches can lead to greater management issues. An Active Directory logical based structure would an OU for each logical component of the organization. An Active Directory location based structure would include an OU for each physical site and could include sub-OUs for areas in those locations. There are two prominent methods of organizing AD: location or logical. Start your Active Directory structure off right This removes hardcoded dependencies on objects that can change frequently. This is true even if that security group contains a single user. If you delegate control (ex: resetting user passwords), apply that permission to a security group. Whoever is managing the objects should probably have permissions to manage the security group as well.įinally, do not apply permissions where the scope is to a single object (computer or user). Security groups can be kept in separate OUs or in the OU (or sub-OU) of its members. Separate these objects out into separate sub-OUs when applicable. Do not group users and computers in the same OU. This includes the Computers and Users container. If you have an extremely compelling reason to ignore any of this advice, do so.Īvoid using/tampering with the default containers or OUs in Active Directory. There are always exceptions to any rule (except the exceptions to any rule rule). Let’s first talk about practices that should normally be avoided when organizing Active Directory. Things you should not do in Active Directory organization These steps apply on both new domains or restructures on an existing domain.
In this guide, we will tie these thoughts together and explore a few innovative ways to organize Active Directory. Many core best practices have emerged over the years. Unfortunately, Active Directory organization is not a simple black and white choice. You can see just how important it is for you to have an Active Directory structure that exceeds the needs of your environment. Is it flexible? Does it easily adapt to innovation? Or is it rigid with boundaries preventing growth? Your Active Directory structure defines your organization.