Child Domain vs Trust Relationship

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?

Thanks-

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?

Solution 1:

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.

Solution 2:

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.

Solution 3:

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.