UNDERSTANDING FORESTS AND DOMAINS

UNDERSTANDING DOMAINS AND FORESTS

What Are Domains and Forests?

The Active Directory directory service is a distributed database that stores and manages information about network resources, as well as application-specific data from directory-enabled applications. Active Directory allows administrators to organize objects of a network (such as users, computers, and devices) into a hierarchical collection of containers known as the logical structure. The top-level logical container in this hierarchy is the forest. Within a forest are domain containers, and within domains are organizational units.

Understanding domains and forests requires understanding the possible relationships they might have in Active Directory. The relationships between these logical containers might be based on administrative requirements, such as delegation of authority, or they might be defined by operational requirements, such as the need to provide for data isolation. Service administrators can use domain and forest containers to meet a number of specific requirements, including:

• Implementing an authentication and authorization strategy for sharing resources across a network 
• Providing a mechanism for centralizing management of multiple domains and forests
• Providing an information repository and services to make information available to users and applications
• Organizing objects of a network (such as users, computers, devices, resources, and application specific data from directory-enabled applications) into a non-physical hierarchical structure

To learn more about domains and forests, you must first understand the logical and physical structures of Active Directory. This section describes how those structures differ, and defines domains and forests in terms of the logical structure.

The Logical Structure of Active Directory

Active Directory stores network object information and implements the services that make this information available and usable to users. Active Directory presents this information through a standardized, logical structure that helps you establish and understand the organization of domains and domain resources in a useful way. This presentation of object information is referred to as the logical structure because it is independent of the physical aspects of the Active Directory infrastructure, such as the domain controllers required for each domain in the network.

Benefits of the Logical Structure

The logical structure provides a number of benefits for deploying, managing, and securing network services and resources. These benefits include:

• Increased network security. The logical structure can provide security measures such as autonomy for individual groups or complete isolation of specific resources.
• Simplified network management. The hierarchical nature of the logical structure simplifies configuration, control, and administration of the network, including managing user and group accounts and all network resources. 
• Simplified resource sharing. The logical structure of domains and forests and the relationships established between them can simplify the sharing of resources across an organization.
• Low total cost of ownership. The reduced administration costs for network management and the reduced load on network resources that can be achieved with the Active Directory logical structure can significantly lower the total cost of ownership. 

An efficient Active Directory logical structure also facilitates the system integration of features such as Group Policy, enabling desktop lockdown, software distribution, and administration of users, groups, workstations, and servers. In addition, the logical structure can facilitate the integration of services such as Exchange 2000, public key infrastructure (PKI), and domain-based distributed file system (DFS).

Components of the Logical Structure

The logical structure consists of leaf object and container object components that must conform to the hierarchical structure of an Active Directory forest. Leaf objects are objects that have no child objects, and are the most basic component of the logical structure. Container objects store other objects and occupy a specific level within the forest hierarchy.

The relationships among the components of the logical structure control access to stored data and determine how that data is managed across one or more domains within a single forest. The components that make up the Active Directory logical structure are described in the following table.

Components of the Active Directory Logical Structure

 

Component	Description
Organizational Units	Organizational units are container objects. You use these container objects to arrange other objects in a manner that supports your administrative purposes. By arranging objects in organizational units, you make it easier to locate and manage them. You can also delegate the authority to manage an organizational unit. Organizational units can be nested in other organizational units. You can arrange objects that have similar administrative and security requirements into organizational units. Organizational units provide multiple levels of administrative authority, so that you can apply Group Policy settings and delegate administrative control. This delegation simplifies the task of managing these objects and enables you to structure Active Directory to fit your organization’s requirements.
Domains	Domains are container objects. Domains are a collection of administratively defined objects that share a common directory database, security policies, and trust relationships with other domains. In this way, each domain is an administrative boundary for objects. A single domain can span multiple physical locations or sites and can contain millions of objects.
Domain Trees	Domain trees are collections of domains that are grouped together in hierarchical structures. When you add a domain to a tree, it becomes a child of the tree root domain. The domain to which a child domain is attached is called the parent domain. A child domain might in turn have its own child domain. The name of a child domain is combined with the name of its parent domain to form its own unique Domain Name System (DNS) name such as Corp.nwtraders.msft. In this manner, a tree has a contiguous namespace.
Forests	A forest is a complete instance of Active Directory. Each forest acts as a top-level container in that it houses all domain containers for that particular Active Directory instance. A forest can contain one or more domain container objects, all of which share a common logical structure, global catalog, directory schema, and directory configuration, as well as automatic two-way transitive trust relationships. The first domain in the forest is called the forest root domain. The name of that domain refers to the forest, such as Nwtraders.msft. By default, information in Active Directory is shared only within the forest. In this way, the forest is a security boundary for the information that is contained in that instance of Active Directory.
Site Objects	Sites are leaf and container objects. The sites container is the topmost object in the hierarchy of objects that are used to manage and implement Active Directory replication. The sites container stores the hierarchy of objects that are used by the Knowledge Consistency Checker (KCC) to effect the replication topology. Some of the objects located in the sites container include NTDS Site Settings objects, subnet objects, connection objects, server objects, and site objects (one site object for each site in the forest). The hierarchy is displayed as the contents of the Sites container, which is a child of the Configuration container.

