How Domains and Forests Work

Welcome > Windows Server 2003 Technical Reference > Technologies Collections > Active Directory Collection > Active Directory Structure and Storage
Technologies > Domains and Forests Technical Reference
In this section
Domain and Forest Structure
Active Directory Objects
Domain and Forest Protocols and Programming Interfaces
Domains and Forests 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.
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.
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.
How Domains and Forests Work
Domain and Forest Structure
Back to Top
Page 1 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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 cross-references 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 cross-reference:
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 cross-reference 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.
To reference external directories by a name that is within the Active Directory namespace (a name that is
Page 2 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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 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 n-1, 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
Page 3 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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, 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 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
Page 4 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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 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).
Important
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
Page 5 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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
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
Page 6 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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; 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 2003-based 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.
Note
WINS and NetBIOS are not required in an environment where computers run only Windows 2000, Windows XP
or Windows Server 2003, but WINS is required for interoperability between Windows 2000 Server- and
Windows Server 2003-based 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.
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- and Windows Server 2003-based computers in general and
Windows 2000 Server- and Windows Server 2003-based domain controllers in particular.
For more information about domain names, see "How DNS Support for Active Directory Works."
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
Active Directory Objects
Back to Top
Page 7 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
as a security ID (SID), is used on security-enabled 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; 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, Windows XP and Windows Server 2003 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
Page 8 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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 the Windows 2000
Server and Windows Server 2003 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.
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.
Relative Distinguished Name
Page 9 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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, Windows XP, and Windows Server 2003 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.
In the Windows 2000, Windows XP and Windows Server 2003 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
Page 10 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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 [email protected]. 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 [email protected]. 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 e-mail domain name as the UPN suffix -
[email protected]. This gives the user in the example the UPN name of [email protected].
For a UPN-based 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
[email protected]), you provide a single UPN suffix for all users (so that the user then becomes
simply [email protected]), a global catalog is required for logon.
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, Windows XP, and Windows Server 2003 refers to
the SAM account name as User logon name (pre-Windows 2000).
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.
Page 11 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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.
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.
Important
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
Page 12 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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 Windows Server 2003 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 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 pre-Windows 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
Page 13 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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.
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 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 in Windows Server 2003 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
Domain and Forest Protocols and Programming
Interfaces
Back to Top
Page 14 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
(LAN), or across the Internet.
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 protocol is the default protocol used for network authentication in the Windows NT 4.0 operating system.
For compatibility reasons, it is used by Active Directory domains to process network authentication requests that
come from earlier Windows-based clients and servers. Computers running Windows 2000, Windows XP or Windows
Server 2003 use NTLM only when authenticating to servers running Windows NT 4.0 and when accessing resources
in Windows NT 4.0 domains.
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,
Windows XP Professional, or Windows Server 2003. 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 is a Windows 2000, Windows XP or Windows Server 2003-based
computer.
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 non-Windows-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.
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 Kerberos 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 Interface (ADSI)
LDAP C API
REPL
MAPI
SAM
Page 15 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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.
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.
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
Windows 2000, Windows XP or Windows Server 2003, 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
Domain and Forest Processes and Interactions
Back to Top
Page 16 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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 ticket-granting 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.
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 and Windows Server 2003 process
referrals for authentication to a domain differently, as do other authentication protocols, such as Digest and
SChannel, that Windows 2000 Server and Windows Server 2003 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
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 NT 4.0, Windows 2000, Windows XP or Windows
Server 2003 to an Active Directory domain, the following events occur:
Page 17 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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
For clients running Windows 2000, Windows XP and Windows Server 2003 only, 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, Windows XP and Windows Server 2003 only, 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
When a computer joins a domain, the following changes occur on domain controllers running Windows NT 4.0,
Windows 2000 Server and Windows Server 2003:
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 Windows Server 2003-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-based server or Windows Server 2003-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 Directory-based 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 protocol-specific SRV records to enable locating servers that run the Kerberos
Key Distribution Center (KDC) service.
Page 18 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
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.
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 running Windows Server 2003, 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.
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.
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 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."
The following tables list the network ports that are associated with domains and forests.
Port Assignments for Raising Active Directory Functional Levels

Port Assignments for Data Store
Network Ports Used by Domains and Forests
Back to Top
Service Name UDP TCP
LDAP 389 389
LDAP SSL N/A 636
Page 19 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...

Port Assignments for Service Publication and SPNs

Port Assignments for Raising Active Directory Searches

