What Are Domains and Forests?

Updated: November 19, 2014

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with
SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2,
Windows Server 2012, Windows Server 2012 R2

What Are Domains and Forests?

In this section

The Logical Structure of Active Directory

The Physical Structure of Active Directory

What Are Domains?

What Are Forests?

Related Information

The Active Directory directory service is a distributed database that stores and manages
information about network resources, as well as application-specific data from directoryenabled 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.
Note
In Windows 2000 Server and Windows Server 2003, the directory service is named Active
Directory. In Windows Server 2008 and Windows Server 2008 R2, the directory service is
named Active Directory Domain Services (AD DS). The rest of this topic refers to Active
Directory, but the information is also applicable to Active Directory Domain Services.
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
1

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.
2

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

Organizational
Units

Domains

Description
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 organizations requirements.
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 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.

Domain Trees

Forests

Site Objects

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.
A forest is a complete instance of Active Directory. Each forest acts as a toplevel 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.
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
3

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.
4

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.
Note

You can view the physical structure of Active Directory by using Active Directory
Sites and Services.

For more information about the network components associated with the physical structure of
Active Directory, see the Active Directory Replication Topology Technical Reference.

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.
5

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.
6

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 objects 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 users 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. For more information about Active Directory Objects, see How
Domains and Forests Work and How the Active Directory Schema Works.

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
7

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:
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.
10

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
11

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 domainwide 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.
12

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. Kerberosbased 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

13

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
14

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
15

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.

16

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.

17

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
18

Partition

Description
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,
Schema
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.
The configuration partition describes the topology of the forest as well as other
forest, domain and domain controller settings. This configuration data includes
Configuration 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.
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
Application
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.
19

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.
20

Enterprise Administrators Outside of a Forest Can Administer Only Within Their Own
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:

21

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 crossforest 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.
Two Forest Trusts Between Three Windows Server 2003 Forests

22

How Domains and Forests Work

Updated: November 19, 2014
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with
SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2,
Windows Server 2012, Windows Server 2012 R2

How Domains and Forests Work

In this section

Domain and Forest Structure

Active Directory Objects

Domain and Forest Protocols and Programming Interfaces

Domain and Forest Processes and Interactions

Network Ports Used by Domains and Forests

Related Information

Active Directory stores data for an entire forest. A forest is a distributed database, which is
made up of directory partitions spread across multiple computers. A domain is one partition of
the database; each domain contains Active Directory objects, such as security principal
objects (users, computers, and groups) to which you can grant or deny access to network
resources. All domain data stored in the domain directory partition is replicated to domain
controllers in that domain only.
Note
In Windows 2000 Server and Windows Server 2003, the directory service is named Active
Directory. In Windows Server 2008 and Windows Server 2008 R2, the directory service is
named Active Directory Domain Services (AD DS). The rest of this topic refers to Active
Directory, but the information is also applicable to Active Directory Domain Services.
The directory partitions that store configuration and schema information are replicated to
domain controllers in all domains. In this way, Active Directory provides a data repository
that is logically centralized but physically distributed. Because all domain controllers store
forest-wide configuration and schema information, a domain controller in one domain can
reference a domain controller in any other domain if the information that it is requesting is not
stored locally.
This section details how domains and forests work, discusses the various components of
domains and forests, describes several common processes that depend on domains and forests,
and lists the network ports related to domains and forests.

Domain and Forest Structure

23

A forest consists of a hierarchical structure of domain containers that are used to categorically
store information about objects on the network. Domain containers are considered the core
functional units in the forest structure. This is because each domain container in a forest is
used primarily to store and manage Active Directory objects, most of which have a physical
representation (such as people, printers, or computers). Forests also provide the structure by
which domain containers can be segregated into one or more unique Domain Name System
(DNS) namespace hierarchies known as domain trees.
In addition, the domain tree hierarchy is based on trust relationships that is, the domain
containers are linked by intra-forest trust relationships. When it is necessary for domain
containers in the same organization to have different namespaces, you can create a separate
tree for each namespace. In Active Directory, the roots of trees are linked automatically by
two-way, transitive trust relationships. Trees linked by trust relationships form a forest. A
single tree that is related to no other trees constitutes a forest of one tree. The domain and
forest structure is made up of the following components:

Cross-References

Trust Relationships

Forest Root

Domain Trees and Child Domains

Domain Names

For more information about Active Directory Domains and DNS, see How DNS Support for
Active Directory Works.
This section describes the structure and function of these components, and describes how this
structure helps administrators manage the network so that users can accomplish business
objectives.

Cross-References
Cross-references enable every domain controller to be aware not only of the partitions that it
holds, but of all directory partitions in the forest. The information contained within crossreferences form the glue that holds the pieces of the domain and forest structure together.
Because Active Directory is logically partitioned, and directory partitions are the discrete
components of the directory that replicate between domain controllers, either all objects in a
directory partition are present on a particular domain controller or no objects in the directory
partition are present on the domain controller. For this reason, cross references have the effect
of linking the partitions together, which allows operations such as searches to span multiple
partitions.
Cross-references are stored as directory objects of the class crossRef that identify the
existence and location of all directory partitions, irrespective of location in the directory tree.
In addition, these objects contain information that Active Directory uses to construct the
directory tree hierarchy. Values for the following attributes are required for each crossreference:

24

nCName . The distinguished name of the directory partition that the crossRef object
references. (The prefix nC stands for naming context, which is a synonym for
directory partition.) The combination of all of the nCName properties in the forest
defines the entire directory tree, including the subordinate and superior relationships
between partitions.

dNSRoot. The DNS name of the domain where servers that store the particular
directory partition can be reached. This value can also be a DNS host name.

How Cross-Reference Information is Propagated Throughout the Domain and Forest

Structure
For every directory partition in a forest, there is an internal cross-reference object stored in the
Partitions container (cn=Partitions,cn=Configuration,dc=ForestRootDomain). Because crossreference objects are located in the Configuration container, they are replicated to every
domain controller in the forest, and thus every domain controller has information about the
name of every partition in the forest. By virtue of this knowledge, any domain controller can
generate referrals to any other domain in the forest, as well as to the schema and configuration
directory partitions.
When you create a new forest, the Active Directory Installation Wizard creates three directory
partitions: the first domain directory partition, the configuration directory partition, and the
schema directory partition. For each of these partitions, a cross-reference object is created
automatically. Thereafter, when a new domain is created in the forest, another directory
partition is created and the respective cross-reference object is created. When the
configuration directory partition is replicated to the new domain controller, a cross-reference
object is created on the domain naming master and is then replicated throughout the forest.
Note

The state of cross-reference information at any specific time is subject to the effects of
replication latency.

For more information about cross-reference objects, see How Active Directory Searches
Work. Cross-reference objects can also be used to generate referrals to other directory
partitions located in another forest through external cross-references.
External Cross-References
An external cross-reference is a cross-reference object that can be created manually to provide
the location of an object that is not stored in the forest. If your Lightweight Directory Access
Protocol (LDAP) clients submit operations for an external portion of the global LDAP
namespace against servers in your forest, and you want servers in your forest to refer the
client to the correct location, you can create a cross-reference object for that directory in the
Partitions container. There are two ways that external cross-references are used:

