none
Active Directory Design ... Multiple Domains or Organizational Units RRS feed

  • Question

  • I've been trying to find some Best Practices on whether to have multiple domains or just use a single domain with multiple organizational units.  We have three locations each having their own separate domain right now.  We want to consolidate our Domains into one Forest under our primary site.  We've thought of making the smaller domains a part of our primary forest so we could manage the other domains at the enterprise level when needed (our remote systems administrators currently manage their smaller domains which causes us some management issues).  We are only talking about 100 to 125 servers across the enterprise and about 400 workstations...our primary location has about 400 users while the other locations have less than a dozen users.

    We've also thougth of just expanding our domain to cover all locations and just create organizational units for each of the remote locations rather than having multiple domains.  Seems like this would be easier to manage than having multiple domains.

    We'd like to find some best practices and case studies on this but have been coming up pretty empty so far.  Any help or pointing in the right direction would be appreciated!  Thanks.

    • Changed type Bruce-Liu Friday, August 5, 2011 7:49 AM
    Wednesday, July 27, 2011 8:10 PM

Answers

  • Hi doc,

    You've received some excellent suggestions, which I agree with all of them. Just to add, with the number of users in the organization, and based on your description that you have a centralized corporate location which appears to reflect a centralized IT department, with small satellite lcoations, there is no bonafide reason to have multiple domains. I've worked with some medium sized organizations (up to 5000 users) with multiple sites (local and global) that have a single domain design and control the whole infrastructure. The AD design is an OU by location design with specific IT folks at each location that have full control of their respective OU. They can do anything within that OU with user accounts, machines, servers (if we allow them by putting the servers in that OU) they want. Matter of fact (can I say this?) each branch of the US military is a single domain, with each base an OU, with an OU admin that is the IT manager at the base with full control in their specific OU. I can't say how many users are in each branch or in the single domain (first I don't know, second I wouldn't be able to reveal it if I did), but the design works fine. So it's not a user based limit, rather an administrative decision to design it this way. Theoretically, an AD forest (one domain or multiples) will handle approx 4.3 billion objects (users, computes, groups, etc).

    As for the OU structure, well first, you will want to remove the domain admin rights from everyone except at your IT corp staff, and design a location based OU structure, then function (departments), then provide the local IT manager or someone already taking care of the tasks at that location with FC of the OU (delegate the OU). THis will also aid in controlling GPOs per location, as well as software distribution, etc. Here's one example OU structure:

    For example, for a company with more than one location/site, I would suggest the following:

    Domain
    .....Philly OU
    ..............Accounting
    ..............Sales
    ..............Marketing
    ..............Desktop
    ..............Users
    ..............Laptops
    .....Seattle OU
    ..............Accounting
    ..............Sales
    ..............Marketing
    ..............Desktops
    ..............Users
    ..............Laptops

    I separated Laptops and Desktops because I have two different Windows Update
    GPOs set. The Desktop Windows Update GPO I created runs at 3:00 AM, whereas
    the Laptop Updates run at 3:30 PM while the users have the laptops in the
    office. This design also allows me to create GPOs for the different offices,
    or I can create one and link them to both offices. The design possibilities
    are endless, especially if you control flow with Block Inheritance,
    Loopback, WMI filtering, disabling the Computer or User portion of a GPO,
    etc, however in many cases I do not use these features because trying to
    support them 8 months later when there's a problem it is difficult to
    remember what you had blocked, etc. Yes youcan use RSOP to look at what is
    being applied, etc, but I find it easier to simply create another OU or a
    child OU to have a different setting than the parent, such as the following,
    where I created a GPO to lock the desktop with two different time settings.
    The Desktops OU has a 30 minute setting, but I created a 15 Minute Timeout
    OU directly beneath it. Because the identical setting isdifferent on the
    child, it overrides the parent's setting. I can simply "look" at my OUs and
    know what I have applied.

    .....Seattle OU
    ..............Accounting
    ..............Sales
    ..............Marketing
    ..............Desktops
    ....................15 Minute Timeout OU
    ..............Users
    ..............Laptops

    These are just suggestions, and you may find that it may work for you, or
    not. Even in a single site, I still do it this way, because it is flexible.
    You never know when the customer or your company may expand. If they do,
    simply create another OU for the new location.

     

     

    Ace

     


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    • Marked as answer by Bruce-Liu Friday, August 5, 2011 7:52 AM
    Thursday, July 28, 2011 4:02 AM
  • >>> We'd like to find some best practices and case studies on this but have been coming up pretty empty so far. 

    You can see get some good information from IPD guide - http://technet.microsoft.com/en-us/solutionaccelerators/ee395428   Look for Active Directory Domain Service guide.

    Anyway, here are some generic recommendations:

    A best practice is to start with a single forest and let business requirements justify any additional forests. The following requirements will dictate a design with multiple forests:

    Multiple schemas. Everything in the forest shares a common schema. Conflicts between applications or administration of the schema can introduce the need for an additional forest.

    Resource forests. Some organizations may require multiple forests for isolation reasons, but need to share a common resource, for example Microsoft Exchange Server. A separate forest can be created to host the shared resources, and forest-level trusts can be used to provide the authentication and authorization paths.

    Forest administrator distrust. Some organizations have an internal structure that includes more than one IT team. When each IT team wants to control the forest while denying the other IT staff control, implementing multiple forests are means to that end. This is a common scenario when companies merge, in government agencies, and at universities.

    Legal regulations or geo-political reasons for application and/or data access. All domains in a single forest have automatic, two-way Kerberos trusts so that data and applications can be accessed easily. When working with some countries or regions, legal requirements may dictate the separation of data and applications. Multiple forests provide this separation


    Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+ Houston, TX

    Blogs - http://blogs.sivarajan.com/
    Articles - http://www.sivarajan.com/publications.html
    Twitter: @santhosh_sivara - http://twitter.com/santhosh_sivara
    This posting is provided AS IS with no warranties,and confers no rights.
    • Marked as answer by Bruce-Liu Friday, August 5, 2011 7:52 AM
    Wednesday, July 27, 2011 8:41 PM
    Moderator