Port Assignments for Global Catalogs
Service Name UDP TCP
LDAP 389 389
LDAP SSL N/A 636
RPC Endpoint Mapper 135 135
Global Catalog LDAP N/A 3268
Global Catalog LDAP SSL N/A 3269
Service Name UDP TCP
LDAP 389 389
LDAP SSL N/A 636
RPC Endpoint Mapper 135 135
Global Catalog LDAP N/A 3268
Global Catalog LDAP SSL N/A 3269
Kerberos 88 88
Service Name UDP TCP
LDAP 389 389
LDAP SSL N/A 636
Global Catalog LDAP N/A 3268
Global Catalog LDAP SSL N/A 3269
Service Name UDP TCP
LDAP N/A 3268
LDAP N/A 3269 (global catalog Secure Sockets Layer [SSL])
LDAP 389 389
LDAP N/A 686 (SSL)
RPC/REPL 135 135 (endpoint mapper)
Kerberos 88 88
DNS 53 53
SMB over IP 445 445
Page 20 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...

Port Assignments for Replication

Port Assignments for Operations Masters

Port Assignments for Interactive Logon

Port Assignments for Kerberos V5 Protocol

Port Assignment for DC Locator
Service Name UDP TCP
LDAP 389 389
LDAP N/A 686 (SSL)
RPC/REPL N/A 135 (endpoint mapper)
LDAP N/A 3268
Kerberos 88 88
DNS 53 53
SMB over IP 445 445
Service Name UDP TCP
LDAP 389 389
LDAP N/A 686 (SSL)
RPC/REPL N/A 135 (endpoint mapper)
Netlogon N/A 137
Kerberos 88 88
DNS 53 53
SMB over IP 445 445
Service Name UDP TCP
Kerberos 88 88
Local Security Authority (LSA) RPC Dynmaic RPC Dynamic RPC
NTLM Dynamic Dynamic
Service Name UDP TCP
DNS 53 53
Kerberos 88 88
Page 21 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...

The following table shows the list of ports that might need to be opened before you establish trusts.
Ports Required for Trusts
Service Name UDP TCP
LDAP 389 389
Task Outbound Ports Inbound Ports From-To
Set up trusts on both sides from the
internal forest
LDAP (389 UDP and
TCP)
Microsoft SMB (445
TCP)
Kerberos (88 UDP)
Endpoint resolution -
portmapper (135 TCP)
Net Logon fixed port
N/A Internal domain domain
controllers-External domain
domain controllers (all
ports)
Trust validation from the internal
forest domain controller to the
external forest domain controller
(outgoing trust only)
LDAP (389 UDP)
Microsoft SMB (445
TCP)
Endpoint resolution -
portmapper (135 TCP)
Net Logon fixed port
N/A Internal domain domain
controllers-External domain
domain controllers (all
ports)
Use Object picker on the external
forest to add objects that are in an
internal forest to groups and DACLs
N/A LDAP (389 UDP and
TCP)
Windows NT Server 4.0
directory service fixed
port
Net Logon fixed port
Kerberos (88 UDP)
Endpoint resolution
portmapper (135 TCP)
External server-Internal
domain PDCs (Kerberos)
External domain domain
controllers-Internal domain
domain controllers (Net
Logon)
Set up trust on the external forest
from the external forest
N/A LDAP (389 UDP and
TCP)
Microsoft SMB (445
TCP)
Kerberos (88 UDP)
External domain domain
controllers-Internal domain
domain controllers (all
ports)
Use Kerberos authentication (internal
forest client to external forest)
Kerberos (88 UDP) N/A Internal client-External
domain domain controllers
(all ports)
Use NTLM authentication (internal
forest client to external forest)
N/A Endpoint resolution -
portmapper (135 TCP)
Net Logon fixed port
External domain domain
controllers-Internal domain
domain controllers (all
ports)
Join a domain from a computer in the
internal network to an external
domain
LDAP (389 UDP and
TCP)
Microsoft SMB (445
N/A Internal client-External
domain domain controllers
(all ports)
Page 22 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...


The following resources contain additional information that is relevant to this section.
Active Directory Schema Technical Reference
Data Store Technical Reference
DNS Support for Active Directory Technical Reference
Active Directory Replication Model Technical Reference
Logon and Authentication Technologies
Domain Controller Roles
Search and Publication Technologies
Installation, Upgrade, and Migration Technologies
Windows Support Tools
TCP)
Kerberos (88 UDP)
Endpoint resolution -
portmapper (135 TCP)
Net Logon fixed port
Windows NT Server 4.0
directory service fixed
port
Related Information
Back to Top
Nanage Your Profile ] Legal ] Contact Us
© 2005 Nicrosoft Corporation. All rights reserved. Terms of Use ] Trademarks ] Privacy Statement
Page 23 of 23 How Domains and Forests Work - Directory Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...