To reference external directories by their disjoint directory name (a name that is not
contiguous with the name of this directory tree). In this case, when you create the
cross-reference, you create a reference to a location that is not a child of any object in
this directory.

25

To reference external directories by a name that is within the Active Directory

namespace (a name that is contiguous with the name of this directory tree). In this
case, when you create the cross-reference, you create a referenceto a location that is a
child of a real object in this directory.

Because the domain component (dc=) portion of the distinguished names of all Active
Directory domains matches their DNS addresses, and because DNS is the worldwide
namespace, all domain controllers can generate external referrals to each other automatically.

Trust Relationships
Active Directory provides security across multiple domains through intra-forest trust
relationships. When there are trust relationships between domains in the same forest, the
authentication mechanism for each domain trusts the authentication mechanism for all other
trusted domains. If a user or application is authenticated by one domain, its authentication is
accepted by all other domains that trust the authenticating domain. Users in a trusted domain
have access to resources in the trusting domain, subject to the access controls that are applied
in the trusting domain.
Note

Default intra-forest trust relationships are created at the time the domains are created.
The number of trust relationships required to connect n domains is n1, whether the
domains are linked in a single, contiguous parent-child hierarchy or constitute two or
more separate contiguous parent-child hierarchies.

A trust relationship is a relationship established between two domains that allows users in one
domain to be recognized by a domain controller in the other domain. Trusts let users access
resources in the other domain, and also let administrators manage user rights for users in the
other domain. Account authentication between domains is enabled by two-way, transitive
trust relationships. All domain trusts in an Active Directory forest are two-way and transitive
and are have the following attributes:

Two-way. When you create a new child domain, the child domain automatically trusts
the parent domain, and vice versa. At the practical level, this means that authentication
requests can be passed between the two domains in both directions.

Transitive. A transitive trust reaches beyond the two domains in the initial trust
relationship. For example, if Domain A and Domain B (parent and child) trust each
other, and if Domain B and Domain C (also parent and child) trust each other, Domain
A and Domain C also trust each other (implicitly), even though no direct trust
relationship between them exists.

At the level of the forest, a trust relationship is created automatically between the forest root
domain and the root domain of each domain tree added to the forest, with the result that
complete trust exists between all domains in an Active Directory forest. At the practical level,
because trust relationships are transitive, a single logon process lets the system authenticate a
user (or computer) in any domain in the forest. As shown in the following figure, this single
logon process lets the account access resources on any domain in the forest.
Transitive Trusts Facilitate Cross-Domain Access to Resources With a Single Logon
26

Note

Single logons enabled by trusts do not necessarily imply that the authenticated user
has rights and permissions in all domains in the forest. This is because in any
discussion of trust relationships, access to resources always assumes the limitations of
access control.

Forest Root Domain

The first domain created in the forest is called the forest root domain. When you create a new
tree, you specify the root domain of the initial tree, and a trust relationship is established
between the root domain of the second tree and the forest root domain. If you create a third
tree, a trust relationship is established between the root domain of the third tree and the forest
root domain. Because all trust relationships created within a forest are transitive and two-way,
the root domain of the third tree also has a two-way trust relationship with the root domain of
the second tree. In Windows 2000 Active Directory, the forest root domain cannot be deleted,
changed, or renamed. In Windows Server 2003 Active Directory or higher, the forest root
domain cannot be deleted, but it can be restructured or renamed.
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, the
27

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.
The 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. The following operations occur when you create the forest
root domain:

The Schema container and the Configuration container are created.

The Active Directory Installation Wizard assigns the PDC emulator, RID master,
domain naming master, schema master, and infrastructure master roles to the domain
controller.

The Enterprise Admins and Schema Admins groups are located in this domain. By default,
members of these two groups have forest-wide administrative credentials.

Domain Trees and Child Domains

A forest is a collection of one or more domain trees, organized as peers and connected by
two-way, transitive trust relationships. A single domain constitutes a tree of one domain, and
a single tree constitutes a forest of one tree. Thus, a forest is synonymous with Active
Directory that is, the set of all directory partitions in a particular directory service instance
(which includes all domains and all configuration and schema information) makes up a forest.
Trees in the same forest do not form a contiguous namespace. They form a noncontiguous
namespace that is based on different DNS root domain names. However, trees in a forest
share a common directory schema, configuration, and global catalog. (The global catalog is a
domain controller that stores all objects of all domains in an Active Directory forest, which
makes it possible to search for objects at the forest level rather than at the tree level.) This
sharing of common schema and configuration data, in addition to trust relationships between
their roots, distinguishes a forest from a set of unrelated trees. 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.
Note

The directory schema and configuration data are shared because they are stored in
separate logical directory partitions that are replicated to domain controllers in every
domain in the forest. The data about a particular domain is replicated only to domain
controllers in the same domain.

Domain Trees
A domain tree is a DNS namespace: it has a single root domain and is built as a strict
hierarchy; each domain below the root domain has exactly one superior, or parent, domain.
The namespace created by this hierarchy, therefore, is contiguous each level of the
28

hierarchy is directly related to the level above it and to the level below it, if any. In Active
Directory, the following rules determine the way that trees function in the namespace:

A tree has exactly one name. The name of the tree is the DNS name of the domain at
the root of the tree.

The names of domains created beneath the root domain (child domains) are always
contiguous with the name of the tree root domain.

The DNS names of the child domains of the tree root domain reflect this organization;
therefore, the children of a tree root domain called Somedomain are always children of
that domain in the DNS namespace (for example, Child1.somedomain,
Child2.somedomain, and so forth).

Note

Tree and forest hierarchies are specific to Active Directory domains. A

Windows NT 4.0 domain that is configured to trust or to be trusted by a Active
Directory domain is not part of the forest to which the Active Directory domain
belongs.

The forest structure provides organizations with the option of constructing their enterprise
from separate, distinct, noncontiguous namespaces. Having a separate namespace is desirable
under conditions where, for example, the namespace of an acquired company should remain
intact. If you have business units with distinct DNS names, you can create additional trees to
accommodate the names.
Note

Before creating a new domain tree when you want a different DNS namespace,
consider creating another forest. Multiple forests provide administrative autonomy,
isolation of the schema and configuration directory partitions, separate security
boundaries, and the flexibility to use an independent namespace design for each forest.

When you create a new domain tree, you specify the root domain of the initial tree, and a trust
relationship is established between the root domain of the new tree (the second tree) and the
forest root domain. If you create a third tree, a trust relationship is established between the
root domain of the third tree and the forest root domain. Because a trust relationship is
transitive and two-way, the root domain of the third tree also has a two-way trust relationship
with the root domain of the second tree. The following operations occur when you create a
new tree root domain in an existing forest:

Location of a source domain controller in the forest root domain and synchronization
of domain system time with the system time of the source domain controller.

