Active Directory Domain Design Principles
This blog entry was written on July 2006. Since much of it is still relevant in today’s Windows Server 2008 R2 Active Directory, I took the liberty of reviewing and reposting it in my new techblog. – Jay Paloma
Ater you finalize the Forest Design, it’s now time to consider how the Domains will look like in Active Directory.
The key to domain design is to start with a single domain, then justify the need for an additional domain. Domain design principles in Windows NT 4.0 and earlier are already irrelevant as far as the Active Directory is concerned, so don’t be tempted to create a new domain for each business unit or branch office that the company has, or for each set of administrator that the company has.
So, what are the reasons to create additional domains? It is my personal recommendation, as well as Microsoft documentation, that each additional domain should have one or more of these conditions:
When business units have different domain-wide security policies. An example of a domain-wide security policy is password length. If a certain group of users wish to have a minimum password length of 8 characters, while another group of users prefer 4 characters, then it leaves us no choice but to create a domain for these two groups of users. Other domain-wide policies include password complexity, account lockout and Kerberos ticket lifetime. (NOTE: Password policies are no longer bound within the domain -jp 18 jan 2017)
When different locations cannot support bandwidth for Domain Partition Replication. In this scenario, we need to isolate the domain partition for each LAN location by creating a domain for each location. The domain partition is one of three partitions (the others are the Schema and the Configuration partitions) containing user credential information, among others. Although Active Directory replication uses IP or SMTP to transfer data from one domain controller to another, the Domain Partition is always replicated via RPC and is encrypted for security (it replicates usernames and passwords, that’s why). What is needed is not necessarily bandwidth, but more on availability. Therefore, if two locations have intermittent WAN link downtime, create a different domain for the remote location.
When doing an in-place upgrade of a Windows NT multiple domain environment. An in-place upgrade may result in the creation of a new domain, and this domain may not qualify in the conditions to create a domain mentioned above. If this were so, after doing the in-place upgrade, consider consolidating the domains if the benefits outweigh the risks in the consolidation process.
The reasons NOT to create new domains are as follows:
Administrative considerations. If each business unit has its own domain and its own set of administrators, the solution in Active Directory is not to create an additional domain, but to create Organizational Units for each business unit and delegate administrative control over those business units to the appropriate personnel.
Windows NT Object Limit. In Windows NT, the maximum number of objects for each domain is 40,000. This is no longer true in Active Directory. The practical limit of the Active Directory database is the hard disk size. To put it in another way, given the proper hardware, it is possible to create a user account for all Filipinos in a single domain, and the domain controllers can still do their jobs properly as what’s expected from domain controllers.
Primary Domain Controller (PDC) Availability. In Windows NT 4.0 and below, there is only one writeable copy of the domain database, and that’s in the Primary Domain Controller. If a domain were to have to or more sets of administrators making changes to the domain database from two locations, it is better in Windows NT to separate these two sets of administrators in two domains to make a PDC more available near their location. In Active Directory, the concept of Primary Domain Controller no longer exists. All domain controllers have a writeable copy of the domain database already. That’s why in the above scenario, the domain database will be written on the domain controller(s) nearest to the administrators.
Namespace requirements. It is not a correct practice attempting to reflect the organizational hierarchy in Active Directory domain names, and thereby in the Active Directory domain structure itself. If it is really a must to reflect the hierarchy of the company in the directory structure, the Organizational Units are more appropriate for the job. Even Microsoft Exchange email domain names are not to be reflected in the domain hierarchy, because such is the responsibility of the Recipient Update Services or RUS.
In a multiple domain scenario, you may want to consider the domain naming hierarchy. Here is where Active Directory Domain Trees come in. A Tree is simply a group of domains sharing a contiguous namespace. If the top of the tree is called mycompany.local, and its child domains are manila.mycompany.local and subic.mycompany.local, then these three domains form an Active Directory Tree. It is important to note that having mycompany.local as the parent domain of subic and manila subdomains does not empower its administrator to administer its child domains.
Creating additional domains joins these domains into a two-way, transitive trust relationship with the other. This trust relationship cannot be altered or removed. It’s simply there. The trust relationship is transitive, meaning if A trusts B and B trusts C, A has an implied trust relationship with C.
After considering the single domain, multiple domain, and in a multiple domain scenario, how these domains are to be organized, it’s time to consider how we’ll organize object within a domain. That will be the role of the Organizational Unit (OU), and that’s discussed in the next section.