By understanding the purpose and hierarchical structure of these components, you can complete a variety of tasks, including installing, configuring, managing, and troubleshooting Active Directory. Although the logical structure of Active Directory is a hierarchical organization of all users, computers, and other physical resources, the forest and domain form the basis of the logical structure.

Forests, which are the security boundaries of the logical structure, can be structured to provide data and service autonomy and isolation in an organization in ways that can both reflect site and group identities and remove dependencies on the physical topology. Domains can be structured within a forest to provide data and service autonomy (but not isolation) and to optimize replication with a given region.

This separation of logical and physical structures improves manageability and reduces administrative costs because the logical structure is not impacted by changes in the physical structure, such as the addition, removal, or reorganization of users and groups.

Note

• You can view and manage components of the logical structure by using the Active Directory Users and Computers, Active Directory Domains and Trusts, and Active Directory Schema Microsoft Management Console (MMC) snap-ins, and other tools.

The Physical Structure of Active Directory

The physical structure of Active Directory is represented by a set of physical components which, when configured correctly, can help optimize the transmission of network replication and authentication in ways specifically tailored to fit your physical network. Physical network components, such as domain controllers and physical subnets, are used to facilitate network communication and to set physical boundaries around network resources. More specifically, the physical structure of Active Directory represents all of the physical subnets in your enterprise network, the domain controllers in those physical subnets (commonly referred to as Sites in Active Directory) and the replication connections between the domain controllers.

Sites and subnets are represented in Active Directory by site and subnet objects. Computers on TCP/IP networks are assigned to site objects based on their location in a physical subnet or a set of physical subnets. Physical subnets group computers in a way that identifies their physical proximity on the network. Each site object is associated with one or more subnet objects. Subnet objects are used during the process of domain controller location to find a domain controller in the same site as the computer that is logging on. This information also is used during Active Directory replication to determine the best routes between domain controllers. This enables you to use network bandwidth more efficiently. For example, it ensures that when users log on to the network they are authenticated by the authentication authority nearest to the user, thus reducing the amount of network traffic.

The physical domain controller contains the directory partitions that are replicated. Although the logical and physical structures are defined and configured independently, they have interdependencies that affect replication.

 

What Are Domains?

Domains are logical directory components that you create to manage the administrative requirements of your organization. The logical structure is based on the administrative requirements of an organization, such as the delegation of administrative authority, and operational requirements, such as the need to control replication. In general, domains are used to control where in the forest replication of domain data occurs and organizational units are used to further organize network objects into a logical hierarchy and delegate control to appropriate administrative support personnel.

A domain is a partition in an Active Directory forest. Partitioning data enables organizations to replicate data only to where it is needed. In this way, the directory can scale globally over a network that has limited available bandwidth. Domains can also be defined as:

• Containers within a forest
• Units of Policy
• Units of Replication
• Authentication and Authorization Boundaries
• Units of Trust

Each domain has a domain administrators group. Domain administrators have full control over every object in the domain. These administrative rights are valid within the domain only and do not propagate to other domains.

 

Domains as Containers Within a Forest

Within the scope of a forest, a domain is a container. Objects in that container inherently trust each other and the security services located in that same container. Each time you create a new domain container in a forest, a two-way, transitive trust relationship is automatically created between the new domain and its parent domain. Trusts are logical relationships established between domains to allow pass-through authentication in which a trusting domain honors the logon authentications of a trusted domain. Because all domain containers within a forest are joined together by two-way transitive trusts, objects within one domain container also inherently trust all other objects and security services located in every domain container located in that forest.

