MCPMag.com

Sign up for our newsletter.

I agree to this site's Privacy Policy.

In-Depth

AD Design Best Practices: Know Your Domains

When setting up directory services on a Windows network, it's truly all about the infrastructure.

In the first part, I talked about OU design as it relates to group policy-based security. In this article, I want to continue the discussion by talking about planning your Active Directory’s domain structure.

One of the first design decisions that you will have to make when creating a new Active Directory environment is how many domains you want to have, and where those domains should be placed. In some organizations it is perfectly acceptable to use a single domain, while other organizations require multiple domains. So how do you know which domain design is right for you?

There are many different reasons for using multiple domains, but I like to think of domains primarily as administrative boundaries. Therefore, if you need to give someone administrative control over a subset of the network, then you might consider making that part of the network a separate domain.

Single Domain Forests
Single domain forest tend to work out best in small- to medium-sized organizations. The primary benefit to a single forest domain is ease of management. Anyone belonging to the Domain Admins group will have the authority to manage the entire forest.

Multiple Domain Forests
As I mentioned earlier, creating separate domains is usually a way of establishing administrative boundaries. If you do plan on creating multiple domains, then Microsoft recommends that you reserve the forest root domain (the first domain created in an Active Directory forest) solely for administering the forest infrastructure. All other functionality should be performed by child domains beneath the forest root domain.

Geographical Domains
Probably the most commonly used model for multi-domain forests involves creating a separate domain for each geographic location. For example, if an organization had its headquarters in Miami, and had satellite offices in Las Vegas and New Orleans then the Miami office would host the forest root domain as well as a child domain dedicated to serving the needs of the Miami office. The New Orleans and Las Vegas offices would each have their own domains.

The nice thing about this design is that it allows each office to be semi-autonomous. The down side is that it requires each office to have their own IT staff to manage the on-premise domain.

I have heard some IT professionals state that you should always create a separate domain for each office because doing so allows you to control Active Directory replication traffic. While creating separate domains does control replication traffic, you can also control replication traffic by placing each office into a separate Active Directory site. The method that you should use really just depends on your administrative needs.

Departmental Domains
Some organizations like to create a separate domain for individual departments. This is a great way of keeping the departments isolated from one another. Once again though, the down side to this technique is that as the number of domains increases so does the management burden.

There is nothing wrong with creating a separate domain for each department, but you do have to consider who will manage those domains.

About the Author

Brien Posey is a seven time Microsoft MVP with over two decades of IT experience. As a freelance writer, Posey has written many thousands of articles and written or 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 healthcare 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. When He isn't busy writing, Brien Posey enjoys exotic travel, scuba diving, and racing his Cigarette boat. You can visit his personal Web site at: www.brienposey.com.

comments powered by Disqus

Reader Comments:

Mon, Oct 22, 2012 User

for example, i have 3 locations and and single forest with 3 domains for each location. but i want users from all 3 domains to get authenticated from all locations.do i need to deploy domain controller for every domain at each location ?

Sun, Oct 3, 2010 Ravi

Microsoft no longer recommends the multiple forest design. The forest, not the domain is the security boundary. so it is pointless to create more domains, except that you are wasting domain controllers and making your infrastructure more complex. Read this for more info: http://www.activedir.org/Articles/tabid/54/articleType/ArticleView/articleId/68/Default.aspx

Fri, Oct 1, 2010 GarW

No matter the size of the organisation, the starting point for dpomain design should always be single/forest/single domain and this is suitable for the vast majority of domains regardless of size. Multiple domains increases complexity significantly (and needlessly), especially as users move around and services are shared amongst domains

Thu, Sep 30, 2010 DaveN

Interesting stuff - thanks!

Wed, Sep 29, 2010 DarrenC

I've designed very large active directories (78,000+ users and 100,000+ computer objects) with a single parent domain, and a single child domain. The parent domain was simply a root for a certificate authority and schema. The child domain is where all of my users and computers were located. I simply delegated admin permissions to OUs to separate departments, geographic boundaries, even multiple companies that operated under the parent-company. The domain administrators were a small centralized group, the day-to-day admins had control of their OU, that's all--that was the boundary. Multiple domains sounds like additional infrastructure hardware costs and headaches that I just don't need.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above