Active Directory Hierarchies
Now that you understand the building blocks of Active Directory, you can start to understand how to build a hierarchy in Active Directory. One of the foundations of design for AD has been a flexibility to allow companies to build a structure which fits into their organization. This flexibility allows organizations of all sizes to use Active Directory to meet their needs.
Domains and OUs
The most basic design of an Active Directory is a single forest, single domain, no Organizational Unit design.
Basic AD Installation
For a small organization, this might be adequate, but almost every organization can benefit from some structure.
Creating multiple domains is not always the best design solution, so Microsoft created organizational units in Active Directory which can be nested to provide hierarchical control of your AD environment. It is a great idea to think about and map out your OU design before committing it into Active Directory.
Typically, companies design their OU trees based on either geographic separation (e.g. Americas, EMEA, PacificRim) or based on organizational design (e.g. Accounting, Marketing, Technology, Sales). There is no incorrect way to design your AD environment, however, consistency should be key. You shouldn’t mix the two design methods and have a top level Americas OU and a top level Sales OU. Doing so makes administration difficult as you won’t know where a particular salesperson’s account is.
Also, remember that OUs allow enterprise administrators to delegate administration responsibility to local teams. Building an effective OU design will allow you to properly delegate authority.
The other reason OUs are used is to apply policies. Policies are rules for security, access, and functionality which can apply to several different containers in Active Directory. Frequently, policies are applied by OU – so though you might separated geographically (and therefore want to set up your structure based solely on geography), it might make more sense to setup your AD by organizational divisions. Why? Because if all of your marketing employees need the same software and settings, you will setup policies based on the department instead of the physical location of the employees.
Domain Trees
Once an organization becomes large and you cannot have the entire AD database replicated everywhere, it might make sense to move to a domain tree. A domain tree allows an organization to become more decentralized as it is more independent than using an OU tree.
Domain-wide policies can be changed per domain in a domain tree which is not possible with only an OU structure. Policies such as minimum and maximum password age, minimum password length, and account lockout are domain-wide policies and cannot be changed on a per-OU basis. By creating multiple domains, administrators can set these policies for each domain.
Domain Tree
In the illustration above, learnthat.com has a domain tree in the Active Directory domain.
Forest of Domain Trees
In more complex environments, a company may use multiple domain trees in a single forest. This might be a large operating company with multiple subsidiaries – each requiring their own domain, for example, ThatNetwork.com is the parent company and subsidiaries might include Learnthat.com, Romancetips.com, Exampractice.com. This structure makes sense if you have different administrative staff for each domain, along with different policies and different security requirements.
You can still setup trusts between the domains to allow users to authenticate for resources in either domain.
Multiple Forests
The last possibility is using multiple forests. This is the less frequent design choice, but can be used with you want an absolute separation for one reason or another. This structure is most often found when companies merge or in the case of acquisitions. In Windows 2003, you can setup forest trusts between forests to allow some access.