Domain containers are used to store and manage Active Directory objects, some of which have a physical representation. All of the objects within the domain container are stored in a central database that stores only objects created within that domain. Some objects represent people or groups of people, while others represent computers or network servers. Examples of Active Directory objects that have a physical representation are user, computer, and group objects.

While domains contain objects that represent physical things, they also contain objects that are used to help self-regulate domain operations such as trusted domain objects (TDOs) and site link objects. Domain containers can also hold subordinate containers such as organizational units. The following figure shows where objects are stored within the logical structure of a domain.

Domain Containment Structure Within a Forest

Organizational Units and Objects

Organizational units are used to group objects, including accounts and resources in a domain, for administrative purposes, such as the application of Group Policy or delegation of authority. Control over an organizational unit, including the objects within it, is determined by the access control lists (ACLs) on the organizational unit and on the objects in the organizational unit.

Organizational Units

The organizational unit is a particularly useful type of directory object contained within domains. Each organizational unit is an Active Directory container within a domain into which users, groups, computers, and other organizational units of the domain can be placed. An organizational unit cannot contain objects from other domains.

An organizational unit is the smallest scope or unit to which Group Policy settings can be assigned or to which administrative authority can be delegated. A hierarchy of organizational units can be extended as necessary to model the hierarchy of an organization within a domain. The administrative model of the organizational unit can be scaled to any size. For more information about Group Policy, see “How Core Group Policy Works.”

Administrative authority can be delegated for individual organizational units or for multiple organizational units. Organizational units can be nested to create a hierarchy within a domain and form logical administrative units for users, groups, and resource objects, such as printers, computers, applications, and file shares. The organizational unit hierarchy within a domain is independent of the structure of other domains: Each domain can implement its own hierarchy. Likewise, domains that are managed by the central authority can implement similar organizational unit hierarchies. The structure is flexible, which allows organizations to create an environment that mirrors the administrative model, whether it is centralized or decentralized.

Objects

Active Directory objects represent the physical entities that make up a network. An object stores an instance of a class. A class is defined in the Active Directory schema as a specific set of mandatory and optional attributes — that is, an attribute can be present in an object in Active Directory only when that attribute is permitted by the object’s class. Classes also contain rules that determine which classes of objects can be superior to (parents of) a particular object of the class. Each attribute is also defined in the directory schema. The attribute definitions determine the syntax for the values the attribute can have.

Creation of an Active Directory object requires specification of values for the attributes of the object in its particular class, consistent with the rules of the directory schema. For example, creating a user object requires specification of alphanumeric values for the user’s first and last names and the logon identifier, which are mandatory according to the directory schema. Other non-mandatory values can also be specified, such as telephone number and address.

Applications that create or modify objects in Active Directory use the directory schema to determine what attributes the object must and might have, and what those attributes can look like in terms of data structures and syntax constraints. The directory schema is maintained forest-wide so that all objects created in the directory conform to the same values.

Objects are either container objects or leaf objects. A container object stores other objects, and as such occupies a specific level in a subtree hierarchy. An object class is a container if at least one other class specifies it as a possible superior, so any object class defined in the schema can become a container. A leaf object does not store other objects, so it occupies the endpoint of a subtree.

 

Domains as Units of Policy

A domain defines a scope or unit of policy within a forest. Some policy settings apply only to the scope of a domain, that is, the policy settings are domain-wide. Account policies, for example, apply uniformly to all user accounts in the domain. Although a domain is not the smallest unit of policy that can be assigned (policies can be assigned to organizational units) it is the most commonly used unit when splitting administrative duties between departments and subsidiaries located in different geographical locations. As shown in the following figure, you might need to create multiple domains to provide for policy variance among domains throughout a forest. A domain is also considered a unit of access control, in that it can be used for business groups requiring general autonomy.

Delegation of Domains to Domain Admins that Require Different Policies or Autonomy

You cannot define different account policies for different organizational units in the same domain. Policy settings are stored as Group Policy objects (GPOs) in Active Directory. A GPO establishes how domain resources can be accessed, configured, and used. The policies associated with a GPO are applied only within the domain and not across domains. A GPO can be associated with one or more Active Directory containers, such as a site, domain, or organizational unit.

Account policies and Public Key policies have domain-wide scope and are set at the domain GPO level. All other policies can be specified at the level of the organizational unit. Some policies that can be applied only at the domain container level include:

