An entire AD namespace is called a forest or tree
The Active Directory namespace consists of multiple naming contexts that are tied to a DNS zone.
When you first create an Active Directory domain, you must pick a DNS zone for its name. This Active Directory domain is the root domain of what Microsoft calls a tree or domain tree. A single tree can also be called a forest (a forest contains one or more trees). DNS zones subordinate to the DNS zone of the root domain can become subordinate Active Directory domains in a tree. The root domain is not the same as the DNS root domain introduced in Chapter 2. A root domain is simply the first Windows domain in a tree. The first domain in a forest is called the forest root domain.
Figure 7-1 shows a tree with a root domain and two child domains. A triangle represents a domain.
Figure 7-1. Active Directory domain tree
Noncontiguous DNS zones can participate in the same forest
Active Directory also supports noncontiguous DNS zones. Each noncontiguous DNS zone would be a separate tree. These multiple trees can be connected in a single directory namespace (the forest).
Each tree holds a contiguous DNS zone in which each Windows child domain is a DNS child domain of the Windows domain immediately above it. Figure 7-2 shows a forest with two noncontiguous domain trees.
Figure 7-2. Active Directory forest with two domain trees
Multiple domain controllers host a single domain partition, and changes are replicated via a delta-only system
Each domain consists of an independent domain directory that is hosted by directory servers called domain controllers. A domain can have as many domain controllers as desired. Each domain
controller replicates the domain partition to the other controllers for that domain. Client computers can join the domain by accepting it as their primary source of authentication and authorization.
These client computers are also loosely considered part of the domain, because by default they share the same security context. As a result, other security principals that reside in that domain
partition may have some level of access to those client computers by default. From a directory standpoint, each of the client computers that joins the domain has an entry that represents it in the domain partition.
A forest has properties that are consistent across all the domain directories. For example, there can be only one schema in a forest, and it is replicated across all domain controllers. Additionally, configuration information for each of the pieces of Active Directory is replicated across all the domain controllers.
Figure 7-3 shows the logical directory namespace of the forest pictured in Figure 7-2 and how each domain relates to the partitions and overall directory namespace. Each partition is pictured as an ellipse with a tree structure to simulate the entries within that partition. Each of the partitions of this logical structure does not correspond to a single physical location. Figures 7-4 and 7-5 will illustrate how the namespace is distributed on the domain controllers.
Figure 7-3. Active Directory forest namespace
Figure 7-4. Domains distributed across sites
Figure 7-5. Active Directory naming contexts
Sites
Sites allow distribution of the directory with respect to physical connectivity issues
Sites are how Active Directory addresses connectivity and bandwidth issues that might affect the operations of the directory. A site is a network with adequate connectivity and bandwidth, as arbitrarily decided by an administrator. The site architecture has no dependencies on the directory hierarchy, and it is external to LDAP namespace design. However, site configuration information is stored in the directory, and it is a factor in determining both replication flow and which directory server any particular client uses. Every computer that participates in AD, including the domain controllers, knows the site to which it belongs. This information in turn affects the client-server interaction; the client automatically prefers to interact with domain controllers in its own site.
Sites and domains can overlap with no restrictions
The administrator can create multiple sites, which are independent of the directory namespace I just described. For example, a domain might have multiple sites, with a domain controller in each site to provide localized service to clients. In Figure 7-4, the root domain illustrates this
configuration (DC stands for domain controller). Alternatively, a site might contain multiple domains so controllers for different domains can provide services to clients from each domain in that site. In Figure 7-4, the Mycompany Main Site demonstrates this configuration.
Replication is scheduled between sites
Domain controllers from the same domain in separate sites replicate the domain partition via a site bridge, according to the schedule and topology in the configuration partition. The configuration partition is conveniently stored local to each domain controller. Root domain controllers replicate the configuration and schema partitions between themselves and all other domain controllers using the site bridge when necessary. When a new domain controller is initially installed, it must be able to receive the existing configuration and schema partitions over the network. If this domain controller is across a low-bandwidth link, this requirement can be extraordinarily painful. Many companies circumvent this problem by building the new domain controller locally and shipping it to the remote site. Microsoft plans to fix this problem with .NET Server 2003 so the initial replication can be done via media.
Sites help maximize the efficiency of network traffic because of to client-server directory interactions Sites provide useful functionality in controlling network traffic across WAN links. Clients can simply interact with domain controllers that are local, and domain controllers can replicate at times scheduled to be least disruptive. This type of functionality is uncommon among LDAP server products, and it is one of the many significant benefits in choosing Active Directory.
Naming Contexts and Partitions
Every domain controller holds exactly three partitions
Each domain directory holds three naming contexts, each of which is a replicated partition. One partition is the domain naming context. The domain naming context is where most of the action takes place. Most of the entries that clients need to interact with are held in this naming context.
The domain naming context is replicated only to the domain controllers of that domain. Another partition is the configuration naming context, which is replicated to all the domain controllers in a forest. This context holds all the configuration information for Active Directory. The definitions of Active Directory architecture, replication schedules, and replication topology are held here. Finally, there is the schema naming context, which holds the schema definitions for Active Directory. The schema naming context is subordinate to the configuration naming context, but it has been implemented as a separate namespace. The schema partition is replicated to all the domain controllers in a forest. The following sections explore the purpose of each of the naming contexts;
for the details of replication, see the section Replication later in the chapter.