Creation of a tree-root trust relationship between the tree root domain and the forest
root domain, and creation of the trusted domain object (TDO) in both domains. The
tree-root trust relationship is two-way and transitive.

Child Domains

29

Child domains can represent geographical entities (for example, the United States and
Europe), administrative entities within the organization (for example, sales and marketing
departments), or other organization-specific boundaries, according to the needs of the
organization. Domains are created below the root domain to minimize Active Directory
replication and to provide a means for creating domain names that do not change. Changes in
the overall domain architecture, such as domain collapses and domain re-creation, create
difficult and potentially IT-intensive support requirements. A good namespace design should
be capable of withstanding reorganizations without the need to restructure the existing domain
hierarchy.
Each time you create a new child domain, a two-way transitive trust relationship (known as
the parent-child trust) is automatically created between the parent and new child domain. In
this way, transitive trust relationships flow upward through the domain tree as it is formed,
creating transitive trusts between all domains in the domain tree. The parent-child relationship
is a naming and trust relationship only. Administrators in a parent domain are not
automatically administrators of a child domain. Likewise, policies set in a parent domain do
not automatically apply to child domains.
The following operations occur when you create a child domain in an existing tree:

Verification of the name that you provide as a valid child domain name.

Location of a source domain controller in the parent domain and synchronization of

the system time of the child domain with the system time of the source domain
controller.

Creation of parent-child TDOs in the System folder on both the parent domain and the
child domain. The TDO objects identify two-way transitive trust relationships between
the child domain and the parent domain.

Replication of the Active Directory Schema container and the Configuration container
from a domain controller in the parent domain.

Domain Names
Active Directory uses DNS naming standards for hierarchical naming of Active Directory
domains and computers. For this reason, domain and computer objects are part of both the
DNS domain hierarchy and the Active Directory domain hierarchy. Although these domain
hierarchies have identical names, they represent separate namespaces.
The domain hierarchy defines a namespace. A namespace is any bounded area in which
standardized names can be used to symbolically represent some type of information (such as
an object in a directory or an Internet Protocol [IP] address) and that can be resolved to the
object itself. In each namespace, specific rules determine how names can be created and used.
Some namespaces, such as the DNS namespace and the Active Directory namespace, are
hierarchically structured and provide rules that allow the namespace to be partitioned. Other
namespaces, such as the Network Basic Input/Output System (NetBIOS) namespace, are flat
(unstructured) and cannot be partitioned.
The main function of DNS is to map user-readable computer names to computer-readable IP
addresses. Thus, DNS defines a namespace for computer names that can be resolved to IP
addresses, or vice versa. In Windows NT 4.0 and earlier, DNS names were not required;
30

domains and computers used NetBIOS names, which were mapped to IP addresses by using
the Windows Internet Name Service (WINS). Although DNS names are required for Active
Directory domains and Windows 2000, Windows XP, and Windows Server 2003based
computers, NetBIOS names also are supported in Windows Server 2003 for interoperability
with Windows NT 4.0 domains and with clients that are running Windows NT 4.0 or earlier,
Windows for Workgroups, Windows 98, or Windows 95. There is no interoperability between
Windows Server 2008 and higher domains and Windows NT 4.0 domains.
Note

WINS and NetBIOS are not required in an environment where computers run only
Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows
Server 2008, Windows 7 or Windows Server 2008 R2, but WINS is required for
interoperability between Windows 2000 Server and Windows Server 2003based
domain controllers, computers that are running earlier versions of Windows, and
applications that depend on the NetBIOS namespace for example, applications that
call NetServerEnum and other so-called Net* application programming interfaces
(APIs) that depend on NetBIOS. There is no interoperability between Windows Server
2008 based domains and Windows NT 4.0 domains.

Active Directory domains have both DNS names and NetBIOS names. In general, both names
are visible to end users. The DNS names of Active Directory domains include two parts, a
prefix and a suffix. The DNS prefix is the first label in the DNS name of the domain. The
suffix is the name of the Active Directory forest root domain. For example, the first label of
the DNS name for the Child1.wingtiptoys.com domain is Child1 and is referred to as the DNS
prefix. The name of the forest root domain in that same forest is wingtiptoys.com and is
referred to as the DNS suffix.
Active Directory Domain Names and the Internet
Active Directory domain names can exist within the scope of the global Internet DNS
namespace. When an Internet presence is required by an individual or organization, the Active
Directory namespace is maintained as one or more hierarchical Windows 2000 domains
beneath a root domain that is registered as a DNS namespace. Registration of individual and
organizational root domain DNS names ensures the global uniqueness of all DNS names and
provides for the assignment of network addresses that are recorded in the global DNS
database. Registration of the DNS name for the root domain of the individual or organization
also grants that individual or organization the authority to manage its own hierarchy of child
domains, zones, and hosts within the root domain.
Note

An organization might or might not choose to be part of the global Internet DNS
namespace. However, even if the root domain of the organization is not registered as
an Internet DNS namespace, the DNS service is required to locate Windows 2000,
Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008,
Windows 7 and Windows Server 2008 R2based computers in general and
Windows 2000 Server,Windows Server 2003, Windows Server 2008 and Windows
Server 2008 R2based domain controllers in particular.

For more information about domain names, see How DNS Support for Active Directory
Works.
31

Active Directory Objects

Active Directory objects represent the entities that make up a network. An object is a distinct,
named set of attributes that represents something concrete, such as a user, a printer, or an
application. When you create an Active Directory object, Active Directory generates values
for some of the attributes of the object; others you provide. For example, when you create a
user object, Active Directory assigns a globally unique identifier (GUID) and a security
identifier (SID), and you provide values for such attributes of the user as the given name,
surname, logon identifier, and so on. This section describes the key identifiers assigned to
objects by Active Directory and their associated naming schemes

Object Uniqueness
Each object in Active Directory is associated with at least one identifier that identifies that
object as unique in an enterprise. This object identifier is referred to as a globally unique
identifier (GUID). Another identifier, referred to as a security ID (SID), is used on securityenabled objects so that authentication and authorization services can determine its origin and
validity within the domain or forest. Active Directory objects that are security-enabled are
referred to as security principals.
A security principal is an object managed by Active Directory that is automatically assigned a
SID for logon authentication and for access to resources. A security principal can be a user
account, computer account, or a group, and is unique within a single domain. A security
principal object must be authenticated by a domain controller in the domain in which the
security principal object is located, and it can be granted or denied access to network
resources.
GUIDs
Every object in Active Directory has a GUID, a 128-bit number assigned by the Directory
System Agent when the object is created. The GUID, which cannot be altered or removed, is
stored in an attribute that is required for every object, not just security principal objects. The
GUID of each object is stored in its Object-GUID (objectGUID) property. When storing a
reference to an Active Directory object in an external store (for example, a Microsoft SQL
Server database), the objectGUID value should be used.
Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of
the properties of an object that is published in the global catalog. Searching the global catalog
for the GUID of a User object will yield results if the user has an account somewhere in the
enterprise. In fact, searching for any object by Object-GUID might be the most reliable way
of finding the object you want to find. This is because the values of other object properties
can change, but the Object-GUID never changes. When an object is assigned a GUID, it
always keeps that value.
Security IDs (SIDs)
When a new security principal is created, Active Directory stores the SID of the security
principal in the Object-SID (objectSID) property of the object and assigns the new object a
GUID. Each security principal (as well as the domain itself) has a SID, which is the property
that authoritatively identifies the object to the Windows security subsystem. The SID of a
user, group, or computer is derived from the SID of the domain to which the object belongs;
32