• Password policy. Determines the rules, such as password length, that must be met when a user sets a password. 
• Account lockout policy. Defines rules for intruder detection and account deactivation. 
• Kerberosticket policy. Determines the lifetime of a Kerberos ticket. A Kerberos ticket is obtained during the logon process and is used for network authentication. A particular ticket is only valid for the lifetime specified in the policy.

Because organizational units provide multiple levels of administrative authority, you can use them to systematically apply Group Policy settings and delegate administrative control. Delegation simplifies the task of managing these objects and enables you to structure Active Directory to fit the requirements of your organization. Using delegated authority in conjunction with GPOs and group memberships allows one or more administrators to be assigned rights and permissions to manage objects in an entire domain or in one or more organizational units within the domain.

For more information about Group Policy, see “How Core Group Policy Works.”

Domains as Units of Replication

The physical significance of a domain is that it is a unit of replication. In fact, with the exception of application partitions, which replicate only non-security principal objects, the domain is the smallest unit of replication that can be administered within an Active Directory forest. This is because all objects that are located within a domain container, also referred to as domain data, are replicated to other domain controllers within that same domain, regardless of whether those domain controllers are located over a local area network (LAN) or wide area network (WAN) connection.

As shown in the following figure, Active Directory multi-master replication manages the transfer of domain objects to the appropriate domain controllers automatically, keeping domain data up-to-date among all domain controllers in the domain, regardless of location.

Replication of Domain Data Within Each Domain in the Forest

All domain controllers in the forest are also updated with changes to forest-wide data. For more information about replication at the Forest level, see “Forests as Units of Replication” later in this section Domain-wide replication relies on three components of the Active Directory physical structure to be in place for optimal performance, these include:

All domain controllers in the forest are also updated with changes to forest-wide data. For more information about replication at the Forest level, see “Forests as Units of Replication” later in this section Domain-wide replication relies on three components of the Active Directory physical structure to be in place for optimal performance, these include:

Domain Controllers

The physical domain controller contains the domain partition data that is replicated to other domain controllers in that same domain. A domain partition stores only the information about objects located in that domain. All domain controllers in a domain receive changes and replicate those changes to the domain partition stored on all other domain controllers in the domain. In this way, all domain controllers are peers in the domain and manage replication as a unit.

Domain controllers also have two non-domain directory partitions that store forest-wide data, which includes the directory schema and configuration data. Optionally, domain controllers, application partitions can be configured to be located on designated domain controllers anywhere in a forest. Unlike the schema and configuration partitions, application partitions are not located on every domain controller in a forest. For more information about the replication of forest-wide data, see “Forests as Units of Replication” later in this section.

Partitioning Active Directory data into three physical partitions on each domain controller helps to control replication so that data is replicated only to where it is needed. In this way, Active Directory can scale globally over a network that has limited available bandwidth.

Sites

Within the scope of a forest, sites are a representation of the physical network topology. This includes physical subnet and site definitions. Replication of updates to domain data occurs between multiple domain controllers to keep replicas synchronized. Multiple domains are common in large organizations, as are multiple sites in disparate locations. In addition, domain controllers for the same domain are commonly placed in more than one site.

Therefore, replication must often occur both within sites and between sites to keep domain and forest data consistent among domain controllers that store the same directory partitions. Replication within sites generally occurs at typical LAN speeds between domain controllers that are on the same network segment. Replication between sites usually occurs over WAN links that might be costly in terms of bandwidth. To accommodate the differences in distance and cost of replication within a site and between sites, the intrasite replication topology is used to optimize speed, and the intersite replication topology is used to minimize cost based on a configurable replication schedule.

The Knowledge Consistency Checker (KCC) is a distributed application that runs on every domain controller and is responsible for creating the connections between domain controllers that collectively form the replication topology. The KCC uses Active Directory data to determine where to create connections between source domain controllers and destination domain controllers.

Intersite replication is optimized for bandwidth efficiency, and directory updates between sites occur automatically based on a configurable schedule.

Domain-Wide Operations Masters

Active Directory supports multi-master replication of the directory data store between all domain controllers in the domain. However, some changes are impractical to perform in multi-master fashion, so only a single domain controller, called the operations master, accepts requests for such changes. Because these roles can be transferred to other domain controllers within the domain or forest, they are sometimes referred to as operations master roles.

There are three operations master roles per domain. These include the Relative Identifier (RID) Master, Primary Domain Controller (PDC) emulator, and Infrastructure Master. These three roles must be unique in each domain, so each domain can have only one RID master, one PDC emulator, and one Infrastructure Master. For information about forest-wide roles, see “Forest-Wide Operations Master Roles” later in this section. For more information about replication, see “How Active Directory Replication Topology Works.”

