none
Active Directory Design Strategy - Child Domain versus OU

    Question

  • 1) What are the pros and cons using ROOT DOMAIN>CHILD DOMAIN>OU'S versus ROOT DOMAIN>OU'S for individual sites in active directory?

    2) Does one model scale better than the other?

    3) Does one model work better for "absorbing" newly purchased companies and their domains?

    4) Is one model more "secure" than the other - how so?

    5) What model do you use/prefer and why?


    Background: I personally prefer the single root domain>OU model as I will be the domain/group policy admin. We are a growing company with nine sites that currently use a single root domain with sub-ou's for each site and then users, computers etc. The goal is to have each site have an IT team to manage their own users, computers etc. and group policy to be managed centrally. We do not need different password policies at each site. We have been told that our current design is less "secureable" than using a child domain for each site.

    I am looking for as detailed answers as possible please. I also know there may be no "correct" answer to some of these questions. I am looking for pros/cons and opinions.

    Thanks all!
    Tuesday, August 24, 2010 1:13 AM

Answers

  • Hi Voldar and Miles

    It's always interesting to see different opinions.  :-)

    Just to be clear, the schema is the same throughout the forest.  The empty root + child model gives you the ability to host the Schema Master and Domain Naming Master FSMO roles, together with the Schema Admins and Enterprise Admins groups in a separate, dedicated root domain .  I personally don't think this buys you much additional security or lowered risk.  As others have stated, the domain is not considered a true security boundary, which means that Domain Admins in child domains have the potential to take control of the forest (through known exploits).  In other words a Domain Admin in the child domain can give themselves Enterprise Admins or Schema Admins privilege (albeit with some effort).  Given this security consideration, locating those 2 FSMO roles in the root domain gives you perhaps some operational safety, but no real security.  And it comes at significant additional cost and complexity. 

    I haven't seen a greenfield deployment of the empty root + child domain model for about 5 years now.

    Tony

    Tuesday, August 24, 2010 7:06 AM
  • I would go for a single domain forest unless you have a good reason not to.  You don't get any meaningful security benefit from separate domains (the forest being the security boundary) and multi-domain forests are more costly and complex to operate.

    http://www.activedir.org/Articles/tabid/54/articleType/ArticleView/articleId/68/Default.aspx

    http://markparris.co.uk/2009/12/09/empty-root-place-holder-%E2%80%93-still-a-valid-design-choice/

    I'd really like to hear the argument for the single domain model being "less securable".  What reasons did they give?

    Alexei

    Tuesday, August 24, 2010 1:32 AM
  • The primary benefit of having multple domains is greater replication control (with Windows Server 2008-based DCs, Fine Grained Password Policies give you ability to configure multple password policies in the same domain). The drawback is increased complexity of forest-wide administration and additional hardware requirements.

    Mergers/acquisitions typically involve domain migrations - this can be done in similar manner in either model.

    Since a domain does not constitute a "true" security boundary, there are no meaningful security advantages to either one - although having a single domain will make implementation of security easier.

    Single domain forest is a common recommendation. You should use it unless there are compelling reason not to do so (such as, for example, remote locations connected via low-bandwidth/unreliable links which require a local domain controller)

    hth
    Marcin

    Tuesday, August 24, 2010 1:32 AM
  • I would go for a PlaceHolder Domain model = Root domain + ONE Child domain containing the OU's for your sites. There are two distinct advantages to this design. First, as with the peer-root model, the schema is separate from the user domains, thus limiting their exposure and helping to protect the schema. Second, the namespace for the user accounts is consistent in the namespace, thus mitigating any potential political issues. The Root domain will be only to hold the EA and SA accounts/groups and/or any other application services. The child domain has the rest and in fact it is the place where almost all of the administration is happening. (99%).

    The "less securable" reason I have in mind is that ANY user with domain administrator rights in the "Root domain + OU's for sites" can make himself member of the EA or SA group without any restriction.

    Tuesday, August 24, 2010 4:28 AM
  • The only thing I'd add is that yes like everyone has said the forest is the security boundary.  I'd like to share a quote from Tony's great activedir list (highly recommend everyone subscribe to that) from a few years ago

     Quote by Laura Robinson (not taking credit for Laura’s good summary)

    ****Laura's quote from activedir*****
    Your domain admins for *any* domain can already muck up your entire forest. Make no mistake about that. Domains are not security boundaries, merely replication, administration and “simple oops protection” boundaries. Therefore, using the rationale that your DAs for the other domains can’t break the entire thing right now isn’t technically true. They have to work a little harder to muck up the entire forest, but they can certainly do it

    *******end of quote *************

    I do agree with her; yes the forest takeover exploit exists but the accidental/easier elevation by a DA in the root just adding themselves to the schema or enterprise admins group is much more likely

    Right now where I am and have been we use an empty root but that is because it has always been there and a pain to consolidate just to get rid of the empty root.  If I'm starting a new design I'd go in trying to have only one domain and only expanded if there was a good reason.

    Thanks

    Mike


    http://adisfun.blogspot.com;
    Tuesday, August 24, 2010 2:39 PM