this SID is made up of the value of the domain SID and one additional 32-bit component
called the relative identifier (RID).
In Windows 2000 and later operating systems, ACLs are used to identify users and groups by
SID, not by GUID even ACLs on resources in Active Directory. A user gains access to, for
example, a Group Policy object, based on one of the SIDs belonging to the user, not based on
the GUID for the User object.
SIDs and Migrations

When an employee moves to a different location or to a new position, their user account
might need to be moved or migrated to a different domain within the organization. Migrating
a user account from one domain to another replaces the SID of the account with a new SID
and new RID assigned by the new domain. For example, if Nicolette moves from North
America to Europe, but stays in the same company, her account can be transferred with her.
An administrator with the appropriate credentials can simply move her User object from, say,
the Noam.wingtiptoys.com domain to the Euro.wingtiptoys.com domain. When the account is
moved, the User object for her account needs a new SID. The domain identifier portion of a
SID issued in Noam is unique to Noam, so the SID for her account in Euro has a different
domain identifier. The RID portion of a SID is unique relative to the domain, so if the domain
changes, the RID also changes.
Thus when a User object moves from one domain to another, a new SID must be generated
for the user account and stored in the Object-SID property. Before the new value is written to
the property, the previous value is copied to another property of a User object, SID History
(SIDHistory). This property can hold multiple values. Each time a User object moves to
another domain, a new SID is generated and stored in the Object-SID property and another
value is added to the list of old SIDs in SIDHistory. When a user logs on and is successfully
authenticated, the domain authentication service queries Active Directory for all of the SIDs
associated with the user the current SID of the user, any old SIDs of the user, and the SIDs
for the groups to which the user belonged. All of these SIDs are returned to the authentication
client and are included in the access token of the user. When the user tries to gain access to a
resource, any one of the SIDs in the access token, including one of the SIDs in SIDHistory,
can be used to authorize the user to the resource.
For more information about SIDHistory, see How Security Identifiers Work and Security
Considerations for Trusts.

Object Names
Object names are used to identify accounts in an Active Directory network. Objects have both
LDAP-related names and logon names. Each object name represents a unique attribute for
that object.
LDAP-Related Names
Active Directory is a Lightweight Directory Access Protocol (LDAP)-compliant directory
service. In Windows Server 2003 and higher operating systems, all access to Active Directory
objects occurs through LDAP. LDAP defines what operations can be performed in order to
query and modify information in a directory, and how information in a directory can be
accessed in compliance with established security requirements. Therefore, you can use LDAP
to find or enumerate directory objects and to query or administer Active Directory.
33

It is possible to query by LDAP distinguished name (which is itself an attribute of the object),
but because these names are difficult to remember, LDAP also supports querying by other
attributes (for example, by using the attribute color to find color printers). This lets you
find an object without having to know the distinguished name. If your organization has
several domains, it is possible to use the same user name or computer name in different
domains.
Like some other types of object names, LDAP-related names can change. The SID, globally
unique ID, LDAP distinguished name, and canonical name generated by Active Directory
uniquely identify each user, computer, or group in the forest. If the security principal object is
renamed or moved to a different domain, the SID, LDAP relative distinguished name, LDAP
distinguished name, and canonical name change, but the globally unique ID generated by
Active Directory does not change.

Distinguished Name
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
name of the object itself, separate from the path to the object, is defined by the relative
distinguished name.
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. It contains sufficient
information for an LDAP client to retrieve information the about the object from the
directory.
For example, a user named Samantha Smith works in the marketing department of a company
as a promotions coordinator. Therefore, her user account is created in an organizational unit
that stores the accounts for marketing department employees who are engaged in promotional
activities. The user identifier for Samantha Smith is Ssmith, and she works in the North
American branch of the company. The root domain of the company is wingtiptoys.com, and
the local domain is noam.wingtiptoys.com. The following distinguished name is of the user
object Ssmith in the noam.wingtiptoys.com domain.
cn=Ssmith,ou=Promotions,ou=Marketing,dc=noam,dc=wingtiptoys,dc=com
Note

Active Directory tools do not display the LDAP abbreviations for the naming
attributes domain component (dc=), organizational unit (ou=), common name (cn=),
and so forth. These abbreviations are shown only to illustrate how LDAP recognizes
the portions of the distinguished name. Most Active Directory tools display object
names in canonical form, as described later in this section. Because distinguished
names are difficult to remember, it is useful to have other means for retrieving objects.
Active Directory supports querying by attribute (for example, the building number
where you want to find a printer), so an object can be found without having to know
the distinguished name.
34

Relative Distinguished Name

The relative distinguished name of an object is the part of the name that is an attribute of the
object itself the part of the object name that identifies this object as unique from its siblings
at its current level in the naming hierarchy. Using the distinguished name mentioned earlier,
the relative distinguished name of the object is SSmith. The relative distinguished name of the
parent object is Promotions. The maximum length allowed for a relative distinguished name is
255 characters, but attributes have specific limits imposed by the directory schema. For
example, in the case of the common name (cn), which is the attribute type often used for
naming the relative distinguished name, the maximum number of characters allowed is 64.
Active Directory relative distinguished names are unique within a specific parent that is,
Active Directory does not permit two objects with the same relative distinguished name under
the same parent container. However, two objects can have identical relative distinguished
names but still be unique in the directory because within their respective parent containers,
their distinguished names are not the same. (For example, the object
cn=SSmith,dc=noam,dc=wingtiptoys,dc=com is recognized by LDAP as being different from
cn=SSmith,dc=wingtiptoys,dc=com.)
The relative distinguished name for each object is stored in the Active Directory database.
Each record contains a reference to the parent of the object. By following the references to the
root, the entire distinguished name is constructed during an LDAP operation.

Canonical Name
By default, the user interface in Windows 2000 and higher operating systems, displays object
names that use the canonical name, which lists the relative distinguished names from the root
downward and without RFC 1779 naming attribute descriptors; it uses the DNS domain name
(the form of the name where domain labels are separated by periods). For the LDAP
distinguished name in the previous example, the respective canonical name would appear as
follows: noam.wingtiptoys.com/marketing/promotions/ssmith
Note

If the name of an organizational unit contains a forward slash character (/), Active
Directory requires an escape character in the form of a backslash (\) to distinguish
between forward slashes that separate elements of the canonical name and the forward
slash that is part of the organizational unit name. The canonical name that appears in
Active Directory Users and Computers properties pages displays the escape character
immediately preceding the forward slash in the name of the organizational unit. For
example, if the name of an organizational unit is Promotions/Northeast and the name
of the domain is Wingtiptoys.com, the canonical name is displayed as
Wingtiptoys.com/Promotions\/Northeast.