Domains as Authentication and Authorization Boundaries

By default, a domain provides authentication and authorization services for all its accounts in order to facilitate logons and single sign-on access control to shared resources within the boundaries of the domain. The process of authentication ensures that users are who they claim to be. Once identified, the user can be authorized access to a specific set of network resources based on permissions.Authorization takes place through the mechanism of access control, using access control lists (ACLs) that define permissions on file systems, network file and print shares, and entries in Active Directory.

Authorization is determined not only by the identity of the user but also the membership of the user in one or more security groups. In fact, the preferred method of controlling domain-wide resources is to grant access to groups rather than to individuals, adjusting the level of authorization for a group according to the needs of its members. This method of controlling access makes it easier to keep ACLs up-to-date on domains that have thousands of users and objects. Group membership can be managed centrally by anyone with the appropriate administrative credentials. You can change the level of authorization a particular user has to many resources simply by adding or removing the user from a group. The following figure shows when authentication and authorization for a user in a given domain occur.

Authentication and Authorization of a User Within the Same Domain

Authentication is not limited to users. Computers and services are also authenticated when they make network connections to other servers. For example, domain joined computers connect Active Directory in their domain for policy information during startup. Computers and services also prove their identity to clients that request mutual authentication. Mutual authentication prevents an intruder from adding another computer as an imposter between the client and the real network server. The Kerberos version 5 authentication protocol is a technology for single sign-on to network resources. Kerberos V5 protocol is used to provide single sign-on to network services within a domain, and to services residing in trusted domains. The Kerberos V5 protocol verifies both the identity of the user and of the network services, providing mutual authentication.

Authentication and authorization services in one domain can be extended to accounts that are located in trusted domains. This can be done by using trusts. Trusts are logical relationships established between domains to allow pass-through authentication in which a trusting domain honors the logon authentications of a trusted domain. Consequently, trust relationships inherently allow domain-specific authentication and authorization services to be extended, thereby enabling single sign-on access control capabilities throughout a forest. Because the domain trust relationships between all domains in the forest are bidirectional by default, authentication in one domain is sufficient for referral or pass-through authentication to resources in other domains in the forest.

Domains as Units of Trust

A domain is the smallest container within Active Directory that can be used in a trust relationship. All domains within a forest are connected by Kerberos-based trusts. Kerberos-based trusts are two-way and transitive in nature. Trusts act as authentication pipelines that must be present in order for users in one domain to access resources in another domain. All authentication requests made between domains located inside or outside of a forest must occur over trusts. Trust relationships within a forest are created as implicit two-way transitive trusts.

Note

• “Access to resources” in any discussion of trust relationships always assumes the limitations of access control.

Within a forest, trust relationships are automatically created between the forest root domain and any tree root domains on the one hand, and all child domains that are subordinate to the forest root domain on the other. Because trust relationships are two-way and transitive by default, users and computers can be authenticated between any domain containers in the forest, as shown in the following figure.

Domains as Units of Trust and the Authentication Paths they Provide

In accordance with DNS naming standards, Active Directory domains within a single forest are created in an inverted tree structure, with the forest root domain at the top. This tree structure requires that trusts exist between domains to facilitate security of communications. Adding a domain tree to a forest requires specification of the forest root domain, which results in the establishment of a trust relationship between the root domain of the new tree and the forest root domain. For more information about trusts and root domains, see “Forests as Collections of Domain Containers that Trust Each Other” later in this section.

What Domains Are Not

Domains are not security boundaries within the scope of Active Directory and do not provide complete isolation in the face of possible attacks by malicious service administrators who might manage that forest. This is because a malicious service administrator, such as a member of the Domain Admins group, can use nonstandard tools and procedures to gain full access to any domain in the forest or to any computer in the forest. For example, service administrators in a non-root domain can make themselves members of the Enterprise Admins or Schema Admins group.

However, administrative rights do not flow across domain boundaries, nor do they flow down through a domain tree. For example, if you have a domain tree with domains A, B, and C, where A is the parent domain of B and B is the parent domain of C, users with administrative rights in domain A do not have administrative rights in B, nor do users with administrative rights in domain B have administrative rights in domain C. For a user to obtain administrative rights in a given domain, a higher authority must grant them. This does not mean, however, that an administrator cannot have administrative rights in multiple domains; it simply means that all rights must be explicitly defined.

