Once you determine how many forests are needed based on the current namespace and administration needs of the organization as a whole, you next need to determine the domain structure that needs to be implemented. Whether your organization has an existing Active Directory structure or is implementing Active Directory for the first time, this means assessing the current environment and determining what changes are needed.
You will need to thoroughly document the existing infrastructure and determine what—if anything—needs to be restructured, replaced, or upgraded. You will also need to determine if it is even possible or practical to update the existing infrastructure as proposed. In some cases, you may find that current design is not ideal for updating as proposed and you may need to revise your plans.
That's all acceptable, because design is usually an iterative process in which you go from the theoretical to the practical during successive revisions. Just remember that it is difficult to change the domain namespace as well as the number of forests and domains once you've started implementing the design. Other parts of a design, such as the OU and site structure, are easier to change after implementation.
Note
For tips and techniques on naming domains and establishing a naming hierarchy, see Chapter 26. You'll also find detailed information on using DNS (Domain Name System) with Active Directory in Chapter 27.
Domains allow you to logically group objects for central management and control over replication of those objects. You use domains to partition a forest into smaller components. As part of domain design, you should consider the following:
Replication Domains set the replication boundary for the domain directory partition and for domain policy information stored in the Sysvol folder on every domain controller in the domain. Any changes made to the domain directory partition or domain policy information on one of the domain controllers is replicated automatically to the other domain controllers in the domain. Although other directory partitions, such as the schema and configuration, are replicated throughout a forest, the domain information is only replicated within a particular domain, and the more objects in the domain container, the more data that potentially needs to be replicated.
Resource access The trusts between and among domains in a forest do not by themselves grant permission to access resources. A user must be specifically given permission to access a resource in another domain. By default, an administrator of a domain can only manage resources in that domain and cannot manage resources in another domain. This means that domain boundaries are also boundaries for resource access and administration.
Policy The policies that apply to one domain are independent from those applied to other domains. This means that policies for user and computer configuration and security can be applied differently in different domains. Certain policies can be applied only at the domain level. These policies, referred to as domain security policies, include password policies, account lockout policies, and Kerberos policies, and are applied to all domain accounts.
Language For organizations in which multiple languages are used, servers within a domain should all be configured with the same language. Although English is supported by all installations, any additional language should be the same on all servers within a domain. This is a consideration for administration purposes but not a requirement.
With domain design, part of the decision involves the number of domains that are needed. You may need to implement additional domains or continue using a single domain. A single domain is the easiest to manage. It is also the ideal environment for users, because it is easier for users to locate resources in a single domain environment than in a multi-domain or multi-tree forest.
Inside Out: Moving from Windows NT
For most companies moving from Microsoft Windows NT domains, you can implement Active Directory domains with fewer domains, a process known as domain consolidation. Windows NT imposes less than ideal limits on the number of objects you can have in a domain, which forces many organizations to have multiple domains. As a result, organizations using Windows NT domains often have separate user account domains and resource domains. This is not the case with Active Directory. With Active Directory, you can have millions of objects in a single domain, so the reason for using multiple domains is not based solely on the number of objects—although the number of objects is certainly still a factor to consider from a manageability standpoint. It is important to note that when you are upgrading from Windows NT with a multiple-domain environment, you typically keep the existing domain infrastructure until after the upgrade. When you finish upgrading, you can then merge the additional domains so that there are fewer domains.
Beyond simplicity, there are several other reasons for implementing or keeping to a single domain design, such as the following:
You do not need to create additional domains to limit administrative access, delegate control, or create a hierarchical structure. In Active Directory, you can use OUs for these purposes.
You may want to make authentication and resource access easier to configure and less prone to problems. A single domain doesn't have to rely on trusts or the assignment of resource access in other domains.
You may want to make domain structure easier to manage. A single domain only has one set of domain administrators and one set of domain policy. A single domain doesn't need duplicate domain-wide infrastructure for domain controllers.
Your organization may frequently restructure its business units. It is easy to rename OUs, but very difficult to rename domains. It is easy to move accounts and resources between OUs, but much more difficult to move accounts and resources between domains.
That said, using multiple domains sometimes make sense, particularly if your organization has multiple business locations. With multiple locations, domain changes need to be replicated to all domain controllers and geographic separation is often—but not always—a key factor in deciding to use multiple domains. Primarily, this is because there is less replication traffic between domains than within domains (relatively speaking), and if business locations are geographically separated, it makes sense to limit the replication traffic between locations if possible.
The need to limit replication traffic is a key reason for using multiple domains even within a single business location. For example, a large organization with groups of users spread out over several floors of a building or in multiple buildings in a campus setting may find that the connection speed between locations isn't adequate. In this case, using multiple domains may make sense, because it will limit the scope of updates that initiate replication of changes.
Restricting access to resources and the need to enforce different sets of security policies are also reasons for using multiple domains. Using multiple domains creates boundaries for resource access and administration. It also creates boundaries for security policy. So, if you need to limit resource access or tighten security controls for both users and administrators, you will probably want to use multiple domains.
Like additional forests, multiple domains require additional administrative and infrastructure overhead. Each domain will have its own domain-level configuration, which will require server hardware and administrators to manage that hardware. Because users may be accessing, authenticating, and accessing resources across trusts, there is more complexity and there are more points of failure.
The forest root domain can be either a dedicated root or a non-dedicated root. A dedicated root, also referred to as an empty root, is used as a placeholder to start the directory. No user or group accounts are associated with it other than accounts created when the forest root is installed and accounts that are needed to manage the forest. Because no additional user or group accounts are associated with it, a dedicated root domain is not used to assign access to resources. A non-dedicated root is used as a normal part of the directory. It has user and group accounts associated with it and is used to assign access to resources.
For an organization that is going to use multiple domains anyway, using a dedicated root domain makes a lot of sense. The forest root domain contains the forest-wide administrator accounts (Enterprise Admins and Schema Admins) and the forest-wide operations masters (domain naming master and schema master). It must be available when users log on to domains other than their home domain and when users access resources in other domains.
A dedicated root domain is easier to manage than a root domain that contains accounts. It allows you to separate the root domain from the rest of the forest. The separation also helps safeguard the entire directory, which is important, as the forest root domain cannot be replaced. If the root domain is destroyed and cannot be recovered, you must recreate the entire forest.
Ideally, after you implement a domain structure, the domain names will never need to change. In the real world, however, things change. Organizations change their names, merge with other companies, are acquired, or restructure more often than we'd like. With Active Directory, you have several options for changing structure. If you find that you need to move a large number of objects from one domain to another, you can use the migration techniques discussed in Chapter 9. You can rename domains as long as the forest is running at the Windows Server 2003 functional level. Changing the domain design after implementation is difficult, however, and involves using the Domain Rename utility (Rendom.exe), which is provided on the CD-ROM that accompanies this book.
You can rename domains in the following key ways:
Rename domains to move them within a domain tree. For example, you could rename a child domain from eng.it.cohowinery.com to eng.cohowinery.com.
Rename domains so that a new tree is created. For example, you could change the name of a child domain from vineyard.cohowinery.com to cohovineyard.com.
Rename domains to move them to a new tree. For example, you could change the name of a child domain from it.cohowinery.com to it.cohovineyard.com.
Rename domains to set new domain names without changing the parent-child structure. For example, if the company name changes from Coho Vineyard to Coho Winery, you could change the existing domain names to use cohowinery.com instead of cohovineyard.com.
You cannot use the Domain Rename utility to change which domain is the forest root domain. Although you can change the name of the forest root domain so that it is no longer the forest root logically, the domain will remain the forest root domain physically in Active Directory. It will still contain the forest-wide administrator accounts (Enterprise Admins and Schema Admins) and the forest-wide operations masters (domain naming master and schema master). This occurs because there is no way to change the forest root domain assignment within Active Directory once the forest root has been established.
You cannot use Domain Rename to make changes to a domain in which Microsoft Exchange 2000 is deployed. Exchange 2000 does not have its own directory service functionality. It uses Active Directory for this purpose.
On the CD-ROM that accompanies this book, you'll find a step-by-step guide for implementing Domain Rename. As you might imagine, renaming a domain in a single-domain forest is the easiest renaming operation. As you increase the number of domains within a forest, you increase the complexity of the Domain Rename operation. Regardless of how many domains you are working with, you should always plan the project completely from start to finish and back up the entire domain infrastructure before trying to implement Domain Rename.
The reason for this planning and backup is that when you rename domains, even if you rename only one domain in a forest of many domains, you will need to make a change to every domain controller in the forest so that it recognizes the renamed domain. When you are finished, you will need to reboot each domain controller. If you don't perform the rename change on every domain controller, you will need to remove from service the domain controllers that did not get the updates. Furthermore, from the time you start the rename operation to the time you reboot domain controllers, the forest will be out of service.
To complete the process after renaming a domain and updating domain controllers, each workstation or member server in the renamed domain will need to be rebooted twice. Any computers running Windows NT 4 in the renamed domain will need to be unjoined from the domain and then rejoined to the domain. While you are working with domain controllers and other computers that don't use Dynamic Host Configuration Protocol (DHCP) in the renamed domain, you should rename the computer so the DNS name is correct and make other DNS name changes as appropriate.