Logon Names
A unique logon name is required for user security principals to gain access to a domain and its
resources. Security principals are objects to which Windows security is applied in the form of
authentication and authorization. Users are security principals, and they are authenticated
(their identity is verified) at the time they log on to the domain or local computer. They are
authorized (allowed or denied access) when they use resources.
35

In Windows 2000 and higher operating systems, user security principals require a unique
logon name to gain access to a domain and its resources. Security principal objects might be
renamed, moved, or contained within a nested domain hierarchy. The names of security
principal objects must conform to the following guidelines:

The name cannot be identical to any other user, computer, or group name in the
domain. It can contain up to 20 uppercase or lowercase characters except for the
following:" / \ [ ] : ; | = , + * ? <>

A user name, computer name, or group name cannot consist solely of periods (.) or
spaces.

The two types of logon names are user principal name and Security Account Manager account
names.
User Principal Name

In Active Directory, each user account has a user principal name (UPN) in the format
user@DNS-domain-name. A UPN is a friendly name assigned by an administrator that is
shorter than the LDAP distinguished name used by the system and easier to remember. The
UPN is independent of the DN of the user object, so a user object can be moved or renamed
without affecting the user logon name. When logging on using a UPN, users do not have to
choose a domain from a list on the logon dialog box.
The three parts of a UPN are the UPN prefix (user logon name), the @ character, and the
UPN suffix (usually a domain name). The default UPN suffix for a user account is the DNS
name of the Active Directory domain where the user account is located. For example, the
UPN for user Frank Miller, who has a user account in the Wingtiptoys.com domain (if
Wingtiptoys.com is the only domain in the tree), is FMiller@Wingtiptoys.com. The UPN is
an attribute (userPrincipalName) of the security principal object. If the userPrincipalName
attribute of a User object has no value, the User object has a default UPN of
userName@DnsDomainName.
If your organization has many domains forming a deep domain tree organized by department
and region, default UPN names can become unwieldy. For example, the default UPN for a
user might be Sales.westcoast.microsoft.com. The logon name for a user in that domain is
user@sales.westcoast.microsoft.com. Instead of accepting the default DNS domain name as
the UPN suffix, you can simplify both administration and user logon processes by providing a
single UPN suffix for all users. (The UPN suffix is used only within the Active Directory
domain and is not required to be a valid DNS domain name.) You can choose to use your email domain name as the UPN suffix userName@microsoft.com. This gives the user in the
example the UPN name of user@microsoft.com.
For a UPNbased logon, a global catalog might be necessary, depending on the user logging
on and the domain membership of the computer where the user logs on. A global catalog is
needed if the user logs on with a non-default UPN and the computer account of the user is in a
different domain than the user account of the user. For example, if, instead of accepting the
default DNS domain name as the UPN suffix (in the example
user@sales.westcoast.microsoft.com), you provide a single UPN suffix for all users (so that
the user then becomes simply user@microsoft.com), a global catalog is required for logon.

36

You use the Active Directory Domains and Trusts tool to manage UPN suffixes for a domain.
UPNs are assigned at the time a user is created. If you have created additional suffixes for the
domain, you can select from the list of available suffixes when you create the user or group
account. The suffixes appear in the list in the following order:

Alternate suffixes (if any; last one created appears first)

Root domain

The current domain

SAM Account Name

A Security Accounts Manager (SAM) account name is required for compatibility with
Windows NT 3.x and Windows NT 4.0 domains. The user interface in Windows 2000 or
higher operating systems, refers to the SAM account name as User logon name (preWindows 2000). There is no interoperability between Windows Server 2008 or higher
domains and Winows NT 3 and Windows NT 4.0 domains.
SAM account names are sometimes referred to as flat names because unlike DNS names
SAM account names do not use hierarchical naming. Because SAM names are flat, each
one must be unique in the domain.

Organizational Units
Active Directory allows administrators to create a hierarchy within a domain that meets the
needs of their organization. The object class of choice for building these hierarchies is the
organizationalUnit, a general-purpose container that can be used to group most other object
classes together for administrative purposes. An organizational unit in Active Directory is
analogous to a directory in the file system; it is a container that can hold other objects. You
can use organizational units for purposes such as creating an administrative hierarchy,
applying Group Policy, and delegating control of administration.
Administrative Hierarchy
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 a central authority can implement similar organizational unit
hierarchies. The structure is completely flexible, which allows organizations to create an
environment that mirrors the administrative model, whether it is centralized or decentralized.
Group Policy
Group Policy can be applied to organizational units to define the abilities of groups of
computers and users that are contained within the organizational units. Levels of control range
from complete desktop lockdown to a relatively autonomous user experience. Group Policy
can affect functionality, such as what applications are available to a group of users, what
features within an application are accessible on a particular computer, where documents are
saved, and can affect access and user permissions. Group Policy also affects where, when, and
how application and operating system updates or special scripts are applied.
37

Group Policy settings are stored as Group Policy objects in Active Directory. A Group Policy
object can be associated with one or more Active Directory containers, such as a site, domain,
or organizational unit.
Delegation of Control
The Active Directory object-based security model implements default access control that is
propagated down a subtree of container objects. You can use this technology to determine the
security for an entire group of objects according to the security that you set on the
organizational unit that contains the objects. By default, most Active Directory objects inherit
ACEs from the security descriptor on their parent container object. If necessary, you can
change the inherited permissions. However, as a best practice, you should avoid changing the
default permissions or inheritance settings on Active Directory objects unless you have
additional security requirements.
Note

Because Active Directory is indexed, you can organize the tree to match your
administrative model, instead of having to organize it for ease of browsing.

Inheritance enables the access control information defined at a container object in Active
Directory to apply to the security descriptors of any subordinate objects, including other
containers and their objects. One benefit this provides is that it eliminates the need to apply
permissions each time a child object is created. You can apply or delegate administrative
control over directory objects to organizational units by setting access control.
This inheritance of access effectively delegates administrative control to individuals in the
organization. The best way to take full advantage of delegation and inherited control on
directory objects is to organize the hierarchy to match the way that the directory is
administered.

User Accounts and Access Control

Active Directory authenticates and authorizes security principals such as user, inetorgperson,
and computer accounts to access shared resources on the network. The Local Security
Authority (LSA) is the security subsystem responsible for all interactive user authentication
and authorization services on a local computer. The LSA also processes authentication
requests made through the Kerberos V5 protocol or the NTLM protocol in Active Directory.
Once the identity of a user is verified in Active Directory, the LSA on the authenticating
domain controller creates a security access token for that user. An access token contains the
name of the user, the groups to which that user belongs, a SID for the user, SIDs included in
the SIDHistory property and all of the SIDs for the groups to which the user belongs.
The information in the access token is used to determine the level of access a user has to
resources whenever the user attempts to access them. The SIDs in the access token are
compared with the list of SIDs that make up the discretionary access control list (DACL) on
the resource to ensure that the user has sufficient permission to access the resource. This is
because the access control process identifies user accounts by SID rather than by name.
Note
38