For more information about isolation, see “Forests as Security Boundaries” later in this section.

What Are Forests?

At its highest level, a forest is a single instance of Active Directory. Therefore, a forest is synonymous with Active Directory, meaning that the set of all directory partitions in a particular Active Directory instance (which includes all domain, configuration, schema and optional application information) makes up a forest. This means that when you have multiple forests in an enterprise they will, by default, act separately from each other as if they were the only directory service in your organization.

This behavior, however, is easily be modified so that multiple forests can share Active Directory responsibilities across an enterprise. This is done by creating external or forest trust relationships between the forests. In this way, each forest can be connected with every other forest to form a collaborative directory service solution for any enterprise with business needs that include multiple forest collaboration.

Forests can also be defined as:

• Collections of Domain Containers that Trust Each Other
• Units of Replication 
• Security Boundaries
• Units of Delegation

Forests as Collections of Domain Containers that Trust Each Other

Within the scope of Active Directory, a forest is a collection of domain containers that inherently trust each other and other security services that are located in that same forest. All domain containers in a forest share a common global catalog, directory schema, and directory configuration, as well as automatic two-way transitive trust relationships. Because all of the domain containers are inherently joined through two-way transitive trusts, all authentication requests made from any domain in the forest to any other domain in the same forest will be granted. In this way, all security principals that are located in domain containers within a forest inherently trust each other.

Forests can be used to segregate domain containers into one or more unique DNS namespace hierarchies known as domain trees. Although each domain tree consists of a unique namespace the schema and configuration data for the forest are shared throughout all the domain containers in a forest irrespective of namespace. Each domain container in a forest must adhere to DNS naming schemes and all domains are organized in a root and subordinate domain hierarchy. Root domains, such as forest root and tree root domains, define the DNS namespace for their subordinate domains. Although a forest can consist of multiple domain trees, it represents one organization. However, an organization can have multiple forests. For more information about multiple forests, see “Forests as Units of Delegation” later in this section. As shown in the following figure, the namespace for each root domain must be unique.

Domain Containers, Root Domains and DNS Namespaces Within a Forest

Forest Root Domain

Although trees in a forest do not share the same DNS namespace, a forest does have a single root domain, called the forest root domain. The forest root domain is, by definition, the first domain created in the forest. The Enterprise Admins and Schema Admins groups are located in this domain. By default, members of these two groups have forest-wide administrative credentials. In Windows 2000 Active Directory, the forest root domain cannot be deleted, changed, or renamed. In Windows Server 2003 and later versions of Active Directory, the forest root domain cannot be deleted, but it can be restructured or renamed.

Objects are located within Active Directory domains according to a hierarchical path, which includes the labels of the Active Directory domain name and each level of container objects. The full path to the object is defined by the distinguished name (also known as a DN). The distinguished name is unambiguous (identifies one object only) and unique (no other object in the directory has this name). By using the full path to an object, including the object name and all parent objects to the root of the domain, the distinguished name uniquely and unambiguously identifies an object within a domain hierarchy.

The distinguished name of the forest root domain is used to locate the configuration and schema directory partitions in the namespace. The distinguished names for the Configuration and Schema containers in Active Directory always show these containers as child objects in the forest root domain. For example, in the child domain Noam.wingtiptoys.com (where Wingtiptoys.com is the name of the forest root domain), the distinguished name of the Configuration container is cn=configuration,dc=wingtiptoys,dc=com. The distinguished name of the Schema container is cn=schema,cn=configuration,dc=wingtiptoys,dc=com. However, this naming convention provides only a logical location for these containers.

These containers do not exist as child objects of the forest root domain, nor is the schema directory partition actually a part of the configuration directory partition: They are separate directory partitions. Every domain controller in a forest stores a copy of the configuration and schema directory partitions, and every copy of these partitions has the same distinguished name on every domain controller.

Tree Root Domain

A domain tree represents a unique DNS namespace: it has a single root domain, known as the tree root domain, and is built as a strict hierarchy: Each domain above the tree root domain has exactly one superior, or parent, domain (the forest root domain). The namespace created by this hierarchy, therefore, is contiguous — each level of the hierarchy is directly related to the level above it and to the level below it. In other words, the names of domains created beneath the tree root domain (child domains) are always contiguous with the name of the tree root domain. The DNS names of the child domains of the root domain of a tree reflect this organization; therefore, the children of a root domain called Somedomain are always children of that domain in the DNS namespace (for example, Child1.somedomain, Child2.somedomain, and so forth).