All replies

  • I would go for a single domain forest unless you have a good reason not to.  You don't get any meaningful security benefit from separate domains (the forest being the security boundary) and multi-domain forests are more costly and complex to operate.

    http://www.activedir.org/Articles/tabid/54/articleType/ArticleView/articleId/68/Default.aspx

    http://markparris.co.uk/2009/12/09/empty-root-place-holder-%E2%80%93-still-a-valid-design-choice/

    I'd really like to hear the argument for the single domain model being "less securable".  What reasons did they give?

    Alexei

    Tuesday, August 24, 2010 1:32 AM
  • The primary benefit of having multple domains is greater replication control (with Windows Server 2008-based DCs, Fine Grained Password Policies give you ability to configure multple password policies in the same domain). The drawback is increased complexity of forest-wide administration and additional hardware requirements.

    Mergers/acquisitions typically involve domain migrations - this can be done in similar manner in either model.

    Since a domain does not constitute a "true" security boundary, there are no meaningful security advantages to either one - although having a single domain will make implementation of security easier.

    Single domain forest is a common recommendation. You should use it unless there are compelling reason not to do so (such as, for example, remote locations connected via low-bandwidth/unreliable links which require a local domain controller)

    hth
    Marcin

    Tuesday, August 24, 2010 1:32 AM
  • I would go for a PlaceHolder Domain model = Root domain + ONE Child domain containing the OU's for your sites. There are two distinct advantages to this design. First, as with the peer-root model, the schema is separate from the user domains, thus limiting their exposure and helping to protect the schema. Second, the namespace for the user accounts is consistent in the namespace, thus mitigating any potential political issues. The Root domain will be only to hold the EA and SA accounts/groups and/or any other application services. The child domain has the rest and in fact it is the place where almost all of the administration is happening. (99%).

    The "less securable" reason I have in mind is that ANY user with domain administrator rights in the "Root domain + OU's for sites" can make himself member of the EA or SA group without any restriction.

    Tuesday, August 24, 2010 4:28 AM
  • Hello,

     

    Thank you for your post here.

     

    In most scenarios, one domain in one forest deployment would be good. However, as Voldar mentioned, in some specific environment Root domain (for management) + child domain (for production) would be an alternative choice which provides more AD scalability and secure. In this two domain environment, the root domain will not hold any production domain users and groups. The DC(s) in the root domain will hold the forest level FSMO roles which have the control of the domain naming and AD schema.

     

     

     

     

     

     

     

     

    Tuesday, August 24, 2010 6:45 AM
    Moderator
  • Hi Voldar and Miles

    It's always interesting to see different opinions.  :-)

    Just to be clear, the schema is the same throughout the forest.  The empty root + child model gives you the ability to host the Schema Master and Domain Naming Master FSMO roles, together with the Schema Admins and Enterprise Admins groups in a separate, dedicated root domain .  I personally don't think this buys you much additional security or lowered risk.  As others have stated, the domain is not considered a true security boundary, which means that Domain Admins in child domains have the potential to take control of the forest (through known exploits).  In other words a Domain Admin in the child domain can give themselves Enterprise Admins or Schema Admins privilege (albeit with some effort).  Given this security consideration, locating those 2 FSMO roles in the root domain gives you perhaps some operational safety, but no real security.  And it comes at significant additional cost and complexity. 

    I haven't seen a greenfield deployment of the empty root + child domain model for about 5 years now.

    Tony

    Tuesday, August 24, 2010 7:06 AM
  • Tony,

    Just to be clear, if you haven't seen a greenfield deployment of the empty root + child domain in 5 years, that doesn't mean it doesn't exist. And yes, the first thing we learn about the schema of an AD forest is that it is unique per forest. So thanks for the lecture, but it was not necessary.

    ETur asked about the differences between the two setups: RD+CD with OU vs SD with OU. I gave my opinion about this. As for the costs you mention, all is about the cost of 2 DC for the RD.

    Best regards,

    P.S. *RD=root domain, CD=child domain, SD=single domain

    Tuesday, August 24, 2010 1:45 PM
  • The only thing I'd add is that yes like everyone has said the forest is the security boundary.  I'd like to share a quote from Tony's great activedir list (highly recommend everyone subscribe to that) from a few years ago

     Quote by Laura Robinson (not taking credit for Laura’s good summary)

    ****Laura's quote from activedir*****
    Your domain admins for *any* domain can already muck up your entire forest. Make no mistake about that. Domains are not security boundaries, merely replication, administration and “simple oops protection” boundaries. Therefore, using the rationale that your DAs for the other domains can’t break the entire thing right now isn’t technically true. They have to work a little harder to muck up the entire forest, but they can certainly do it

    *******end of quote *************

    I do agree with her; yes the forest takeover exploit exists but the accidental/easier elevation by a DA in the root just adding themselves to the schema or enterprise admins group is much more likely

    Right now where I am and have been we use an empty root but that is because it has always been there and a pain to consolidate just to get rid of the empty root.  If I'm starting a new design I'd go in trying to have only one domain and only expanded if there was a good reason.

    Thanks

    Mike


    http://adisfun.blogspot.com;
    Tuesday, August 24, 2010 2:39 PM
  • And to continue with the differences between the PlaceHolder Domain model forest and the single domain in forest :

    - the activation of a DHCP server in the forest needs the rights of EA. So, no administrator from the child domain has the power to activate a DHCP server without the knowledge of the enterprise administrator;
    - the trusts between two forests for a possible merge/migration is, again, best controlled in this model, limiting the number of persons that has the right to do this.

    ETur, I hope you have now the information you wanted to make yourself an idea about the differences between the two forest models.

    • Edited by Voldar Tuesday, August 24, 2010 3:37 PM
    Tuesday, August 24, 2010 2:51 PM
  • Mike,

    I don't have the entire article you talk about, but I think that what Laura says is about when considering multiple domains instead of OU. And I agree with her: a domain is not a security boundary! The creation of a domain is taken in consideration for administration/field related reasons, not security reasons. The discussion started about the two models presented by ETur. And you and Tony should agree that the % of "mucking up a forest" is greater in the single domain forest than in the PlaceHolder Domain forest model. I don't go for the discussion about "everything can be exploited/cracked" because yes, everything can, but one has to have a lot more experience to do that than simply adding himself to the EA group.

    In the end, everyone is responsible for his mistakes. What I am trying to do is to show the differences between the two models, as asked by ETur.

    Tuesday, August 24, 2010 3:07 PM
  • I would be the sole domain admin. The site IT teams would be delegated authority over their own OU's.

    Also, if we started creating multiple child domains, would they all start appearing the in "log on to" domain list on users computers?

    Any examples of large companies using the single domain design?

     

    Thanks again!

    Tuesday, August 24, 2010 6:06 PM
  • I would be the sole domain admin. The site IT teams would be delegated authority over their own OU's.

    Also, if we started creating multiple child domains, would they all start appearing the in "log on to" domain list on users computers?

    Any examples of large companies using the single domain design?

     

    Thanks again!


    I would not go towards creating multiple childs domains, one for each of the sites.

    In all my answers I was for ONE SUBDOMAIN in which al the sites are OUs. I already explained why I would go towards this kind of setup. I join Mike and Tony when they say that using domains as security boundaries IS NOT THE WAY TO GO. For a single company that has a centralized IT, the PlaceHolder Domain model with ONE subdomain is the best solution. Going towards multiple subdomains should be only because of field situation (slow connections, different administration etc.), but not because of "security reasons". 

    And yes, if you go the "multiple-childs" way, every sub-domain will be listed at start up. You may create different GPOs so that the default domain name at login to be set to the "sub-domain" the computer is in, but instead of one GPO you'll create 9. And so on... .

    In your place, I'd go with a counter-proposition: one root domain, ONE single sub-domain with all the sites as OU in it. There is nothing to lose but a lot to gain. And let the others to say why your counter-proposition is not better than theirs.

    Tuesday, August 24, 2010 7:54 PM
  • Mike,

    I don't have the entire article you talk about, but I think that what Laura says is about when considering multiple domains instead of OU. And I agree with her: a domain is not a security boundary! The creation of a domain is taken in consideration for administration/field related reasons, not security reasons. The discussion started about the two models presented by ETur. And you and Tony should agree that the % of "mucking up a forest" is greater in the single domain forest than in the PlaceHolder Domain forest model. I don't go for the discussion about "everything can be exploited/cracked" because yes, everything can, but one has to have a lot more experience to do that than simply adding himself to the EA group.

    In the end, everyone is responsible for his mistakes. What I am trying to do is to show the differences between the two models, as asked by ETur.

    I do agree that the chance of exploiting the EA and SA groups is greater in a single forest (if you are going to stick a bunch of people in domain admins)

     

    I think the point people are trying to make about the child domains is that in the past people would think that would be an ultimate protection/security boundary...and it is not.

     

    In the end no matter what model is chosen try to limit admins.  In this case ETur bing the sole domain admin is a a good thing.  I would consider a second admin (if you have another trusted coworker)....after all you do need days off and vacations from time to time :)

    Thanks

    Mike


    http://adisfun.blogspot.com;
    Tuesday, August 24, 2010 8:11 PM
  • ETur,

    Here is a good start for you to understand a bit more about designing AD. The chapter about the domain design is the place for you to start the reading.

    P.S. I know it is for Windows 2000 but trust me, whatever works in the design for Windows 2000, works for Windows 2003 also.

    Tuesday, August 24, 2010 8:32 PM
  • Hi Voldar

    It wasn't intended to be a lecture - just a clarification given your wording: "the schema is separate from the user domains".

    With regard to your point about "all is about the cost of 2 DC for the RD", I think this is misleading.  Aside from the initial capital costs associated with the server purchase there is a reasonably significant cost in maintaining and supporting two additional DC over the course of the lifetime of an AD implementation (some of which are 10 years old now).  Add to that the increased complexity associated with two domains (backup/recovery, trusts, group management, replication, troubleshooting) and the costs are even higher.

    I agree that there are some marginal benefits associated with empty root model, but these come with a significant price-tag.  For most organisations I suspect the costs will outweigh the perceived benefit.

    Tony

    Tuesday, August 24, 2010 9:33 PM
  • Hi Tony,

    I am talking about a configuration used in a medium to large company. I would go for a single domain forest if I would have a network of 300 computers and 500 users. But not if the company is a medium to large one and they want to acquire new companies in the future. Because yes, now we are talking about one domain admin, but we never know what the future brings. So, having more than 2 domain admins in the network, I assure you, I would rather keep the forest root domain under control, at least. From my experience, you'll get into more troubles with a forest the minut you are no longer the only one that "has the hands on it".

    To respond to your concerns about the root domain DC, they may very well be VM, so no additional costs for buying the servers or such. Yes, a backup would be good to have, but being VM you can back up the whole machine in whatever time-span limit you chose. And the fact they don't host anything but the schema and the 2 FSMO roles, you can always use a VM machine backup instead of recovering the system state. About the trusts, well, in a forest all domains are, by default, in a trust relationship, so no real problem here, either. Yes, some administration of the root domain is needed, but not that much. This is my opinion, but we may agree to disagree, don't we ?

    Tuesday, August 24, 2010 10:05 PM
  • This may be drifting wildly off-topic, but I had to respond to Voldar's thoughts on backup.  VM technology backup/restore is not supported for AD as it can cause USN rollback.

    http://technet.microsoft.com/en-us/library/dd348479(WS.10).aspx

    Alexei

    Tuesday, August 24, 2010 10:42 PM
  • Hi Alexei,

    Thanks for the link, but as per the document in the link, it is possible to restore from a VM - pages 22 to 25 - in certain conditions, of course. I was not aware of it and again, thank you !

    End of the off-topic.

    Wednesday, August 25, 2010 12:17 AM