When a domain controller provides an access token to a user, the access token only
contains information about membership in domain local groups if the domain local
groups are local to the domain where the domain controller is located.

User Authorization
In addition to securing network access through user authentication, Active Directory protects
shared resources by facilitating user authorization. Once a user logon has been authenticated
by Active Directory, the user rights assigned to the user through security groups and the
permissions assigned on the shared resource determine if the user will be authorized to access
that resource. This authorization process protects shared resources from unauthorized access
and permits access to only authorized users or groups.
Administrators can use access control to manage user access to shared resources for security
purposes. In Active Directory, access control is administered at the object level by setting
different levels of access, or permissions, to objects, such as Full Control, Write, Read,
Delete, or No Access. Access control in Active Directory defines how users can use Active
Directory objects. By default, most permissions on objects in Active Directory are at the most
secure setting.
The elements that define access control permissions on Active Directory objects include
security descriptors and the concept of object inheritance.
Security Descriptors

Access control permissions are assigned to securable objects and Active Directory objects to
control how different users can use each object. A securable object, or shared resource, is an
object that is intended to be used over a network by one or more users, and includes files,
printers, folders, and services. All securable objects and Active Directory objects store access
control permissions in security descriptors.
A security descriptor contains two access control lists (ACLs) used to assign and track
security information for each object: these are the discretionary access control list (DACL)
and the system access control list (SACL).
Discretionary access control lists (DACLs). DACLs identify the users and groups that are
assigned or denied access permissions on an object. If a DACL does not explicitly allow
access to a user, or to any group that a user is a member of, the user is implicitly denied
access to that object. By default, a DACL is controlled by the owner of an object or the person
who created the object (In Windows, the creator of an object is also the owner). The DACL
contains access control entries (ACEs) that determine user access to the object.
System access control lists (SACLs). SACLs identify the users and groups that you want to
audit when they successfully access or fail to access an object. Auditing is used to monitor
events related to system or network security, to identify security breaches, and to determine
the extent and location of any damage. By default, a SACL is controlled by the owner of an
object or the person who created the object. A SACL contains ACEs that determine whether
to record a successful or failed attempt by a user to access an object using a given permission,
for example, Full Control or Read.
Active Directory allows you to apply access control permissions to objects at very low levels,
including the ability to assign permissions on a per-attribute basis. To view DACLs and
39

SACLs on Active Directory objects using Active Directory Users and Computers, on the
View menu, click Advanced Features to access the Security tab for each object. You can also
use the DSACLS support tool to manage access control lists in Active Directory.
By default, DACLs and SACLs are associated with every Active Directory object, which
helps reduce attacks to your network by malicious users or any accidental mistakes made by
domain users.

Computer Accounts
Each computer account created in Active Directory has a relative distinguished name, a preWindows 2000 computer name (Security Accounts Manager account name), a primary DNS
suffix, a DNS host name, and a service principal name (SPN). The administrator enters the
computer name when creating the computer account. This computer name is used as the
LDAP relative distinguished name.
Active Directory suggests the pre-Windows 2000 name using the first 15 bytes of the relative
distinguished name. The administrator can change the pre-Windows 2000 name at any time.
The DNS name for a host is called a full computer name and is a DNS fully qualified domain
name (FQDN). The full computer name is a concatenation of the computer name (the first 15
bytes of the SAM account name of the computer account without the $ character) and the
primary DNS suffix (the DNS domain name of the domain in which the computer account
exists). It is listed on the Computer Name tab in System Properties in Control Panel.
By default, the primary DNS suffix portion of the FQDN for a computer must be the same as
the name of the Active Directory domain where the computer is located. To allow different
primary DNS suffixes, a domain administrator might create a restricted list of allowed
suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container.
This attribute is created and managed by the domain administrator using Active Directory
Service Interfaces (ADSI) or LDAP.
The SPN is a multivalue attribute. It is usually built from the DNS name of the host. The SPN
is used in the process of mutual authentication between the client and the server hosting a
particular service. The client finds a computer account based on the SPN of the service to
which it is trying to connect. The SPN can be modified by members of the Domain Admins
group.

Domain and Forest Protocols and Programming Interfaces

The primary protocol that is used by domain controllers in every domain throughout the forest
is LDAP, which runs on top of TCP/IP. LDAP is both a protocol and an API. In addition, the
secured communications between domain controllers must use the remote procedure call
(RPC) protocol for Messaging Application Programming Interface (MAPI), replication,
domain controller management, and SAM-related operations.
LDAP
LDAP is a directory service protocol that specifies directory communications. It runs directly
over TCP/IP, and it can also run over User Datagram Protocol (UDP) connectionless
transports. Clients can use LDAP to query, create, update, and delete information that is
40

stored in a directory service over a TCP connection through the TCP default port 389. Active
Directory supports LDAP v2 (RFC 1777) and LDAP v3 (RFC 3377). LDAP v3 is an industry
standard that can be used with any directory service that implements the LDAP protocol.
LDAP is the preferred and most common way of interacting with Active Directory.
Historically, LDAP is a simplified (lightweight) version of Directory Access Protocol (DAP),
which is the original protocol that was used to interact with X.500 directories. X.500 defines
an earlier set of standards that was developed by the International Organization for
Standardization (ISO). LDAP is simpler than DAP in two key ways:

Rather than using its own protocol stack according to the Open Systems
Interconnection (OSI) networking model, LDAP communicates over Internet Protocol
(IP) by using either UDP or TCP.

LDAP syntax is easier to use than DAP syntax.

For these reasons, LDAP is widely used and accepted as the standard protocol for directory
service access. The following key aspects characterize LDAP:

The protocol is carried directly over TCP for connection-oriented transport (receipt of
data is acknowledged) and over UDP for connectionless transport (sent or received
data is not acknowledged).

Most protocol data elements can be encoded as ordinary strings, for example, as
distinguished names.

Referrals to other servers can be returned to the client.

Simple Authentication and Security Layer (SASL) mechanisms can be used with
LDAP to provide associated security services. SASL Digest is supported as the
authentication standard for LDAP.

Attribute values and distinguished names can be internationalized using the ISO 10646
character set.

The protocol can be extended to support new operations, and controls can be used to
extend existing operations.

The schema is published through an attribute on the directory root object (rootDSE)
for use by clients.

For more information about LDAP, see How Active Directory Searches Work.
RPC
Active Directory uses remote procedure call (RPC) for replication (REPL) and domain
controller management communications, MAPI communications, and SAM-related
communications. RPC is a powerful, robust, efficient, and secure interprocess communication
(IPC) mechanism that enables data exchange and invocation of functionality located in a
different process. That different process can be on the same computer, on the local area
network (LAN), or across the Internet.

41