Multiple domain trees can belong to a single forest and do not form a contiguous namespace; that is, they have noncontiguous DNS domain names. Although the roots of the separate trees have names that are not contiguous with each other, the trees share a single overall namespace because names of objects can still be resolved by the same Active Directory instance. A forest exists as a set of cross-reference objects and trust relationships that are known to the member trees. Transitive trusts at the root domain of each namespace provide mutual access to resources.

The domain hierarchy in a forest determines the transitive trust links that connect each domain. Each domain has a direct trust link with its parent and each of its children. If there are multiple trees in a forest, the forest root domain is at the top of the trust tree and, from a trust perspective, all other tree roots are children. That means authentication traffic between any two domains in different trees must pass through the forest root.

Forests as Units of Replication

Unlike domains, forests are the largest unit of replication that can be administered in an Active Directory environment. To efficiently synchronize data between domain controllers throughout a forest, Active Directory replication transfers updates according to directory partition. Directory partitions are used to help organize how replication occurs within a forest. Active Directory uses four distinct directory partition types to store and copy four different types of data.

One directory partition contains domain data; the other three are forest-wide partitions, and contain configuration, schema, and application data. This storage and replication design provides directory information to users and administrators throughout the domain. Each domain controller receives directory updates to the data stored in its domain only, as well as updates to the data in the two directory partitions that store configuration and schema data for the forest. As shown in the following figure, schema and configuration data must be replicated to all domain controllers that exist in a forest, while optional Application data is replicated only to domain controllers within the same forest that are specified as replication partners.

Forest-Wide Replication Scope

The following table describes each of the three forest-wide partitions in more detail.

Forest-Wide Directory Partitions

 

Partition	Description
Schema	The schema partition contains the forest-wide schema. Each forest has one schema so that the definition of each object class is consistent. The schema is the formal definition of all object and attribute data that can be stored in the directory. Active Directory domain controllers include a default schema that defines many object types, such as user and computer accounts, groups, domains, organization units, and security policies. Administrators and programmers can extend the schema by defining new object types and attributes or by adding new attributes for existing objects. Schema objects are protected by access control lists, ensuring that only authorized users can alter the schema. The schema partition is replicated to each domain controller in the forest.
Configuration	The configuration partition describes the topology of the forest as well as other forest, domain and domain controller settings. This configuration data includes a list of all domains, trees, and forests and the locations of the domain controllers and global catalogs. The configuration partition is replicated to each domain controller in the forest.
Application	Applications and services can use application directory partitions to store application-specific data. Data stored in the application directory partition is intended to satisfy cases where information needs to be replicated but not necessarily on a global scale. Application directory partitions can contain any type of object, except security principals. Application directory partitions are usually created by the applications that will use them to store and replicate data. One of the benefits of an application directory partition is that, for redundancy, availability, or fault tolerance, the data in it can be replicated to different domain controllers in a forest. The data can be replicated to a specific domain controller or any set of domain controllers anywhere in the forest. This differs from a domain directory partition in which data is replicated to all domain controllers in that domain. Only domain controllers running Windows Server 2003 or higher can host a replica of an application directory partition. Application directory partitions are created, configured, and managed by the administrator.

All forest replication is Multi-Master with the exception of the three domain-wide and two forest-wide operations master roles. Forest-wide replication requires domain controllers and three other components of the Active Directory physical structure to be in place for optimal performance. These components are forest-wide operations master roles, sites, and global catalogs.

Forest-Wide Operations Master Roles

There are two operations master roles assigned for the entire forest. These include the domain naming master and the schema master. Each forest must have one and only one schema master and one domain naming master, so these two roles must remain in the forest root domain. The other three operations master roles are assigned to each domain in the forest. These three roles must be unique in each domain, so each domain can have only one relative ID master, one PDC emulator, and one infrastructure master.

In an Active Directory forest with only one domain and one domain controller, that domain controller has all the operations master roles. For more information about operations master roles, see “How Operations Masters Work.”

Sites

Sites in Active Directory represent the physical structure, or topology, of the network. Within the scope of a forest, sites are a representation of the physical network topology, including physical subnet and site definitions. When you establish sites, domain controllers within a single site communicate frequently. This communication minimizes the latency within the site; that is, the time required for a change that is made on one domain controller to be replicated to other domain controllers. You create sites to optimize use of the bandwidth between domain controllers in different locations. For more information about sites, see “How Active Directory Replication Topology Works.”

