Special Reports
Active Directory Design Best Practices
Why mess with the default AD structure? Better security and organization are two reasons. Let's take a closer look.
Recently, I read a blog article in which the author indicated that he likes to take a hands off approach when it comes to Active Directory design. His primary argument was that the default Active Directory structure is usually adequate, and that tampering with Microsoft's design will only lead to problems.
While I certainly found that blog post to be thought-provoking (I wish that I could remember where I found it), I have to disagree with the author on a couple of points:
- The default Active Directory structure may be adequate, but there is a big difference between adequate and optimal.
- Tampering can lead to problems, but Microsoft did design the Active Directory structure to be customizable.
Customizing the Active Directory structure is only problematic if you don't know what you are doing.
There was once a time, many years ago, when I agreed with the blogger's philosophy, but for different reasons. I used to recommend that small- and medium-sized businesses keep their Active Directory structure as simple as possible, and this often meant using the default Active Directory structure. Before I tell you why I have since reevaluated that idea, let me explain my reasoning behind keeping things simple.
As I'm sure you know, group policies are one of the primary security mechanisms used by Windows. Microsoft has designed group policies to be hierarchical in nature. In other words, you can create multiple group policy objects, which reside at various levels of the Active Directory, and those group policy objects will combine to form the effective policy.
My rationale behind my original recommendation that SMBs try to keep things simple was that it can be difficult to secure complex environments. Group policy objects often combine in ways that result in unanticipated security settings. On the other hand, if you have a simple Active Directory structure and only use the default domain policy, then the policy's effects are absolutely predictable.
So what made me change my mind? A couple of things, starting with my idea of a complex environment. I tend to do a lot of consulting projects for SMBs. As I did these jobs, I usually saw two different types of Active Directory environments. Organizations that I worked for tended to either keep things really simple by sticking with the default AD structure, or the AD structure was extremely messy. It was the messy Active Directories that I was defining as complex. As time went on though, I began to realize that when properly designed, an Active Directory could be complex without being messy.
The other thing that changed my mind was what happened when some of my client's businesses began to grow. Rapid growth often required AD restructuring. What I discovered was that it would have been much easier to spend a little bit of extra time up front and design the Active Directory in a way that anticipated future growth than it was to restructure the Active Directory once the growth had already occurred.
With that in mind, I have established a few guidelines for good Active Directory design. As I'm sure you know, group policies are broken down into user policy settings and computer policy settings. It is possible to define both user and computer policy settings within a single group policy object. Instead though, I recommend that each of your group policy objects define either user policy settings or computer policy settings, but not both.
My second recommendation is that you create an Organizational Unit (OU) structure that makes sense for your organization. You should have some OUs that will store computer objects and some that store user objects. You should then attach a dedicated group policy object to each OU.
In the default Active Directory structure for example, Microsoft gives you a Domain Controllers container and a Computers container. I like to expand on this concept. For example, I like to move the user's desktops out of the Computers container and into a custom OU named Workstations. That way, I am not forced to apply the same security policy to user workstations as I am to network servers.
With the user workstations removed from the Computers container, that leaves behind any member servers that may exist. Depending on the size of the organization, I might create additional containers for specific types of member servers. For instance, I might create an Exchange Servers OU so that I can apply a dedicated security policy to an organization's Exchange servers.
In some organizations, the Users container works fine. In other organizations it may make more sense to create a dedicated OU for each department. That way, you can apply group policy settings on a per department basis.
I realize that this approach may seem like overkill, especially for smaller networks, but there is a method to the madness. Any time that a user logs on to the network, they are using exactly one user account and one computer. By structuring your Active Directory in the way that I have described you can ensure that the optimum security settings are in place, regardless of where a user logs on.
Stay tuned! In the next part, we continue with a few more best practices for desiging a complex but clean AD infrastructure.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.