Authentication Protocols
Domain controllers authenticate users and applications by using one of two protocols: either
the Kerberos version 5 authentication protocol or the NTLM authentication protocol. When
two Active Directory domains or forests are connected by a trust, authentication requests
made using these protocols can be routed to provide access to resources in both forests.
NTLM
The NTLM version 2 (NTLMv2) authentication protocol is a challenge/response
authentication protocol. It is supported in Windows Server 2008, Windows Vista, Windows
Server 2003, Windows 2000, and Windows XP, but it is not the default authentication
protocol. Kerberos v5 is the default for these versions except when exchanging
communications with a computer running Windows NT Server 4.0 or earlier. Networks with
this configuration are referred to as mixed-mode. NTLM is also the authentication protocol
for computers that are not participating in a domain, such as stand-alone servers and
workgroups.
In Windows 7 and Windows Server 2008 R2, you can restrict the usage of NTLM. For more
information see, Introducing the Restriction of NTLM Authentication
(http://technet.microsoft.com/en-us/library/dd560653(WS.10).aspx)
When the NTLM protocol is used between a client and a server, the server must contact a
domain authentication service on a domain controller to verify the client credentials. The
server authenticates the client by forwarding the client credentials to a domain controller in
the client account domain.
Kerberos Version 5 Protocol
The Kerberos version 5 protocol is the default authentication protocol used by computers
running Windows 2000 or later operating system versions. This protocol is specified in RFC
1510 and is fully integrated with Active Directory, server message block (SMB), HTTP, and
RPC, as well as the client and server applications that use these protocols. In Active Directory
domains, the Kerberos protocol is used to authenticate logons when any of the following
conditions is true:

The user who is logging on uses a security account in an Active Directory domain.

The computer that is being logged on to has an operating system that is Windows 2000
or later.

The computer that is being logged on to is joined to an Active Directory domain.

The computer account and the user account are in the same forest.

The computer from which the user is trying to access resources is located in a nonWindows-based operating system Kerberos version 5 realm.

If any computer involved in a transaction does not support the Kerberos version 5 protocol,
the NTLM protocol is used.

42

The authentication protocol of choice for Active Directory authentication requests is Kerberos
V5. In contrast to NTLM, when the Kerberos protocol is used, the server does not have to
contact the domain controller. Instead, the client gets a ticket for a server by requesting one
from a domain controller in the server account domain; the server validates the ticket without
consulting any other authority.
For more information about Kerberos, see How the Kerberos Version 5 Authentication
Protocol Works.

Active Directory APIs

You can use the following application programming interfaces (APIs) to access information
in any LDAP directory including Active Directory:

Active Directory Service Interfaces (ADSI)

LDAP C API

REPL

MAPI

SAM

ADSI
Active Directory Service Interfaces (ADSI) provides a simple, powerful, object-oriented
interface to Active Directory. ADSI makes it easy for programmers and administrators to
create directory programs by using high-level tools, such as Microsoft Visual Basic, without
having to worry about the underlying differences between the different namespaces.
ADSI is supplied as a software development kit that enables you to build or buy programs that
give you a single point of access to multiple directories in your network environment, whether
those directories are based on LDAP or another protocol. ADSI is fully scriptable for ease of
use by administrators.
ADSI also enables access to Active Directory by exposing objects stored in the directory as
Component Object Model (COM) objects. A directory object is manipulated using the
methods available on one or more COM interfaces. ADSI has a provider-based architecture
that allows COM access to different types of directories for which a provider exists.
LDAP C
The LDAP C API, defined in Internet standard RFC 1823, is a set of low-level C-language
APIs to the LDAP protocol. Microsoft supports LDAP C APIs on all Windows platforms.
Developers have the choice of writing Active Directory-enabled applications using LDAP C
APIs or ADSI. LDAP C APIs are most often used to ease portability of directory-enabled
applications to the Windows platform. ADSI is a more powerful language and is more
appropriate for developers writing directory-enabled code on the Windows platform.

43

LDAP is the primary interface for the data store. Directory clients use LDAP v3 to connect to
the DSA through the LDAP interface. The LDAP interface is part of Wldap32.dll. LDAP v3
is backward compatible with LDAP v2.
REPL
The REPL management interface provides functionality for finding data about domain
controllers, converting the names of network objects between different formats, manipulating
SPNs and DSAs, and managing replication of servers.
MAPI
Messaging clients gain access to the Microsoft Exchange Server directory service by using
MAPI address book providers. For compatibility with existing messaging clients, Active
Directory supports the MAPI-RPC address book provider, which provides access to Active
Directory, for example, to find the telephone number of a user.
SAM
Security Accounts Manager (SAM) is a proprietary interface for connecting to the DSA on
behalf of clients that use Windows NT 4.0 or earlier. These clients use Windows NT 4.0
networking APIs to connect to the DSA through SAM. Replication with Windows NT 4.0
backup domain controllers (BDCs) goes through the SAM interface as well.

Domain and Forest Processes and Interactions

Many network related operations depend on domains and forests in order to complete various
tasks. This section describes some of the processes and interactions that commonly occur
within the boundaries of domains or forests.

Logging on to a Domain
When a user with an account in an Active Directory domain logs on at the keyboard of a
computer running a Windows 2000 or later operating system, the logon request is processed
in three stages:
1. The user requests admission to the ticket-granting service for the domain.
This is accomplished through an Authentication Service (AS) Exchange between the
Kerberos security support provider (SSP) on the computer and the Key Distribution
Center (KDC) in the domain in which the user account exists. The result is a ticketgranting ticket (TGT) that the user can present in future transactions with this KDC.
2. The user requests a ticket for the computer.
This is accomplished through a Ticket-Granting Service (TGS) Exchange between the
Kerberos SSP on the computer and the KDC for the domain in which the computer
account exists. The result is a session ticket that the user can present when he or she
requests access to system services on the computer.

44

3. The user requests admission to Local System services on the computer.

This is accomplished when the Kerberos SSP on the computer presents a session ticket
to the LSA on the computer.
If the account domain of the computer is different from the account domain of the user, an
extra step is involved. Before the Kerberos SSP can request a session ticket for the computer,
it must ask the KDC in the domain where the user account exists for a TGT that is good for
admission to the KDC in the domain where the computer account exists. The SSP can then
present the TGT to the KDC in the domain of the computer and get a session ticket for the
computer.
The precise steps in the logon process depend on how the computer is configured. With
standard configurations of Windows, interactive users log on with a password. In another
optional configuration of Windows, users log on with a smart card. Although the basic
process is the same for both configurations, there are some differences. For more information
about the domain logon process, see How Interactive Logon Works.

Processing Authentications Across Domains and Forests

When a request for authentication is referred to a domain, before the domain controller in that
domain authenticates the user to access resources in the domain, it must determine whether a
trust relationship exists with the domain from which the request comes, as well as the
direction of the trust and whether the trust is transitive or nontransitive. The authentication
process between trusted domains varies according to the authentication protocol in use. The
Kerberos version 5 and NTLM protocols in Windows 2000 Server, Windows Server 2003,
Windows Server 2008, and Window Server R2, process referrals for authentication to a
domain differently, as do other authentication protocols, such as Digest and SChannel, that
Windows 2000 Server, Windows Server 2003, Windows Server 2008, and Window Server R2
support.
In an Active Directory environment the Kerberos-based authentication process is most
commonly used. To access a shared resource in another domain by using Kerberos
authentication, a computer where the user logs on first requests a ticket from a domain
controller in its account domain to the server in the trusting domain that hosts the requested
resource. This ticket is then issued by an intermediary trusted by both the requesting computer
and the server. The computer then presents this trusted ticket to the server in the trusting
domain for authentication. This process, however, becomes more complex when a
workstation in one forest attempts to access data on a resource computer in another forest.
In this case, the Kerberos authentication process contacts the domain controller for a service
ticket to the SPN of the resource computer. Once the domain controller queries the global
catalog and determines that the SPN is not in the same forest as the domain controller, the
domain controller sends a referral for its parent domain back to the workstation. At that point,
the workstation queries the parent domain for the service ticket and continues to follow the
referral chain until it reaches the domain where the resource is located. For more detailed
information about how authentication requests are processed across domains and forests, see
How Domain and Forest Trusts Work.

Joining a Computer to a Domain

45

Joining a computer to a domain creates the computer account object for the client in an Active
Directory location where all computer accounts are created by default during a join operation.
The default location is set to the Computers container in Active Directory. A computer
account differs from a user account in that it identifies the computer to the domain, while a
user account identifies a user to a computer.
The act of joining a computer to a domain creates an account for the computer on the domain
if it does not already exist. When you join a client computer running Windows 2000 or later,
the following events occur:

The domain name is validated.

A domain controller in the domain is located through a call to the DsGetDcName API.

A session is established with the domain controller under the security context of the
passed-in credentials that are supplied in the Network Identification tab under
System Properties in Control Panel.

The computer account is enabled. If the flags so specify

(NETSETUP_ACCT_CREATE), the APIs create the computer account on the domain
controller.

The local password for this account is created in the Local Security Authority (LSA).

The local primary domain information LSA policy is set to refer to the new domain.
This includes the domain name and the domain SID.
Note
o

For clients running Windows 2000 or later, the LSA policy consists of the
domain name, domain SID, DNS domain name, DNS forest name, and domain
GUID.

The DNS name assigned to the local computer is updated.

The local group membership is changed to add members of the Domain Admins group
to the Local Accounts Administrators group.

The Net Logon trusted domain cache is initialized to the trusted domains domain list.

For clients running Windows 2000 or later, the Windows Time Service is enabled and
started.

The Net Logon service is started.

To join a workstation or member server to a domain, you can use the Netdom tool. For
example, to join a workstation to the Wingtiptoys.com domain in the engineering
organizational unit, type the following command at the workstation:
Netdom join /d:wingtiptoys.com /OU:OU=engineering,DC=wingtiptoys,DC=com

46

When a computer joins a domain, the following changes occur on domain controllers running
Windows 2000 Server, Windows Server 2003, Windows Server 2008 and Window Server
2008 R@:

A computer object is created. The name of this object is generated by appending a

dollar sign ($) to the name (uppercase letters) of the client.

On Windows 2000 Server and later versions of Microsoft Server operating systems
based domain controllers only, the Net Logon service creates SPNs on the computer
object.

Netsetup.log

When joining a computer to an Active Directory domain, the Networking Setup (NetSetup)
utility installs all the necessary Microsoft supported networking components. The
Netsetup.log file provides information about attempts to join domains and records any errors
that might prevent the join operation from succeeding.

Registering DNS Names and Locating Domain Controllers

When a Windows 2000 Server and later versions of Microsoft Server operating systems
based member server is promoted to a domain controller by installing Active Directory, the
Net Logon service registers the DNS resource records necessary for network hosts and
services to locate the domain controller on the network. When network hosts and services
attempt an operation (such as joining a domain) that requires a domain controller, the locator
mechanism attempts to locate the domain controller through DNS.
DNS is used because every Active Directorybased domain controller dynamically registers
SRV records in DNS. The SRV records enable servers to be located by service type (for
example, LDAP) and protocol (for example, TCP). Because domain controllers are LDAP
servers that communicate over TCP, SRV records can be used to find the DNS computer
names of domain controllers. In addition to registering LDAP-specific SRV records, Net
Logon also registers Kerberos v5 authentication protocolspecific SRV records to enable
locating servers that run the Kerberos Key Distribution Center (KDC) service.
Domain controllers not only register their DNS domain names on a DNS server, but also
register their NetBIOS names by using a transport-specific mechanism (for example, WINS).
Thus, a DNS client locates a domain controller by querying DNS, and a NetBIOS client
locates a domain controller by querying the appropriate transport-specific name service. The
domain controller locator service consists of two main parts:

Locator finds which domain controllers are registered with a DNS server.

Locator submits a DNS query to the DNS server to locate a domain controller in the
specified domain.

After this query is resolved, an LDAP User Datagram Protocol (UDP) lookup is sent to one or
more of the domain controllers listed in the response to the DNS query to ensure their
availability. Finally, the Net Logon service caches the discovered domain controller to aid in
resolving future requests.

47

For more information about the DC Locator process, see How DNS Support for Active
Directory Works.

Raising Domain and Forest Functional Levels

When Active Directory is installed on a server, a set of basic Active Directory features is
enabled by default. In addition to the basic Active Directory features on individual domain
controllers, there are new domain- and forest-wide Active Directory features available when
all domain controllers in a domain or forest are running Windows Server 2003. This also
holds true for Windows Server 2008 and Windows Server 2008 R2.
To enable the new domain-wide features, all domain controllers in the domain must be
running Windows Server 2003, and the domain functional level must be raised to Windows
Server 2003. To enable new forest-wide features, all domain controllers in the forest must be
running Windows Server 2003, and the forest functional level must be raised to Windows
Server 2003. The same is true for Windows Server 2008 and Windows Server 2008 R2.
Before raising the forest functional level to Windows Server 2003, verify that all domains in
the forest are set to the domain functional level of Windows 2000 native or Windows
Server 2003. Note that domains that are set to the domain functional level of Windows 2000
native will automatically be raised to Windows Server 2003 at the same time the forest
functional level is raised to Windows Server 2003. For more detailed information about
Windows Server 2008 and Windows Server 2008 R2 functional levels, see the How Active
Directory Functional Levels Work.

Replicating Directory Partitions

Active Directory uses RPC over IP to transfer replication data between domain controllers.
RPC over IP is used for both intersite and intrasite replication. To keep data secure while in
transit, RPC over IP replication uses both authentication (using the Kerberos V5
authentication protocol) and data encryption.
When a direct or reliable IP connection is not available, replication between sites can be
configured to use the Simple Mail Transfer Protocol (SMTP). However, SMTP replication
functionality is limited, and requires an enterprise certification authority (CA). SMTP can
only be used to replicate the configuration, schema and application directory partitions, and
does not support the replication of domain directory partitions. For more detailed information
about the replication process, see How Active Directory Replication Topology Works.

48