Global Catalogs

The global catalog stores a full copy of all Active Directory objects in the directory for its host domain and a partial copy of all objects for all other domains in the forest. Users in a forest do not need to be aware of directory structure because all users see a single directory through the global catalog. Applications and clients can query the global catalog to locate any object in a forest. The global catalog is hosted on one or more domain controllers in the forest. It contains a partial replica of every domain directory partition in the forest. These partial replicas include replicas of every object in the forest, including the attributes most frequently used in search operations and the attributes required to locate a full replica of the object. A global catalog is created automatically on the first domain controller in the forest. Optionally, other domain controllers can be configured to serve as global catalogs.

A global catalog serves the following roles:

• Enables user searches for directory information about objects throughout all domains in the forest
• Resolves user principal names (UPNs) during authentication, when the authenticating domain controller does not have information about the account
• Supplies universal group membership information in a multiple domain environment
• Validates references to objects in other domains in the forest

For more information about global catalogs and their roles, see “How the Global Catalog Works.”

Forests as Security Boundaries

Each forest is a single instance of the directory, the top-level Active Directory container, and a security boundary for all objects that are located in the forest. This security boundary defines the scope of authority of the administrators. In general, a security boundary is defined by the top-level container for which no administrator external to the container can take control away from administrators within the container. As shown in the following figure, no administrators from outside a forest can control access to information inside the forest unless first given permission to do so by the administrators within the forest.

A forest is the only component of the Active Directory logical structure that is a security boundary. By contrast, a domain is not a security boundary because it is not possible for administrators from one domain to prevent a malicious administrator from another domain within the forest from accessing data in their domain. A domain is, however, the administrative boundary for managing objects, such as users, groups, and computers. In addition, each domain has its own individual security policies and trust relationships with other domains.

Forests as Units of Delegation

The forest is the largest management unit of Active Directory as well as the ultimate unit of autonomy and isolation of authority. Members of the Enterprise Admins and forest root Domain Admins security groups are known as enterprise administrators. Enterprise administrators control the Active Directory objects in the configuration container that do not belong to any one domain, including Enterprise Certification Authority objects and other configuration data that affects all domains in the forest.

Because enterprise administrators have authority over all domains in the forest, the domain administrators in each domain must trust the enterprise administrators. You cannot truly restrict enterprise administrators from managing objects in any domain in the forest. Enterprise administrators can always regain control over objects. Some organizations with political challenges, such as those frequently encountered in mergers and acquisitions, might find the scope of this enterprise authority too great and require more than one forest. If your organization requires strict isolation of authority between domains, you must deploy multiple forests with manually created trusts between domains in the different forests.

Because each forest is administered separately, adding additional forests to your organization increases the management overhead of the organization. The number of forests that you need to deploy is based on the autonomy and isolation requirements of each group within your organization. Reasons to create multiple forests in your organization include:

• To secure data within each forest. Sensitive data can be protected so that only users within that forest can access it. 
• To isolate directory replication within each forest. Schema changes, configuration changes, and the addition of new domains to a forest have forest-wide impact only within that forest, not on a trusting forest. 

Because the forest is a security boundary, each forest does not trust or allow access from any other forest by default. However, in Windows Server 2003 and higher Active Directory, transitive trust relationships can be manually established between forests to establish cross-forest access to resources, so that users in one forest can access resources in another forest.

Forest trusts help you to manage a segmented Active Directory infrastructure within your organization by providing support for accessing resources and other objects across multiple forests. By using forest trusts, you can link two different Windows Server 2003 or higher forests to form a one-way or two-way transitive trust relationship. A forest trust allows administrators to federate two Active Directory forests with a single trust relationship to provide a seamless authentication and authorization experience across the forests.

When two forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests. Trust security settings and firewalls can be configured between domains in different forests that are joined by trust relationships to limit cross-forest connectivity to specific users or applications. For more information about trust security settings, see “Security Considerations for Trusts.”

A forest trust can be created only between a forest root domain in one Windows Server 2003 or higher forest and a forest root domain in another Windows Server 2003 or higher forest. Forest trusts can be created between two forests only and cannot be implicitly extended to a third forest. This means that if a forest trust is created between Forest 1 and Forest 2, and another forest trust is created between Forest 2 and Forest 3, Forest 1 does not have an implicit trust with Forest 3. The following figure shows two separate forest trust relationships between three forests in a single organization.