All replies

  • The rule of thumb is this simple...  always design an AD infrastructure to consist of a single domain model, then find reasons why this model wont work for you!  Based on your description, I do not see any reason why the single domain model wont work.  Generally, the single domain model meets all requirements other than having more than one password policy requirement.  Even with that, 2008 introduced Fine Grained Password POlicies, so its difficult to find good reasons not to deploy a single domain model.

    Other reasons my include data, administration, replication isolation.  Doesnt sound like this applied to your scenario.

     


    anITKB Visit anITKB.com, an IT Knowledge Base.
    facebook Follow me on Facebook.
    Wednesday, July 27, 2011 8:30 PM
  • Hello,

    if you don't have specific security requirements to separate with forests then use OUs to manage different locations, that's recommended and best practice. That way you can work with less domain admins as on OUs you can use delegation to give experienced users some more permissions.

    Multiple child domains will provide a different password/account lockout policy which may be useful with Windows server 2003, with higher OS version and functional level you can also use fine grained password policies.


    Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.
    Wednesday, July 27, 2011 8:35 PM
  • >>> We'd like to find some best practices and case studies on this but have been coming up pretty empty so far. 

    You can see get some good information from IPD guide - http://technet.microsoft.com/en-us/solutionaccelerators/ee395428   Look for Active Directory Domain Service guide.

    Anyway, here are some generic recommendations:

    A best practice is to start with a single forest and let business requirements justify any additional forests. The following requirements will dictate a design with multiple forests:

    Multiple schemas. Everything in the forest shares a common schema. Conflicts between applications or administration of the schema can introduce the need for an additional forest.

    Resource forests. Some organizations may require multiple forests for isolation reasons, but need to share a common resource, for example Microsoft Exchange Server. A separate forest can be created to host the shared resources, and forest-level trusts can be used to provide the authentication and authorization paths.

    Forest administrator distrust. Some organizations have an internal structure that includes more than one IT team. When each IT team wants to control the forest while denying the other IT staff control, implementing multiple forests are means to that end. This is a common scenario when companies merge, in government agencies, and at universities.

    Legal regulations or geo-political reasons for application and/or data access. All domains in a single forest have automatic, two-way Kerberos trusts so that data and applications can be accessed easily. When working with some countries or regions, legal requirements may dictate the separation of data and applications. Multiple forests provide this separation


    Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+ Houston, TX

    Blogs - http://blogs.sivarajan.com/
    Articles - http://www.sivarajan.com/publications.html
    Twitter: @santhosh_sivara - http://twitter.com/santhosh_sivara
    This posting is provided AS IS with no warranties,and confers no rights.
    • Marked as answer by Bruce-Liu Friday, August 5, 2011 7:52 AM
    Wednesday, July 27, 2011 8:41 PM
    Moderator
  • Hi doc,

    You've received some excellent suggestions, which I agree with all of them. Just to add, with the number of users in the organization, and based on your description that you have a centralized corporate location which appears to reflect a centralized IT department, with small satellite lcoations, there is no bonafide reason to have multiple domains. I've worked with some medium sized organizations (up to 5000 users) with multiple sites (local and global) that have a single domain design and control the whole infrastructure. The AD design is an OU by location design with specific IT folks at each location that have full control of their respective OU. They can do anything within that OU with user accounts, machines, servers (if we allow them by putting the servers in that OU) they want. Matter of fact (can I say this?) each branch of the US military is a single domain, with each base an OU, with an OU admin that is the IT manager at the base with full control in their specific OU. I can't say how many users are in each branch or in the single domain (first I don't know, second I wouldn't be able to reveal it if I did), but the design works fine. So it's not a user based limit, rather an administrative decision to design it this way. Theoretically, an AD forest (one domain or multiples) will handle approx 4.3 billion objects (users, computes, groups, etc).

    As for the OU structure, well first, you will want to remove the domain admin rights from everyone except at your IT corp staff, and design a location based OU structure, then function (departments), then provide the local IT manager or someone already taking care of the tasks at that location with FC of the OU (delegate the OU). THis will also aid in controlling GPOs per location, as well as software distribution, etc. Here's one example OU structure:

    For example, for a company with more than one location/site, I would suggest the following:

    Domain
    .....Philly OU
    ..............Accounting
    ..............Sales
    ..............Marketing
    ..............Desktop
    ..............Users
    ..............Laptops
    .....Seattle OU
    ..............Accounting
    ..............Sales
    ..............Marketing
    ..............Desktops
    ..............Users
    ..............Laptops

    I separated Laptops and Desktops because I have two different Windows Update
    GPOs set. The Desktop Windows Update GPO I created runs at 3:00 AM, whereas
    the Laptop Updates run at 3:30 PM while the users have the laptops in the
    office. This design also allows me to create GPOs for the different offices,
    or I can create one and link them to both offices. The design possibilities
    are endless, especially if you control flow with Block Inheritance,
    Loopback, WMI filtering, disabling the Computer or User portion of a GPO,
    etc, however in many cases I do not use these features because trying to
    support them 8 months later when there's a problem it is difficult to
    remember what you had blocked, etc. Yes youcan use RSOP to look at what is
    being applied, etc, but I find it easier to simply create another OU or a
    child OU to have a different setting than the parent, such as the following,
    where I created a GPO to lock the desktop with two different time settings.
    The Desktops OU has a 30 minute setting, but I created a 15 Minute Timeout
    OU directly beneath it. Because the identical setting isdifferent on the
    child, it overrides the parent's setting. I can simply "look" at my OUs and
    know what I have applied.

    .....Seattle OU
    ..............Accounting
    ..............Sales
    ..............Marketing
    ..............Desktops
    ....................15 Minute Timeout OU
    ..............Users
    ..............Laptops

    These are just suggestions, and you may find that it may work for you, or
    not. Even in a single site, I still do it this way, because it is flexible.
    You never know when the customer or your company may expand. If they do,
    simply create another OU for the new location.

     

     

    Ace

     


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    • Marked as answer by Bruce-Liu Friday, August 5, 2011 7:52 AM
    Thursday, July 28, 2011 4:02 AM
  • Its been old practice for implementing multiple forest/domain structure. Today, you can achieve almost everything with single forest/domain, but the requirement might differ like production & development forest/domain should be different because it might require schema extension for the development team but its not viable for production environment due to common schema in multiple domain in one forest. 

    Using OU, you can segregate users/computers & the seats specified by you doesn't prove anyway there is requirement for multiple forest/domain. Below link might help you with some design idea.

    http://www.microsoft.com/download/en/details.aspx?id=8133

    http://www.microsoft.com/download/en/details.aspx?id=732

     

    Regards  


    Awinish Vishwakarma

    MVP-Directory Services

    MY BLOG:  awinish.wordpress.com

    This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    Thursday, July 28, 2011 9:01 AM
    Moderator
  • Hi Santhosh,

    We are planning to deploy multiple domains for our entities. Is there any documents available for the Windows Server 2012. 

    Awaiting for your support.

    Thanks,

    Raja


    Rgrds, Muthu.G / Uganda.

    Monday, June 6, 2016 10:38 AM
  • This is an old thread. However, the basic concept mentioned in the IPD guides are still valid for Windows Server 2012.  

    Santhosh Sivarajan | Houston, TX | www.sivarajan.com
    ITIL,MCITP,MCTS,MCSE (W2K3/W2K/NT4),MCSA(W2K3/W2K/MSG),Network+,CCNA

    My Books: | Windows Server Security | Windows Server 2012

    Blogs | Twitter | LinkedIn | Facebook|

    This posting is provided AS IS with no warranties, and confers no rights.

    Monday, June 6, 2016 6:02 PM
    Moderator