Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So here is the scenario-

We are in the process of centralizing IT to a data center in a single location. I currently have 12 different operating companies that need a shared security and exchange functionality. As it stands they are all separate individual domains of varying levels. There is a company wide accounting system that needs to be integrated with AD currently running in a completely separate domain as well that I would like to see people using their own AD log on info to use.

Here is my question-

Knowing that all the Active directory domains need to be touched regardless to get them all up to a uniform functional level and that there is significant work to be done no matter what, which configuration would be best? I know there are several points to each one, but I want to make sure I am covering my bases now before choosing a path. Do I go for a single forest\parent domain? Or separate domains using trusts between the corporate domain and the operating companies like a spoke and hub config? What are the pros and cons of each?


Additional details: There is some need to have administration delegation...it operates as more of a franchise environment than a single company. There will be administration staff responsible for just their company and nothing more. The hardware and software overheads are a non-issue, each company uses a different set of policies anyway, so the policy portion provides no real advantage or disadvantage.

If operating companies are spread out across the US does this change your recommendations at all?

share|improve this question
see my edit to my answer –  mfinni Jan 10 '13 at 0:13
1 - Be sure you are always clear when differentiating between domains and forests. I often hear people say "we have multiple domains" when what they actually mean is "we have multiple forests"...that, or they use the terms interchangeably. The difference makes a BIG difference in the answer that you get. –  SturdyErde Jan 10 '13 at 15:26
2 - Multiple forests could work in this scenario. But there's a great saying about multiple forests that goes something like, "just because you can--DON'T." :) I have been administering a 5-forest environment for a couple of years and we are now planning on consolidating it again. There have been some neat benefits and experiences with the environment, but it brings up unending hassles that need to be continually worked around. –  SturdyErde Jan 10 '13 at 15:28
A few more notes: if you have a single forest with multiple domains within it, they inherently all trust each other. Multiple forests would need trusts to be manually created. Also, having multiple names within a forest does not necessary mean that they all need to follow a parent/child model. Your domain design can be deep, or wide, or a combination of the two. Finally, if you are looking into the option of sharing Exchange (and Lync, SharePoint, etc) with multiple forests, search the string "Exchange resource forest." –  SturdyErde Jan 10 '13 at 15:31
add comment

3 Answers

up vote 7 down vote accepted

The strongest reason to not go with a single domain (and forest) is if you absolutely have to have separate admins in each forest. That's the security boundary. If the same folks are going to have the full set of keys, then make it easy on them. To be clear, I'm not talking about delegation for certain tasks - this is the group of people who are going to be enterprise admins.

This doesn't change my recommendations much, because you can delegate things out as needed, as I said above. If part of the org has local admins that need to be able to edit the GPO that is assigned to their OU, you can give that to them, as an example. However, if they need total control over their part of the domain, to the point that they need to be able to lock you out of it, then you need separate forests, and might have a tough time sharing exchange. So, since you're sharing "security and exchange", it sounds like a single domain is still the right way to go.

share|improve this answer
Gotta clarify: domains are actually not considered a true security boundary; a forest is a security boundary as far as Active Directory is concerned. However, per your point, a domain can be considered an administrative boundary, which is what @NotDrowningYet seems to need. –  SturdyErde Jan 10 '13 at 15:30
Your first point is what I meant by "(and forest)" prior to saying "that's the security boundary". –  mfinni Jan 10 '13 at 16:52
add comment

Personally, if this is a centralisation project, I would use one domain and use OUs to separate things. This saves having to have full redundancy for each child domain, makes roaming and movement easier and cuts down massively on configuration and complexity.

There are almost no downsides if you configure sites and services properly.

share|improve this answer
add comment

Parent/Child domain structure is an artifact of the 20th century. There was a rationale at one point, perhaps when acquiring/spinning off companies, it made more sense to segregate business entities in their own domain.

We have pretty much that, a parent root domain with 13 child domains. All those domains have trusts, and if the trusts breaks, so does everything else. In my experience these breakages are usually self-inflicted, but the impact is very high. Oh, and they can break in two directions, so if you go that route, make sure you know how to use nltest to verify the trusts on all domains in both directions if you have an issue.

There are other implications. All of those domains have multiple partitions that are replicated to the global catalog. Our GC has something like 40+ partitions. Replication is more complex and there is more of it to break. Like repadmin? You better, if you go with separate domains.

I would not pursue a parent/child domain strategy unless there was a compelling need to do so.

One other thing, if the domain where the accounting application is located needs to communicate with other servers (such as front end web servers), and you are using impersonation, those servers need to be in the same domain. Of course if you have flat domain this isn't an issue, but some large, distributed AD implementations get burned by this. User accounts can be in any domain, but the resource servers such as front end web servers and back end databases need to be in the same domain if using impersonation.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.