Active Directory

Active Directory
Typically Active Directory is managed using the graphical Microsoft Management Console.
Active Directory is a technology created by Microsoft that provides a variety of network

services, including:
• Lightweight Directory Access Protocol LDAP is the industry standard directory access
protocol, making Active Directory widely accessible to management and query
applications. Active Directory supports LDAPv3 and LDAPv2.
• Kerberos-based authentication
• DNS-based naming and other network information (Guts of DNS, Stable DNS is needed
for AD to work properly)
• Central location for network administration and delegation of authority [2]
• Information security and single sign-on for user access to networked based resources [3]
• The ability to scale up or down easily [4]
• Central storage location for application data [5]
• Synchronization of directory updates amongst several servers [6]
Using the same database, for use primarily in Windows environments, Active Directory also
allows administrators to assign policies, deploy software, and apply critical updates to an
organization. Active Directory stores information and settings in a central database. Active
Directory networks can vary from a small installation with a few computers, users and printers to
tens of thousands of users, many different domains and large server farms spanning many
geographical locations.
Active Directory was previewed in 1999, released first with Windows 2000 Server edition, and
revised to extend functionality and improve administration in Windows Server 2003. Additional
improvements were made in Windows Server 2003 R2. Active Directory was refined further in
Windows Server 2008 and Windows Server 2008 R2 and was renamed Active Directory
Domain Services.
Active Directory was called NTDS (NT Directory Service) in older Microsoft documents. This
name can still be seen in some Active Directory binaries.
Structure
Objects
Everything that Active Directory tracks is considered an object. An object is any user, system,
computer, resource, or service tracked within Active Directory. The generic term object is used
because Active Directory is capable of tracking a variety of items, and many objects can share
common attributes.
An Active Directory structure is a hierarchical framework of objects. The objects fall into two
broad categories: resources (e.g., printers) and security principals (user or computer accounts and
groups). Security principals are Active Directory objects that are assigned unique security
identifiers (SIDs) used to control access and set security.
Each object represents a single entity — whether a user, a computer, a printer, or a group — and
its attributes. Certain objects can also be containers of other objects. An object is uniquely
identified by its name and has a set of attributes — the characteristics and information that the
object can contain — defined by a schema, which also determines the kinds of objects that can
be stored in Active Directory.
Each attribute object can be used in several different schema class objects. The schema object
exists to allow the schema to be extended or modified when necessary. However, because each
schema object is integral to the definition of Active Directory objects, deactivating or changing
these objects can have serious consequences because it will fundamentally change the structure
of Active Directory itself. A schema object, when altered, will automatically propagate through
Active Directory and once it is created it can only be deactivated — not deleted. Changing the
schema usually requires a fair amount of planning.[1]
Sites
A Site object in Active Directory represents a geographic location that hosts networks. Sites
contain objects called subnets.[2] Sites can be used to assign Group Policy Objects, facilitate the
discovery of resources, manage active directory replication, and manage network link traffic.
Sites can be linked to other Sites. Site-linked objects may be assigned a cost value that represents
the speed, reliability, availability, or other real property of a physical resource. Site Links may
also be assigned a schedule.
Forests, trees, and domains

All objects inside a common directory database is known as a domain. Each domain stores
information only about the objects that belong to that domain. A tree consists of a single domain
or multiple domains in a contiguous namespace. A forest is a collection of Trees and represents
the outermost boundary within which users, computers, groups, and other objects exist. The
forest is the security boundary for Active Directory.
Domain-Dallas
OU-
F Marketing
or Donn
es
Mark
t-
W Steve
id OU-Sales
ge Bill
ts Ralph
C
or
p
Tree-Eastern
Domain-
Boston
Domain-
NewYork
Domain-
Philly
Tree-Southern
Domain-
Atlanta
Domain-
Dallas
Example of the geographical organizing of zones of

interest within trees and domains.
The Active Directory framework that holds the objects can be viewed at a number of levels. At
the top of the structure is the forest. A forest is a collection of multiple trees that share a common
global catalog, directory schema, logical structure, and directory configuration. The forest, tree,
and domain are the logical parts in an Active Directory network.
The Active Directory forest contains one or more transitive, trust-linked trees. A tree is a
collection of one or more domains and domain trees in a contiguous namespace, again linked in a
transitive trust hierarchy. Domains are identified by their DNS name structure, the namespace.
Flat-filed, simulated hierarchy

The objects held within a domain can be grouped into containers called Organizational Units
(OUs).[3] OUs give a domain a hierarchy, ease its administration, and can give a resemblance of
the structure of the organization in organizational or geographical terms. OUs can contain OUs –
indeed, domains are containers in this sense – and can hold multiple nested OUs. Microsoft
recommends as few domains as possible in Active Directory and a reliance on OUs to produce
structure and improve the implementation of policies and administration. The OU is the common
level at which to apply group policies, which are Active Directory objects themselves called
Group Policy Objects (GPOs), although policies can also be applied to domains or sites (see
below). The OU is the level at which administrative powers are commonly delegated, but
granular delegation can be performed on individual objects or attributes as well.
However, Organizational Units are just an abstraction for the administrator, and do not function
as true containers; the underlying domain operates as if objects were all created in a simple flat-
file structure, without any OUs. It is not possible for example to create two user accounts with an
identical username (sAMAccountName) in two separate OUs, such as "fred.staff-ou.domain" and
"fred.student-ou.domain." This is so because sAMAccountName, a user object attribute, is
constrained to be unique across the entire domain. However, note that you can have two different
"Freds" within AD, each with his own different account name (sAMAccountName) - for e.g.
Fred Smith (fsmith), and Fred A. Smith (fasmith). Note that they are both Fred Smiths, albeit one
with a middle initial, they have different account names (sAMAccountName) - fsmith, and
fasmith.
By contrast, there are other vendor directories such as Novell eDirectory that allow certain
naming attribute duplication across separate OUs. Each user logs in by specifying the context of
their account, which is similar to the current working directory of a file system. Context
normally operates in relative form: if the login prompt context is "staff-ou.accounts-
ou.organization," people with accounts in that specific OU need only type their username "fred."
But if the login prompt context were set to be one level higher, at "accounts-ou.organization,"
people would need to specify the OU within that context: "fred.staff-ou." Context can also be
specified in absolute form similar to an absolute directory path by using a leading period:
".fred.staff-ou.accounts-ou.organization," which disregards the current login prompt context.
Novell additionally provides login prompt functionality known as contextless login[4] to permit
searching the directory structure via LDAP for all possible matching or similar usernames,
making the Novell login process operate similar to Microsoft's flat-file structure that searches the
entire domain for accounts regardless of the account's location in the OUs. The concept of
account context in the directory does not apply to Active Directory, since object name
duplication within a single domain is not permitted to occur in the first place.
Because duplicate usernames cannot exist within separate OUs of a single active directory
domain, unique account name generation poses a significant challenge for organizations with
hundreds to thousands of users that are part of a generalized mass that can not be easily
subdivided into separate domains, such as students in a public school system or university that
must be able to login on any computer across the district buildings or campus network.
As the number of users in a domain increases, simple username creation methods such as "first
initial, middle initial, last name" will fail due to having so many common names like Smith or
Johnson in the collective mass that result in having duplications, such as two JASmith, which
requires randomly adding a number to the end (JASmith1) to further differentiate it for one of the
two people. At some point of increasingly many users and name duplications, the network IT
staff may give up on attempts at making usernames personally memorable, and the username
simply becomes a serial number 5 to 10 digits long to provide sufficient naming uniqueness
within a single domain.
Structural divisions to improve performance
Active Directory also supports the creation of Sites, which are physical, rather than logical,
groupings defined by one or more IP subnets.[5] Sites distinguish between locations connected by
low-speed (e.g., WAN, VPN) and high-speed (e.g., LAN) connections. Sites are independent of
the domain and OU structure and are common across the entire forest. Sites are used to control
network traffic generated by replication and also to refer clients to the nearest domain
controllers. Exchange 2007 also uses the site topology for mail routing. Policies can also be
applied at the site level.
The actual division of an organization's information infrastructure into a hierarchy of one or

more domains and top-level OUs is a key decision. Common models are by business unit, by
geographical location, by IT Service, or by object type. These models are also often used in
combination. OUs should be structured primarily to facilitate administrative delegation, and
secondarily, to facilitate group policy application. Although OUs form an administrative
boundary, the only true security boundary is the forest itself[6] and an administrator of any
domain in the forest must be trusted across all domains in the forest.
Physically the Active Directory information is held on one or more equal peer domain controllers
(DCs), replacing the NT PDC/BDC model. Each DC has a copy of the Active Directory; changes
on one computer being synchronized (converged) between all the DC computers by multi-master
replication. Servers joined to Active Directory that are not domain controllers are called Member
Servers.[7]
The Active Directory database is split into different stores or partitions.[8] Microsoft often refers
to these partitions as 'naming contexts'.[9] The 'Schema' partition contains the definition of object
classes and attributes within the Forest. The 'Configuration' partition contains information on the
physical structure and configuration of the forest (such as the site topology). The 'Domain'
partition holds all objects created in that domain. The first two partitions replicate to all domain
controllers in the Forest. The Domain partition replicates only to Domain Controllers within its
domain. A subset of objects in the domain partition is also replicated to domain controllers that
are configured as global catalogs.
Unlike earlier versions of Windows, which used NetBIOS to communicate, Active Directory is
fully integrated with DNS and TCP/IP—DNS is required. To be fully functional, the DNS server
must support SRV resource records or service records.
Active Directory replication is 'pull' rather than 'push'.[10] The Knowledge Consistency Checker
(KCC) creates a replication topology of site links using the defined sites to manage traffic.
Intrasite replication is frequent and automatic as a result of change notification, which triggers
peers to begin a pull replication cycle. Intersite replication intervals are less frequent and do not
use change notification by default, although this is configurable and can be made identical to
intrasite replication. A different 'cost' can be given to each link (e.g., DS3, T1, ISDN etc.) and
the site link topology will be altered accordingly by the KCC. Replication between domain
controllers may occur transitively through several site links on same-protocol site link bridges, if
the cost is low, although KCC automatically costs a direct site-to-site link lower than transitive
connections. Site-to-site replication can be configured to occur between a bridgehead server in
each site, which then replicates the changes to other DCs within the site.
In a multi-domain forest the Active Directory database becomes partitioned. That is, each
domain maintains a list of only those objects that belong in that domain. So, for example, a user
created in Domain A would be listed only in Domain A's domain controllers. Global catalog
(GC) servers are used to provide a global listing of all objects in the Forest.[11] The Global
catalog is held on domain controllers configured as global catalog servers. Global Catalog
servers replicate to themselves all objects from all domains and hence, provide a global listing of
objects in the forest. However, in order to minimize replication traffic and to keep the GC's
database small, only selected attributes of each object are replicated. This is called the partial
attribute set (PAS). The PAS can be modified by modifying the schema and marking attributes
for replication to the GC.
Replication of Active Directory uses Remote Procedure Calls (RPC over IP [RPC/IP]). Between
Sites you can also choose to use SMTP for replication, but only for changes in the Schema,
Configuration, or Partial Attribute Set (Global Catalog) NCs. SMTP cannot be used for
replicating the default Domain partition.[12]
The Active Directory database, the directory store, in Windows 2000 Server uses the JET Blue-
based Extensible Storage Engine (ESE98), limited to 16 terabytes and 1 billion objects in each
domain controller's database. Microsoft has created NTDS databases with more than 2 billion
objects.[citation needed] (NT4's Security Account Manager could support no more than 40,000 objects).
Called NTDS.DIT, it has two main tables: the data table and the link table. In Windows Server
2003 a third main table was added for security descriptor single instancing.[13]
The features of Active Directory may be accessed programmatically via the COM interfaces
provided by Active Directory Service Interfaces.[14]
Active Directory is a necessary component for many Windows services in an organization such
as Exchange, Security.
FSMO Roles
Flexible Single Master Operations (FSMO, sometimes pronounced "fizz-mo") roles are also
known as operations master roles. Although the AD domain controllers operate in a multi-master
model, i.e. updates can occur in multiple places at once, there are several roles that are
necessarily single instance:
Role Name Scope Description

Controls and handles updates/modifications to the Active
Schema Master 1 per forest
Directory schema.
Domain
Controls the addition and removal of domains from the forest if
Naming 1 per forest
present in root domain
Master
Provides backwards compatibility for NT4 clients for PDC
operations (like password changes). The PDCs also run domain
specific processes such as the Security Descriptor Propagator
PDC Emulator 1 per domain (SDPROP), and is the master time server within the domain. It
also handles external trusts, the DFS consistency check, holds
the most current passwords and manages all GPOs as default
server.
Allocates pools of unique identifier to domain controllers for
RID Master 1 per domain
use when creating objects
Synchronizes cross-domain group membership changes. The
Infrastructure 1 per infrastructure master cannot run on a global catalog server
Master domain/partition (GCS)(unless all DCs are also GCs, or environment consists of
a single domain)
Trust
To allow users in one domain to access resources in another, Active Directory uses trusts.[15]
Trusts inside a forest are automatically created when domains are created. The forest sets the
default boundaries of trust, not the domain, and implicit, transitive trust is automatic for all
domains within a forest. As well as two-way transitive trust, AD trusts can be a shortcut (joins
two domains in different trees, transitive, one- or two-way), forest (transitive, one- or two-way),
realm (transitive or nontransitive, one- or two-way), or external (nontransitive, one- or two-way)
in order to connect to other forests or non-AD domains.[16]
Trusts in Windows 2000 (native mode)
• One-way trust – One domain allows access to users on another domain, but the other
domain does not allow access to users on the first domain.
• Two-way trust – Two domains allows access to users on both domains.
• Trusting domain – The domain that allows access to users from a trusted domain.
• Trusted domain – The domain that is trusted; whose users have access to the trusting
domain.
• Transitive trust – A trust that can extend beyond two domains to other trusted domains
in the forest.
• Intransitive trust – A one way trust that does not extend beyond two domains.
• Explicit trust – A trust that an admin creates. It is not transitive and is one way only.
• Cross-link trust – An explicit trust between domains in different trees or in the same tree
when a descendant/ancestor (child/parent) relationship does not exist between the two
domains.
Windows 2000 Server – supports the following types of trusts:
• Two-way transitive trusts.

• One-way intransitive trusts.
Additional trusts can be created by administrators. These trusts can be:
• Shortcut
Windows Server 2003 offers a new trust type – the forest root trust. This type of trust can be
used to connect Windows Server 2003 forests if they are operating at the 2003 forest functional
level. Authentication across this type of trust is Kerberos based (as opposed to NTLM). Forest
trusts are also transitive for all the domains in the forests that are trusted. Forest trusts, however,
are not transitive.
ADAM/AD LDS
Active Directory Application Mode (ADAM) is a light-weight implementation of Active
Directory. ADAM is capable of running as a service, on computers running Microsoft Windows
Server 2003 or Windows XP Professional. ADAM shares the code base with Active Directory
and provides the same functionality as Active Directory, including an identical API, but does not
require the creation of domains or domain controllers.
Like Active Directory, ADAM provides a Data Store, which is a hierarchical datastore for
storage of directory data, a Directory Service with an LDAP Directory Service Interface. Unlike
Active Directory, however, multiple ADAM instances can be run on the same server, with each
instance having its own and required by applications making use of the ADAM directory service.
In Windows Server 2008, ADAM has been renamed AD LDS (Lightweight Directory Services).
[17]
Integrating Unix into Active Directory

Varying levels of interoperability with Active Directory can be achieved on most Unix-like
operating systems through standards compliant LDAP clients, but these systems usually lack the
automatic interpretation of many attributes associated with Windows components, such as Group
Policy and support for one-way trusts.
There are also third-party vendors who offer Active Directory integration for Unix platforms
(including UNIX, Linux, Mac OS X, and a number of Java- and UNIX-based applications).
Some of these vendors include Centrify (DirectControl), Computer Associates (UNAB),
CyberSafe Limited (TrustBroker), Likewise Software (Open or Enterprise), Quest Software
(Authentication Services) and Thursby Software Systems (ADmitMac). The open source Samba
software provides a way to interface with Active Directory and join the AD domain to provide
authentication and authorization: version 4 (in alpha as of October 2009) can act as a peer Active
Directory domain controller.[18]. Microsoft is also in this market with their free Microsoft
Windows Services for UNIX product.
The schema additions shipped with Windows Server 2003 R2 include attributes that map closely
enough to RFC 2307 to be generally usable. The reference implementation of RFC 2307,
nss_ldap and pam_ldap provided by PADL.com, contains support for using these attributes
directly, provided they have been populated. The default Active Directory schema for group
membership complies with the proposed extension, RFC 2307bis. Windows Server 2003 R2
includes a Microsoft Management Console snap-in that creates and edits the attributes.
An alternate option is to use another directory service such as 389 Directory Server (formerly
Fedora Directory Server) or Sun Microsystems Sun Java System Directory Server, which can
perform a two-way synchronization with Active Directory and thus provide a "deflected"
integration with Active Directory as Unix and Linux clients will authenticate to FDS and
Windows Clients will authenticate to Active Directory. Another option is to use OpenLDAP with
its translucent overlay, which can extend entries in any remote LDAP server with additional
attributes stored in a local database. Clients pointed at the local database will see entries
containing both the remote and local attributes, while the remote database remains completely
untouched.
Active Directory Operations Guide
Managing Sites
Updated: January 06, 2003
On This Page
Overview
The KCC and Replication Topology
Bridgehead Server Selection
Site Management Tasks and Procedures
Adding a New Site
Procedures for Adding a New Site
Adding a Subnet to the Network
Procedures for Adding a Subnet
Linking Sites for Replication
Procedures for Creating a Site Link
Changing Site Link Properties
Procedures for Configuring Site Links
Moving a Domain Controller to a Different Site
TCP/IP Settings
Preferred Bridgehead Server Status
Procedures for Moving a Domain Controller to a Different Site
Removing a Site
Procedures for Removing a Site
Overview
An Active Directory site object represents a collection of Internet Protocol (IP) subnets, usually constituting a
physical Local Area Network (LAN). Multiple sites are connected for replication by site link objects.
Sites are used in Active Directory to:
• Enable clients to discover network resources (printers, published shares, domain controllers) that are
close to the physical location of the client, reducing network traffic over Wide Area Network (WAN) links.
• Optimize replication between domain controllers.
Managing sites in Active Directory involves adding new subnet, site, and site link objects when the network grows,
as well as configuring a schedule and cost for site links. You can modify the site link schedule, cost, or both, to
optimize intersite replication. When conditions no longer require replication to a site, you can remove the site and
associated objects from Active Directory.
Large hub-and-spoke topology management is beyond the scope of this documentation. For information about
managing Active Directory branch office deployments that include more than 200 sites, see the "Active Directory
Branch Office Guide Series" at
http://www.microsoft.com/technet/archive/windows2000serv/technologies/activedirectory/deploy/adguide/default.
mspx.
Using the SMTP intersite replication transport is beyond the scope of this documentation. For information about
SMTP replication, see "Active Directory Replication" in the Distributed Systems Guide of the Microsoft Windows
2000 Server Resource Kit and see the "Step-by-Step Guide to Setting up ISM-SMTP Replication." To download this
guide, see the Active Directory link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources.
Automatic site coverage is a default condition for Windows 2000 domain controllers. Operations and guidelines
documented in this guide are consistent with the enabling of automatic site coverage.
Top of page
The KCC and Replication Topology
The Knowledge Consistency Checker (KCC) uses site link configuration information to enable and optimize
replication traffic by generating a least-cost replication topology. Within a site, for each directory partition, the KCC
builds a ring topology that minimizes the number of hops between domain controllers. Between sites, the KCC
creates a spanning tree of all intersite connections. Therefore, adding sites and domains increases the processing
that is required by the KCC. Before adding to the site topology, be sure to consider the guidelines discussed in
"Adding a New Site" later in this document.
Significant changes to site topology can affect domain controller hardware requirements. For more information
about domain controller hardware requirements, see "Domain Controller Capacity Planning" in "Best Practice Active
Directory Design for Managing Windows Networks." To download this guide, see the Active Directory link on the
Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
Top of page
Bridgehead Server Selection
By default, bridgehead servers are automatically selected by the intersite topology generator (ISTG) in each site.
Alternatively, you can use Active Directory Sites and Services to select preferred bridgehead servers. However, it is
recommended for Windows 2000 deployments that you donot select preferred bridgehead servers.
Selecting preferred bridgehead servers limits the bridgehead servers that the KCC can use to those that you have
selected. If you use Active Directory Sites and Services to select any preferred bridgehead servers at all in a site,
you must select as many as possible and you must select them for all domains that must be replicated to a
different site. If you select preferred bridgehead servers for a domain and all preferred bridgehead servers for that
domain become unavailable, replication of that domain to and from that site does not occur.
If you have selected one or more bridgehead servers, removing them from the bridgehead servers list restores the
automatic selection functionality to the ISTG.
Top of page
Site Management Tasks and Procedures
Table 1.21 shows the tasks and procedures for managing sites, as well as the tools and the recommended
frequency for performing each task. After you configure sites, subnets, and site links for the initial deployment,
most site management activity is limited to responding to changes in network conditions.
Table 1.21 Site Management Tasks and Procedures
Tasks Procedures Tools Frequency
Add a new site. • Create a site object. • Active As needed
• Create a subnet object and associate Directory Sites
it with the site.or and Services
• Associate an existing subnet object

with the site.
• Create a site link object, if
appropriate.
• Remove the site from a site link, if
appropriate.
Add a subnet to the • Obtain the network address and • Active As needed
network.
subnet mask for the subnet. Directory Sites
• Create a subnet object and associate and Services
it with a site.
Link sites for replication. • Determine the names of the sites • Active As needed
you are linking. Directory Sites

• Create a site link object. and Services
• Determine the ISTG role owner for a

site.
• Generate the replication topology on
the ISTG, if appropriate.
Change site link • Configure the site link schedule. • Active As needed
properties.
• Configure the site link interval. Directory Sites
and Services
• Configure the site link cost.

site.
Move a domain • Change the static IP address of the • My Network As needed
controller to a different
domain controller. Places
site.
• Create a delegation for the domain • Active
controller, if appropriate. Directory Sites
• Verify that the IP address maps to a and Services
subnet and determine the site • DNS snap-in

association.
• Determine whether the server is a
preferred bridgehead server.
• Configure the domain controller to
not be a preferred bridgehead server, if
appropriate.
• Move the server object to a different
site.
Remove a site. • Determine whether the server object • Active As needed
has child objects. Directory Sites

• Delete the server object or objects and Services
from the site.

• Delete the site link object, if
appropriate.
• Associate the subnet or subnets with
a different site.or
• Delete the subnet objects.
• Delete the site object.

site.
Top of page
Adding a New Site
Design teams or network architects might want to add sites as part of ongoing deployment. Although you typically
create subnets to accommodate all address ranges in the network, you do not need to create sites for every
location. Generally, sites are required for those locations that have domain controllers or other servers that run
applications that depend on site topology, such as Distributed File System (DFS). When such locations are
separated from other network locations by a WAN link, create a site object to optimize resource location, Active
Directory replication, and domain controller location for clients.
When the need for a site arises, the design team typically provides details about the placement and configuration
of site links for the new site, as well as subnet assignments or creation if subnets are needed.
KCC calculations for generating the intersite topology for a Windows 2000 forest can cause directory performance
to suffer when the combined sites, site links, and domains exceed certain limits. When these limits are reached,
follow the site administration guidelines on the Active Directory Branch Office Planning Guide link on the Web
Resources page at http://www.microsoft.com/windows/reskits/webresources.
As a general guideline, when any of the following conditions exist, consult your design team before adding a new
site:
• An existing site is directly connected to more than 20 sites.
• A bridgehead server has more than 20 inbound connections.
• The forest has 200 or more sites.
Top of page
Procedures for Adding a New Site
Use the following procedures to add a new site. Procedures are explained in detail in the linked topics.
1. Create a site object and add it to an existing site link.
2. Associate a range of IP addresses with the site, as follows:
• Create a subnet object or objects and associate them with the new site.
or
• Associate an existing subnet object with the new site.
3. Create a site link object, if appropriate, and add the new site and at least one other site to the site link.
4. If, while performing procedure 1, you added the new site to an existing site link temporarily in order to
create the site, remove the site from that site link.
Top of page
Adding a Subnet to the Network
If a new range of IP addresses is added to the network, create a subnet object in Active Directory to correspond to
the range of IP addresses. When you create a new subnet object, you must associated it with a site object. You can
either associate the subnet with an existing site, or create a new site first and then create the subnet and associate
it with the new site. If you are going to create a new site for the new network segment, see "Adding a New Site."
Top of page
Procedures for Adding a Subnet
Use the following procedures to add a subnet. Procedures are explained in detail in the linked topics.
1. Obtain the network address and subnet mask for the new subnet.
2. Create a subnet object and associate it with the appropriate site.
Top of page
Linking Sites for Replication

To link sites for replication, create a site link object in the IP transport container and add two or more sites to the
link. Use a naming convention that includes the sites that you are linking. For example, if you want to link the site
named Seattle to the site named Boston, you might name the site link SEA-BOS.
After you add two or more site names to a site link object, the bridgehead servers in the respective sites replicate
between the sites according to the replication schedule, cost, and interval settings on the site link object. For
information about modifying the default settings, see "Changing Site Link Properties."
At least two sites must exist when you create a site link. If you are adding a site link to connect a new site to an
existing site, create the new site first and then create the site link. For information about creating a site, see
"Adding a New Site."
Top of page
Procedures for Creating a Site Link
Use the following procedures to link sites for replication. Procedures are explained in detail in the linked topics.
1. Determine the names of the sites you are linking.
2. Create a site link object in the IP container and add the appropriate sites to it.
3. Generate the intersite topology. By default, the KCC runs every 15 minutes to generate the replication
topology. To initiate replication topology generation immediately, use the following procedures to refresh
the intersite topology:
a. Determine the ISTG role owner for the site.
b. Generate the replication topology on the ISTG.
Top of page
Changing Site Link Properties
To control which sites replicate directly with each other and when, use the cost, schedule, and interval properties
on the site link object.
These settings control intersite replication as follows:
• Schedule: The time during which replication can occur (the default setting allows replication at all times).
• Interval: The number of minutes between replication polling by intersite replication partners within the
open schedule window (default is every 180 minutes).
• Cost: The relative priority of the link (default is 100). Lower relative cost increases the priority of the link
over other higher-cost links.
Consult your design documentation for information about values to set for site link properties.
Top of page
Procedures for Configuring Site Links

Use the following procedures to configure a site link. Procedures are explained in detail in the linked topics.
1. Configure the site link schedule to identify times during which intersite replication can occur.
2. Configure the site link interval to identify how often replication polling can occur during the schedule
window.
3. Configure the site link cost to establish a priority for replication routing.
4. Generate the intersite replication topology, if appropriate. By default, the KCC runs every 15 minutes to
generate the replication topology. To initiate intersite replication topology generation immediately, use the
following procedures to refresh the topology:
a. Determine the ISTG role owner for the site.
Top of page
Moving a Domain Controller to a Different Site
If you change the IP address or the subnet-to-site association of a domain controller after Active Directory is
installed on the server, the server object does not change sites automatically. You must move it to the new site
manually. When you move the server object, the Net Logon service on the domain controller registers DNS SRV
resource records for the appropriate site.
Top of page
TCP/IP Settings
When you move a domain controller to a different site, if an IP address of the domain controller is statically
configured, then you must change the TCP/IP settings accordingly. The IP address of the domain controller must
map to a subnet object that is associated with the site to which you are moving the domain controller. If the IP
address of a domain controller does not match the site in which the server object appears, the domain controller
must communicate over a potentially slow WAN link to locate resources rather than locating resources in its own
site.
Prior to moving the domain controller, ensure that the following TCP/IP client values are appropriate for the new
location:
• IP address, including the subnet mask and default gateway.
• DNS server addresses.
• WINS server addresses (if appropriate).
If the domain controller that you are moving is a DNS server, you must also:
• Change the TCP/IP settings on any clients that have static references to the domain controller as the
preferred or alternate DNS server.

• Determine whether the parent DNS zone of any zone that is hosted by this DNS server contains a
delegation to this DNS server. If yes, update the IP address in all such delegations. For information about
creating DNS delegations, see "Performing Active Directory Post-Installation Tasks."
Top of page
Preferred Bridgehead Server Status
Before moving any server object, check the server object to see whether it is acting as a preferred bridgehead
server for the site. This condition has ISTG implications in both sites, as follows:
• Site to which you are moving the server: If you move a preferred bridgehead server to a different
site, it becomes a preferred bridgehead server in the new site. If preferred bridgehead servers are not
currently in use in this site, the ISTG behavior in this site changes to support preferred bridgehead
servers. For this reason, you must either configure the server to not be a preferred bridgehead server
(recommended), or select additional preferred bridgehead servers in the site (not recommended).
• Site from which you are moving the server: If the server is the last preferred bridgehead server in the
original site for its domain, and if other domain controllers for the domain are in the site, the ISTG selects
a bridgehead server for the domain. If you use preferred bridgehead servers, always select more than one
server as preferred bridgehead server for the domain. If after the removal of this domain controller from
the site multiple domain controllers remain that are hosting the same domain and only one of them is
configured as a preferred bridgehead server, either configure the server to not be a preferred bridgehead
server (recommended), or select additional preferred bridgehead servers hosting the same domain in the
site (not recommended).
Note: If you select preferred bridgehead servers and all selected preferred bridgehead servers for a domain are
unavailable in the site, the ISTG does not select a new bridgehead server. In this case, replication of this domain to
and from other sites does not occur. However, if no preferred bridgehead server is selected for a domain or
transport (through administrator error or as the result of moving the only preferred bridgehead server to a
different site), the ISTG automatically selects a preferred bridgehead server for the domain and replication
proceeds as scheduled.
Top of page
Procedures for Moving a Domain Controller to a Different Site
Use the following procedures to move a domain controller to a different site. Procedures are explained in detail in
the linked topics.
1. Change the static IP address of the domain controller. This procedure includes changing all appropriate
TCP/IP values, including preferred and alternate DNS servers, as well as WINS servers (if appropriate).
Obtain these values from the design team.
2. Create a delegation for the domain controller, if appropriate. If the parent DNS zone of any zone that is
hosted by this DNS server contains a delegation to this DNS server, use this procedure to update the IP
address in all such delegations.
3. Verify that the IP address maps to a subnet and determine the site association to ensure that the subnet
is associated with the site to which you are moving the server object.
4. Determine whether the server is a preferred bridgehead server.
5. If the server is a preferred bridgehead server in the current site and you do not want the server to be a
preferred bridgehead server in the new site, configure the server to not be a preferred bridgehead server.
6. Move the server object to the new site.
Top of page
Removing a Site
If domain controllers are no longer needed in a network location, you can remove them from the site and then
delete the site object. Before deleting the site, you must remove domain controllers from the site either by
removing it entirely or by moving it to a new location.
• To remove the domain controller, remove Active Directory from the server and then delete the server
object from the site in Active Directory. For information about removing a domain controller, see
"Decommissioning a Domain Controller."
• To retain the domain controller in a different location, move the domain controller to a different site
and then move the server object to the respective site in Active Directory. For information about moving a
domain controller, see "Moving a Domain Controller to a Different Site."
Domain controllers can host other applications that depend on site topology and publish objects as child objects of
the respective server object. For example, when MOM or Message Queuing are running on a domain controller,
these applications create child objects beneath the server object. In addition, a Message Queuing server that is not
a domain controller and is configured to be a Message Queuing Routing Server creates a server object in the Sites
container. Removing the application from the server automatically removes the child object below the respective
server object. However, the server object is not removed automatically.
When all applications have been removed from the server (no child objects appear beneath the server object), you
can remove the server object. After the application is removed from the server, a replication cycle might be
required before child objects are no longer visible below the server object.
After you delete or move the server objects but before you delete the site object, reconcile the following objects:
• Subnet object or objects for the site IP addresses:
• If the addresses are being reassigned to a different site, associate the subnet object or objects
with that site. Any clients using the addresses for the decommissioned site will thereafter be assigned
automatically to the other site.
• If the IP addresses will no longer be used on the network, delete the corresponding subnet object
or objects.
• Site link object or objects. You might need to delete a site link object, as follows:
• If the site you are removing is added to a site link containing only two sites, delete the site link
object.
• If the site you are removing is added to a site link that contains more than two sites, do not
delete this site link object.

Before deleting a site, obtain instructions from the design team for reconnecting any other sites that might be
disconnected from the topology by removing this site. If the site you are removing is added to more than one site
link, it might be an interim site between other sites that are added to this site link. Deleting the site might
disconnect the outer sites from each other. In this case, the site links must be reconciled according to the
instructions of the design team.
Top of page
Procedures for Removing a Site
Use the following procedures to remove a site. Procedures are explained in detail in the linked topics.
1. Determine whether the server object has child objects. If a child object appears, do not delete the server
object. If a domain controller has been decommissioned and one or more child objects appears below the
server object, replication might not have completed. If replication has completed and child objects exist,
do not delete the server object. Contact a supervisor.
2. Delete the server objects within the Servers container of the site that you are removing.
3. Delete the site link object, if appropriate. Obtain this information from the design team.
4. Associate the subnet or subnets with the appropriate site, if appropriate. If you no longer want to use the
IP addresses associated with the subnet object or objects, delete the subnet objects. Obtain this
information from the design team.
5. Delete the site object.
6. Generate the intersite replication topology, if appropriate. By default, the KCC runs every 15 minutes to
generate the replication topology. To initiate intersite replication topology generation immediately, use the
following procedures to refresh the topology:
a. Determine the ISTG role owner in the site.
7. Organizational Units
8. 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 class 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.
Administrative Hierarchy
9. 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.
10. For information about planning and implementing an organizational unit hierarchy, see "Designing the
Active Directory Structure" in the Deployment Planning Guide .
11. Top of page
Group Policy
12. 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 access and user permissions. Group Policy also
affects where, when, and how application and operating system updates or special scripts are applied.
13. 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.
14. For more information about Group Policy, see "Introduction to Desktop Management," "Software
Installation and Maintenance," and "Group Policy" in this book.
15. Top of page
Delegation of Control
16. The Windows 2000 object-based security model implements default access control that is propagated
down a particular subtree of container objects. You 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, which 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.
17. Note
18. Because Active Directory is indexed, there is no need to organize the tree for ease of browsing, which is
likely to run counter to administrative objectives.
19. Administrative control over directory objects can be applied — or delegated — to organizational units
through access control. (For more information about administrative control, see "Delegation of
Administration" later in this chapter.)
Sites overview
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server
2003 with SP2
Sites overview
Sites in Active Directory® represent the physical structure, or topology, of your network. Active Directory uses
topology information, stored as site and site link objects in the directory, to build the most efficient replication
topology. You use Active Directory Sites and Services to define sites and site links. A site is a set of well-connected
subnets. Sites differ from domains; sites represent the physical structure of your network, while domains represent
the logical structure of your organization.
Using sites
Sites help facilitate several activities within Active Directory, including:
• Replication. Active Directory balances the need for up-to-date directory information with the need for
bandwidth optimization by replicating information within a site more frequently than between sites. You
can also configure the relative cost of connectivity between sites to further optimize replication. For more
information, see Replication between sites and Managing replication.
• Authentication. Site information helps make authentication faster and more efficient. When a client logs
on to a domain, it first searches its local site for a domain controller to authenticate against. By
establishing multiple sites, you can ensure that clients authenticate against domain controllers nearest to
them, reducing authentication latency and keeping traffic off WAN connections.
• Active Directory-enabled services. Active Directory-enabled services can leverage site and subnet
information to enable clients to locate the nearest server providers more easily. For information about
services, see Services.
Defining sites using subnets

In Active Directory, a site is a set of computers well-connected by a high-speed network, such as a local area
network (LAN). All computers within the same site typically reside in the same building, or on the same campus
network. A single site consists of one or more Internet Protocol (IP) subnets. Subnets are subdivisions of an IP
network, with each subnet possessing its own unique network address. A subnet address groups neighboring
computers in much the same way that postal codes group neighboring postal addresses. The following figure shows
several clients within a subnet that defines an Active Directory site.
Sites and subnets are represented in Active Directory by site and subnet objects, which you create through Active
Directory Sites and Services. Each site object is associated with one or more subnet objects.
For information about creating sites, see Create a site.
For information about creating subnets, see Create a subnet.
For information about subnets, see "Introduction to TCP/IP" at the Microsoft Windows Resource Kits Web site.
Assigning computers to sites

Computers are assigned to sites based on their Internet Protocol (IP) address and subnet mask. Site assignment is
handled differently for clients and member servers than for domain controllers. For a client, site assignment is
dynamically determined by its IP address and subnet mask during logon. For a domain controller, site membership
is determined by the location of its associated server object in Active Directory. For more information, see "Active
Directory Replication" at the Microsoft Windows Resource Kits Web site.
For information about associating subnets with sites, see Associate a subnet with a site.
For information about establishing single or multiple sites, see When to establish a single or separate sites.
Understanding sites and domains

In Active Directory, sites map the physical structure of your network, while domains map the logical or
administrative structure of your organization. This separation of physical and logical structure provides the
following benefits:
• You can design and maintain the logical and physical structures of your network independently.
• You do not have to base domain namespaces on your physical network.
• You can deploy domain controllers for multiple domains within the same site. You can also deploy domain
controllers for the same domain in multiple sites.

Specifying Security and Administrative Boundaries
2003 with SP2
The Active Directory forest represents the outermost boundary within which users, computers, groups, and other
objects exist; that is, the forest is the security boundary for Active Directory. Active Directory domains, unlike
Windows NT domains, are always part of a forest, and they are not themselves the ultimate security boundary. For
Windows 2000 and later networks, though, domains are the boundaries for administration and for certain security
policies, such as password complexity and password reuse rules, which cannot be inherited from one domain to
another. Each Active Directory domain is authoritative for the identity and credentials of the users, computers, and
groups that reside in that domain. However, service administrators have abilities that cross domain boundaries. For
this reason, the forest is the ultimate security boundary, not the domain.
Important
Previously published Active Directory documentation states that a domain is a security boundary, but this
documentation does not provide specific details about the level of autonomy and isolation that is possible among
domains in a forest. Although a domain is, in fact, a security boundary with regard to the management of
security policies for Active Directory, it does not provide complete isolation in the face of possible attacks by
service administrators.
Delegating Administration
Organizations typically delegate the administration of all or part of the Active Directory service or the data that is
stored in their domains. Table 2 lists the reasons for delegating administration.
Table 2 Reasons to Delegate Administration
Reasons Explanation
Organizational One part of an organization might want to share an infrastructure to reduce costs, but it
requires operational independence from the rest of the organization.
Operational One part of an organization or a single application might place unique constraints on the
directory service configuration, availability, or security. Examples include:
Military organizations
Hosting scenarios
Extranet-based directory services
Legal Some organizations have legal requirements that compel them to operate in a specific manner,
such as restricting information access. Examples include:
Financial institutions
Defense contractors
Government organizations
For these reasons, an organization might need to delegate control over service management, data management, or
both. The goal of delegation is to achieve either autonomy or isolation:
• Autonomy is the ability of administrators to manage independently part or all of the Active Directory
service or the data in the directory or on member computers.
• Isolation is the ability of administrators to prevent other administrators from interfering in or accessing
part or all of the Active Directory service or the data in the directory or on member computers.
An organization’s requirements for service autonomy, data autonomy, service isolation, and data isolation
determine the Active Directory infrastructure that is best suited to its needs. The first step is to define precisely the
needs of your organization.
Active Directory boundaries can assist an organization in achieving the level of autonomy and isolation that its
business units require. Table 3 provides a comparison of the characteristics of administrative autonomy and
isolation.
Table 3 Comparison of the Characteristics of Autonomy and Isolation in Administration
Administrative
Role Autonomy means to… Isolation means to…
Service Manage independently all or part of service Prevent other service administrators from
administrator administration (service autonomy). controlling or interfering with service
administration (service isolation).
Data Manage independently all or part of the data Prevent other data administrators from
administrator that is stored in Active Directory or on controlling or viewing data in Active Directory
member computers (data autonomy). or on member computers (data isolation).
Autonomy is less constrained than isolation. Administrators who require only autonomy accept the fact that other
administrators of equal or higher privilege in the system have equivalent or overriding control in the forest.
Because autonomy is less constrained than isolation, it is generally less costly and more efficient to delegate
administrative autonomy.
Autonomy can be achieved by delegating service or data administration. Isolation requires that a business unit
deploy a separate forest to contain its administrators, users, and resources. Multiple forests in an organization
require external trusts to support collaboration. These trusts are discussed further in Establishing Secure
Collaboration with Other Forests later in this guide.
For a complete discussion of the effects of autonomy and isolation and the service and data administrator roles,
see “Designing the Active Directory Logical Structure” in Designing and Deploying Directory and Security Services
of the Windows Server 2003 Deployment Kit (or see “Designing the Active Directory Logical Structure” on the Web
at http://go.microsoft.com/fwlink/?LinkId=4723).
Trusting Service Administrators

Before choosing an Active Directory delegation model, consider the following facts about Active Directory
administrative roles:
• Forest owners maintain the right to control domain-level services and to access data that is stored in any
domain in the forest.
• Domain owners maintain the right to access data that is stored in the domain or on its member
computers.
• Domain owners, although operating autonomously from forest owners and other domain owners, cannot
prevent a malicious domain owner from controlling their services and accessing their data.
The need for a high degree of collaboration and trust among the authorities that are responsible for the
management of domains in a forest requires that all administrators who manage domains be highly trusted.
Therefore, Active Directory domains in a forest should never be deployed with the objective of isolating business
units that do not trust each other.
To summarize the facts concerning directory structures and directory structure owners, if an organization joins a
forest or domain infrastructure, the organization administrators must agree to trust all service administrators in the
forest and in all domains. Trusting service administrators means to:
• Believe that service administrators look out for the organization’s best interest. Organizations should not
elect to join a forest or domain if the organization fears that the owner of the forest or domain might
behave maliciously.
• Believe that service administrators follow best practices for service administrators and for restriction of
physical access to domain controllers.
• Understand and accept the risks to the organization that are associated with rogue administrators and
coerced administrators.
• Planning for domain controllers and member servers

• Updated: January 21, 2005
• Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows
Server 2003 with SP2
Planning for domain controllers and member servers
• With Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows
Server 2003, Datacenter Edition; servers in a domain can have one of two roles: domain controllers,
which contain matching copies of the user accounts and other Active Directory data in a given domain,
and member servers, which belong to a domain but do not contain a copy of the Active Directory data. (A
server that belongs to a workgroup, not a domain, is called a stand-alone server.) It is possible to change
the role of a server back and forth from domain controller to member server (or stand-alone server), even
after Setup is complete. However, it is recommended that you plan your domain before running Setup and
change server roles (and server names) only when necessary.
• Multiple domain controllers provide better support for users, compared to a single domain controller. With
multiple domain controllers, you have multiple copies of user account data and other Active Directory
data; however, it is still important to perform regular backups, including Automated System Recovery
backups, and familiarize yourself with the methods for restoring a domain controller. In addition, multiple
domain controllers work together to support domain controller functions, such as carrying out logon
validations.
Directory data store

2003 with SP2
Directory data store

The Active Directory directory service uses a data store for all directory information. This data store is often
referred to as the directory. The directory contains information about objects such as users, groups, computers,
domains, organizational units, and security policies. This information can be published for use by users and
administrators.
The directory is stored on domain controllers and can be accessed by network applications or services. A domain
can have one or more domain controllers. Each domain controller has a copy of the directory for the entire domain
in which it is located. Changes made to the directory on one domain controller are replicated to other domain
controllers in the domain, domain tree, or forest. Active Directory uses four distinct directory partition types to
store and copy different types of data. Directory partitions contain domain, configuration, schema, and application
data. This storage and replication design provides directory information to users and administrators throughout the
domain.
Directory data is stored in the Ntds.dit file on the domain controller. It is recommended that you store this file on
an NTFS partition. For more information about the tool used to manage the Active Directory database and log files,
see Files in Ntdsutil. Private data is stored securely, and public directory data is stored on a shared system volume
where it can be replicated to other domain controllers in the domain. For more information about replication, see
Replication overview.
Directory data replicated between domain controllers includes the following:
• Domain data
The domain data holds information about objects within a domain. This is information such as e-mail
contacts, user and computer account attributes, and published resources that are of interest to
administrators and users.
For example, when a user account is added to your network, a user account object and attribute data are
stored in the domain data. When changes to your organization's directory objects occur, such as object
creation, deletion, or attribute modification, this data is stored in the domain data.
• Configuration data
The configuration data describes the topology of the directory. This configuration data includes a list of all
domains, trees, and forests and the locations of the domain controllers and global catalogs.
• Schema data
The schema is the formal definition of all object and attribute data that can be stored in the directory.
Domain controllers running Windows Server 2003 include a default schema that defines many object
types, such as user and computer accounts, groups, domains, organizational 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.
For more information, see Schema.
• Application 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 are not part of the
directory data store by default; they must be created, configured, and managed by the administrator.
For more information, see Application directory partitions.
Note
• If a domain controller is also a global catalog, it stores a subset of the directory data for all other domains
in the forest. For more information about domain controllers, see Domain controllers. For more
information about the global catalog, see The role of the global catalog.
Quotas and directory partitions

Quotas, a new feature with domain controllers running Windows Server 2003 , determine the number of objects
that can be owned in a given directory partition by a security principal. (The owner of an object is usually, but not
always, the creator of the object.) Quotas can help prevent the denial of service that can occur if a security
principal accidentally, or intentionally, creates objects until the affected domain controller runs out of storage
space.
Quotas are specified and administered for each directory partition separately. The schema partition, however, has
no quotas. On a given directory partition, you can assign quotas for any security principal, including users,
inetOrgPersons, computers, and groups. Members of the Domain Admins and Enterprise Admins groups are exempt
from quotas. In some cases, a security principal might be covered by multiple quotas. For example, a user might
be assigned an individual quota, and also belong to one or more security groups that also have quotas assigned to
them. In such cases, the effective quota is the maximum of the quotas assigned to the security principal.
If a security principal is not assigned a quota either directly or through a group membership, a default quota on the
partition governs the security principal. If you do not explicitly set the default quota on a given partition, the
default quota of that partition is unlimited (ie, there is no limit).
Tombstone objects owned by a security principal are also counted as part of the quota consumption of that security
principal. For each partition, you can specify a tombstone quota factor to determine the percentage weight given to
a tombstone object in quota accounting. For example, if the tombstone quota factor for a given partition is set to
25 (or 25%), then a tombstone object on the partition is counted as 0.25 (or ¼) of a normal object. If a quota of
100 is specified for a user on this partition, then the user could own a maximum of 100 normal objects, or a
maximum 400 tombstone objects. The default tombstone quota factor for each partition is initially set to 100 (or
100%), meaning that normal and tombstones objects are weighted equally.
The following example illustrates how quotas can be used. Consider the domain "sales.northwindtraders.com."
Because this domain supports a lot of printing activity, the domain contains several print servers that each support
1,000 or more print queues. Initially, the default quota of the sales.northwindtraders.com domain partition is set to
unlimited. To help control the number of objects created and owned, the administrator specifies a default quota of
500. Now, each user can own a maximum of 500 objects on the partition. Because print queues are directory
objects that are created and owned by the respective print servers, the new default quota of 500 limits each print
server to 500 print queues. To remove this constraint, the administrator creates a group called "Print Servers" and
adds the computer account of each print server to the group. The administrator then specifies a quota of 2,000 for
the Print Servers group. Now, each print server can support its original number of print queues, while the default
quota continues to prevent excess object creation by all other security principals.
Only domain controllers running Windows Server 2003 can enforce quotas. Quotas are enforced only on originating
directory operations; quotas are not enforced on replicated operations. In order for quotas to be fully effective for
any given directory partition, all domain controllers that contain a writable copy of that partition must be running
Windows Server 2003 . Therefore, for quotas to be effective on a domain directory partition, all domain controllers
in that domain must be running Windows Server 2003 . For quotas to be effective on the configuration partition, all
domain controllers in the forest must by running Windows Server 2003 .
Active Directory Replication Traffic

By Andreas Luther—Microsoft Enterprise Services
Editor's Note This article is excerpted from "Optimizing Network Traffic," which is part of the Microsoft Press
Notes From the Field series that outlines the best system management practices and procedures. For more
information on this and other Microsoft Press books, go to http://www.microsoft.com/mspress/.
On This Page
Introducton
Replication Architecture
Replication Topology
How to Measure Replication Traffic
Traffic Scenarios
Summary of Network Traffic Analysis
Introducton
The Windows 2000 Active Directory extends the replication model introduced in Microsoft Exchange Server 4.0—a
directory based on a database and a flexible replication engine. The new Active Directory model uses an updated
replication architecture to meet the needs for an enterprise directory service. The new design results in finer
replication granularity and an architecture that allows administrators to tune replication for specific environments,
controlling what is replicated to whom, how, and when. Active Directory replication is designed to work well without
tuning, but if you have to perform tuning you'll need a solid understanding of the architecture and the resulting
network traffic.
This chapter introduces the new Active Directory replication architecture, shows how to detect network packets
that are caused by replication, and presents some network traffic statistics that will help you define an efficient
replication topology. It is not a complete discussion of this topic—that level of detail is available in other sources—
but is instead intended as a functional overview useful for implementation planning.
Top of page
Replication Architecture
The Active Directory is made up of one or more naming contexts or partitions. A naming context is a contiguous
sub-tree of the directory (such as the directory schema) that is a unit of replication. In the Active Directory each
domain controller always holds at least three naming replicas:
• The schema
• The configuration (replication topology and related metadata)
• One or more domain naming contexts (sub-trees containing the actual objects in the directory)
The schema container defines the objects (such as users) and attributes (such as telephone numbers) that can be
created in the Active Directory, and the rules for creating and manipulating them. Schema information (which
attributes are mandatory for object creation, what additional attributes can be set, and what attribute data types
are used) is replicated to all domain controllers to ensure that objects are created and manipulated in accordance
with the rules.
The configuration container includes information about the Active Directory as a whole—what domains exist,
what sites are available, what domain controllers are running in the particular sites and domains, and what
additional services are offered. All enterprise domain controllers need this information to make operational
decisions (such as choosing replication partners) so it is replicated to all of them.
A domain naming context holds objects such as users, groups, computers, and organizational units. A full domain
naming context replica contains a read-write replica of all information in the domain—all objects and attributes. A
domain controller holds a full replica of its domain naming context. A partial domain naming context replica
contains a read-only subset of the information in the domain—all objects, but only selected attributes. A domain
controller that's a global catalog (GC) server contains a partial replica of every other domain in the forest (and a
full replica of its own domain.)
GC servers speed up enterprise-wide directory searches by acting as indexers for the enterprise, holding in their
database a copy of selected attributes for all enterprise objects—a small set of common object attributes typically
meaningful in searches: first and last names for user objects, locations for printers, etc. Thus the GC optimizes a
search for, say, a specific color-printer, by consulting its database. Even if the specific attribute is not found in the
GC database, the user or application can at least find out which domain controllers to contact for more information.
Besides that, global catalogs are also needed for logon operations. GCs servers map user principal names
(FredG@Acme.com) to accounts (HQ.Acme.com\FredG). Only GC servers know all user memberships in universal
groups, so the logon process must communicate to a GC to add the security IDs (SIDs) of the universal groups to
the user's access token, if the user is a member of a universal group.
Normal replication mechanisms keep GC server partial domain replicas up to date. When Active Directory builds a
replication topology for a naming context, it includes the partial domain replicas. Thus, a partial domain replica
cannot act as a replication source for a full domain replica, because the partial domain replica only knows about a
subset of attributes. A partial domain replica can act as a replication source for another partial domain replica. This
allows for very low-cost topologies.
Object Model
Objects in the Active Directory are defined by their attributes' types and values. An object receives its identity from
its Global Unique Identifier (GUID—the only attribute that cannot be changed). It keeps track of a system object in
the Active Directory even after a move between domains changes its distinguished name (DN).
As noted, the schema defines which attributes can be used on objects. The Active Directory's Extensible Storage
Engine (ESE) reserves space only for attributes with actual values set on them (attributes containing values). This
helps conserve database space because user objects have more than 100 defined attributes, but only 20 to 30 are
commonly used. Using this model, the replication engine minimizes traffic by replicating only object attributes that
have values assigned, and only attributes with values that have changed since the last replication.
Multi-Master Replication
The Windows 2000 Active Directory uses a multi-master replication topology that allows you to use any domain
controller to manipulate the domain database and to replicate changes to its replication partners.
Domain controllers use update sequence numbers (USNs) to see if replication partners are up to date. In the case
of collisions (when the same attribute of the same object is manipulated on two domain controllers at the same
time) the last writer wins. To determine last writer status, an algorithm checks: attribute version number, then
attribute timestamp, then the GUIDs of the domain controllers that performed the write operation. This ensures
that the attribute value is determined consistently and locally, reducing communication between domain
controllers.
Top of page
Replication Topology
Replication efficiency is enhanced by a flexible replication topology that can reflect the structure of an existing
network. The Active Directory's replication topology generator runs as part of the Knowledge Consistency
Checker (KCC). You feed the KCC information on the cost of sending data from one location to another, and which
domain controllers are running in the same location. Using this, the KCC builds an inter-site replication topology
that is a spanning tree based on low-cost routing decisions between remote locations, and a more strongly
connected intra-site topology. You can disable the KCC topology generator and manually create the connection
objects required for replication. During this process, the Active Directory logging mechanism identifies domain
controllers that appear to be isolated from the enterprise-wide replication.
Note: Using replication topology generator is strongly recommended: it simplifies a complex task, has a flexible
architecture that reacts to failures and to changes you make later in the network topology, and helps compute the
lowest-cost topology.
The next sections discuss essential replication concepts.
Connection Objects
The fact that one domain controller uses another as a source for replication information is expressed as a
connection object in the Active Directory. These define incoming replication only. For example, if domain
controller DC1 has a connection object to DC2, then DC1 can use all naming contexts on DC2 as a source for
updated information, but DC2 cannot use DC1 unless it creates a connection object that defines DC1 as a source.
Once a connection object has been created, it can be used to replicate information from all naming contexts.
Sites
Used in the Active Directory to express proximity of network connection, a site is defined as an IP subnetwork—a
concept used in all routed TCP/IP network environments. A legal definition of a site could be 177.177.177.0/24,
where 177.177.177.0 describes the IP subnet, and 24 tells how many bits are used to define it. The remaining bits
of an IP address (32 – 24 = 8 bits in this example) can be used to define hosts.
A site consists of one or more subnets (unique network segments). For example, in a network with three subnets in
Redmond and two in Paris, the administrator can create two sites: one in Redmond and one in Paris, and add the
subnets to the local sites.
The Active Directory uses site information in these ways:
• The KCC generates a replication topology more strongly-connected within a site than between sites (adds
some traffic but reduces intra-site replication latency).

• Does not compress intra-site replication messages (adds some traffic but reduces CPU utilization on DCs).
• Intra-site DC replication is change-based; inter-site DC replication is scheduled.
• Client machines use site information to find nearby DCs for logon operations.
• The Active Directory uses site information to help users find the closest machine that offers a needed
network or a third-party service.
Intra-Site Replication
Intra-site replication (between domain controllers in the same site) attempts to complete in the fewest CPU cycles
possible. Because domain controllers should be able to serve clients quickly for logons, searches, etc., the network
connection between them is assumed to have lots of available bandwidth and reliable connection.
Replication is a trade off: data should be as accurate as possible on all domain controllers, which means that
latency should be as small as possible, which means fast updates, which means frequent replication. On the other
hand, frequency doesn't always equal efficiency. For instance, if there is a bulk import of directory objects, changes
in a domain controller database will become out of date after 10 seconds, but it makes no sense to replicate the
changes until the database is stable (the bulk import is complete).
Intra-site replication avoids unnecessary network traffic by introducing a change notification mechanism that
replaces the usual polling of replication partners for updates. When a change is performed in its database, a
domain controller waits a configurable interval (default 5 minutes), accepts more changes during this time, then
sends a notification to its replication partners, which pull the changes. If no changes are performed for a
configurable period (default 6 hours) the domain controller initiates a replication sequence anyway, just to make
sure that it did not miss anything.
Attribute changes considered security-sensitive are immediately replicated and intra-site partners are notified:
lockout of user accounts, change of domain trust passwords, some changes in the roles of domain controllers.
Intra-site replication topology is a bi-directional ring built using domain controller GUIDs. If a ring contains seven
or more DCs, bi-directional connections are added to keep the path between any pair to less than three hops. New
DCs configured in the site are included in the ring. One bi-directional ring is built for each naming context available
in a site. Schema and configuration information share the same topology and only one bi-directional ring is built for
them, because they must be replicated to all domain controllers.
If all of a site's domain controllers are in the same domain, the two rings are the same—the ring that includes all
site domain controllers is equivalent to the ring that includes all domain controllers in that domain. You have more
than one distinct ring only when your site contains more than one domain: 2 domains = 3 rings, 3 domains = 4
rings, and so forth. To find out what rings exist in a site, use the Active Directory Sites and Services Manager snap-
in to check the connection objects and see what incoming replication connections they represent.
Inter-Site Replication
Inter-site replication is based on the assumption that the WAN is connected by slower links, so it is designed to
minimize traffic rather than CPU cycles. Before being sent out, data is compressed to about 10% to 15% of original
volume.
Inter-site replication topology is a spanning tree. As long as a replication route can be constructed between all sites
in the enterprise, the replication topology is functional. It is not necessary to create additional links. The
administrator decides which sites are connected, and can create a site link that allows domain controllers from any
site to talk to domain controllers in any other site. Site links are based on the cost of replication (which reflects the
speed and reliability of the underlying network) and its schedule (which defines a window when replication is
allowed over the link).
Unlike Intra-site replication, inter-site replication does not use a notification process. Inter-site replication can be
fully scheduled by the administrator on a per site-link basis.
Since there is no notification between the replication partners, a domain controller does not know which naming
context was updated on the sourced replication partner. Therefore, it has to check all existing naming contexts on
the source machine. A normal domain controller (that is, one that uses a GC as replication partner) will check only
the normal three naming contexts on the GC (schema, configuration, and its domain) but never the partial naming
contexts of other domains. For that reason, the initial replication setup traffic is slightly higher in the inter-site
case. But if many objects are replicated, compression kicks in and makes this kind of replication more efficient.
Replication Transports
While intra-site replication supports only replication based on remote procedure calls (RPCs), the initial release of
Windows 2000 offers two transports for inter-site replication:
• Synchronous (scheduled) via RPC over TCP/IP
• Asynchronous via simple mail transfer protocol (SMTP) using the Collaborative Data Objects (CDO v2)
interface and the SMTP component in IIS 5, that is included in Windows 2000.
The intra-site RPC transport does not support data compression; the inter-site transports, both RPC and SMTP, do.
RPC-based replication can be used for any kind of replication—intra-domain, configuration information, or global
catalog information.
The SMTP transport has some restrictions: It can be used to replicate configuration and global catalog information,
but cannot be used for replication between domain controllers that belong to the same domain and therefore have
to replicate the full domain-naming context. The reason for this restriction is that some domain operations (for
example: global policy) require the support of the file replication service (FRS) that does not yet support an
asynchronous transport like SMTP for replication.
Top of page
How to Measure Replication Traffic
Windows 2000 gives you some tools for assessing network load:
• Performance Monitor
• Event Log
• Network Monitor
The Windows 2000 Performance Monitor looks slightly different than previous versions available in Windows NT. It
is implemented as a Microsoft ActiveX control that can be used either as an Microsoft Management Console (MMC)
snap-in, or as a control in a Web page. This allows you to monitor servers and network traffic from a browser.
The Performance Monitor counters most frequently used to measure replication traffic appear under the NTDS
object. They are:
• DRA Inbound Bytes Total. Total number of bytes replicated in. Sum of the number of uncompressed
bytes (never compressed) and the number of compressed bytes (after compression).
• DRA Inbound Bytes Not Compressed. Number of bytes replicated in, that were not compressed at the
source (which typically implies they arrived from other DSAs in the same site).
• DRA Inbound Bytes Compressed (Before Compression). Original size in bytes of inbound
compressed replication data (size before compression).

• DRA Inbound Bytes Compressed (After Compression). Compressed size in bytes of inbound
compressed replication data (size after compression).
• DRA Outbound Bytes Total. Total number of bytes replicated out. Sum of the number of uncompressed
bytes (never compressed) and the number of compressed bytes (after compression).
• DRA Outbound Bytes Not Compressed. Number of bytes replicated out that were not compressed
(which typically implies they were sent to DSAs in the same site, or that less than 50,000 bytes of
replicated data was sent).
• DRA Outbound Bytes Compressed (Before Compression). Original size in bytes of outbound
compressed replication data (size before compression).
• DRA Outbound Bytes Compressed (After Compression). Compressed size in bytes of outbound
compressed replication data (size after compression).
You can also retrieve a subset of this information from the Event Log. The Event Log for directory service logging is
set to the lowest level by default. This reduces the size of the log files, and restricts logging to important events
such as errors, lost connections to replication partners, etc. Activating higher levels of event logging consumes CPU
time and can present you with the tedious task of finding the right information in huge log files.
The third tool is Network Monitor. Measuring replication traffic with a network "sniffer" helps you isolate network
packets that belong to replication between domain controllers. These figures differ for the RPC transport and the
SMTP transport.
Sniffing RPC Replication Traffic
An easy way to detect replication traffic is to start Network Monitor and then force replication, which you can do
either by using the Sites and Services Administration snap-in in MMC, or REPADMIN.EXE, which allows you to
specify the particular naming context that has to be replicated. Once REPADMIN.EXE returns and reports that
replication was successful, you can stop Network Monitor.
At this point, however, you have measured all incoming and outgoing packets from the server machine. Some
could have been sent by other services running on the machine, such as NetLogon or the file server.
It is not easy to determine which packets belong to replication. One way would be to use the IP port that is used by
replication. In general, this is not possible because replication uses dynamic RPC port mapping (as a means of
security). This process allows the replication server to request an available port from the RPC port mapper
interface, which tells the requesting client the port used by the replication interface, which the client then uses to
communicate with the replication server.
One way to get around this is to configure the IP port used on the replication server by adding this value in the
registry:
HKEY_LOCAL_MACHINE \CurrentControlSet \Services \NTDS \Parameters \TCP/IP Port
You can set this to 1349 (decimal), for example, to make 1349 the IP port, then find all replication-related packets
by filtering on that port with Network Monitor.
Sniffing SMTP Transport Replication Traffic
Finding packets that belong to SMTP replication is easier because the SMTP service always uses port number 25
(decimal). Filtering network traffic using this port number shows only the SMTP-related replication packets.
Top of page
Traffic Scenarios
This section discusses the traffic caused in two scenarios: single attribute replication, then complete object
replication (such as users, groups, etc). It examines replication between domain controllers in the same domain
(intra-site and inter-site), and global catalog server replication (intra-site and inter-site). The inter-site GC
replication examines the RPC and SMTP transports. In the other cases, only the RPC transport can be used.
This is the basic scenario:
Single Attribute Changes
The Windows 2000 Active Directory has a replication granularity of one attribute: if only a single attribute changes,
only that one new value is sent over the network.
There are two areas to examine: how efficient single-property replication is when compared to whole-object
replication, and how replication traffic grows with attribute size.
The tests use non-security attributes because replicating security-related attributes (attributes owned by the
security accounts manager—SAM) involves a special domain controller, the PDC emulator, that adds non-
replication traffic onto the wire. (Passwords are tested later, however.) Specifically, the tests use string-data
attributes taken from the user object because these affect traffic growth clearly.
Replication of one attribute with string size 1 – 75 characters.
Character Bytes Diff Character Bytes Diff Character Bytes Diff
1 4396 26 4444 0 51 4492 0
2 4396 0 27 4444 0 52 4492 0
3 4396 0 28 4444 0 53 4492 0
4 4396 0 29 4444 0 54 4492 0
5 4396 0 30 4444 0 55 4492 0
6 4396 0 31 4444 0 56 4492 0
7 4396 0 32 4444 0 57 4508 16
8 4396 0 33 4460 16 58 4508 0
9 4412 16 34 4460 0 59 4508 0
10 4412 0 35 4460 0 60 4508 0
Replication of one attribute with string size 1 – 75 characters. (continued)
Character Bytes Diff Character Bytes Diff Character Bytes Diff

11 4412 0 36 4460 0 61 4508 0
12 4412 0 37 4460 0 62 4508 0
13 4412 0 38 4460 0 63 4508 0
14 4412 0 39 4460 0 64 4508 0
15 4412 0 40 4460 0 65 4524 16
16 4412 0 41 4476 16 66 4524 0
17 4428 16 42 4476 0 67 4524 0
18 4428 0 43 4476 0 68 4524 0
19 4428 0 44 4476 0 69 4524 0
20 4428 0 45 4476 0 70 4524 0
21 4428 0 46 4476 0 71 4524 0
22 4428 0 47 4476 0 72 4524 0
23 4428 0 48 4476 0 73 4688 164
24 4428 0 49 4492 16 74 4688 0
25 4444 16 50 4492 0 75 4688 0
The table shows that the replication of a 1-character string property causes 4396 bytes of traffic. Increasing the
string size up to 8 characters does not change the value. From 9 to 16 characters the traffic increases by 16 bytes,
an increment that recurs up to 72 characters. This result is not surprising because the Active Directory uses
Unicode to store strings in the database. Each Unicode character is 2 bytes, so for every 8 characters a 16- byte
buffer is created. From the 72nd to the 73rd character is a big jump. This was caused by network fragmentation; the
packet that contained the changed value reached its maximum size of 1,500 bytes and a new packet had to be
created (causing overhead for an empty packet). After this jump, the 8-character/16-byte pattern resumes.
The next table shows what happens when multiple attributes are changed at the same time. It begins with one
attribute and increases to six. Two things are examined: how traffic grows as attributes grow from one to ten
characters, and how replication traffic increases as attributes increase.
Changing multiple attributes simultaneously.
One
Attribut Two Three Four Five Six
e Attributes Attributes Attributes Attributes Attributes
Characte Bytes Diff Bytes Diff Bytes Diff Bytes Diff Bytes Diff Bytes Diff
r
1 4396 4460 4524 4736 4800 4864
2 4396 0 4460 0 4524 0 4736 0 4800 0 4864 0
3 4396 0 4460 0 4524 0 4752 16 4816 16 4880 16
4 4396 0 4460 0 4524 0 4752 0 4816 0 4880 0
5 4396 0 4476 16 4688 164 4768 16 4832 16 4912 32
6 4396 0 4476 0 4688 0 4768 0 4832 0 4912 0
7 4396 0 4476 0 4704 16 4784 16 4848 16 4928 16
8 4396 0 4476 0 4704 0 4784 0 4848 0 4928 0
9 4412 16 4492 16 4720 16 4800 16 4864 16 4960 32
10 4412 0 4492 0 4720 0 4800 0 4880 16 4960 0
Replicating one attribute with a one-character string size takes 4396 bytes. Two attributes with one-character
strings each take 4460 bytes—a difference of 64 bytes. The growth from two attributes to three is again 64 bytes.
From three attributes to four is a bigger jump, however, because the increases exceeds the maximum Ethernet
packet size and an extra packet has to be created. From four to five and from five to six attributes, the pattern
resumes the 64-byte jump.
It can be surmised, then, that it takes 64 bytes to replicate one attribute if it has a one-character string. Ten-
character-string attributes show an increase of 80 bytes per attribute (except when a new packet has to be
created).
These tests again show the 8-character/16-byte jump. For example, in the column for 4 attributes, there is a 16-
byte jump after two characters are added to the string size. This is the same behavior seen during the single-
attribute replication.
Since the replication of single attributes causes little network traffic, it is not useful to research the behavior in
different domain/site scenarios.
Object Replication
For object replication, all domain, sites and GC scenarios are covered. Here is the scenario:
Figure 11.1: Replication scenario for object replication testing.
This small environment consists of two domains: Microsoft.com and Sales.Microsoft.com. Each has two domain
controllers. Microsoft.com has Red-MS1 and Red-MS2: Sales.Microsoft.com has Red-Sales1 and Mil-Sales2.
The network is distributed over two sites: Redmond (headquarters) and Milan. Both sites have one global catalog:
Red-MS1 for Redmond, Mil-Sales2 (the only domain in Milan) for Milan.
This small scenario covers all replication cases.
• Between two domain controllers that belong to the same domain, both intra-site (Red-MS1 and Red-MS2)
and inter-site (Red-Sales1 and Mil-Sales2) replication occurs
• Partial global catalog server replication, both intra-site (Red-MS1 and Red-Sales1) and inter-site (Red-MS1
and Mil-Sales2). Replication between Red-MS1 and Mil-Sales2 can use either the RPC or the SMTP
transport.
Intra-Site Domain Replication (Red-MS1 and Red-MS2)
Intra-Site replication assumes fast and reliable network connections. This should be a 10-Mbps Ethernet network or
a comparable network topology. The emphasis on intra-site replication is on using the fewest possible CPU cycles
at the domain controllers. This frees the domain controllers for other tasks, such as client logon, search operations
etc. This is why data compression is not available within a site; it would cause additional CPU load.
In this sample case, both the global and the universal groups had no members. For all objects, only the mandatory
attributes were set.
The following table shows how many bytes were created when objects were sent from one replication partner to
another:
Intra-site domain replication.
#Objects Users Global groups Universal groups Volumes
1 13,019 11,309 11,145 10,277
10 47,037 26,902 26,823 22,848
100 386,148 187,754 185,606 149,736

500 1,914,087 905,015 906,079 715,577
1,000
3,818,256 1,815,170 1,803,090 1,436,085
This shows that the network traffic is absolutely predictable. Replicating 1,000 users, for example, causes twice as
much traffic as replicating 500 users.
Replicating user objects causes more traffic than replicating objects that are not security principals. This is not
surprising; the same effect was evident in the database sizing tests in Chapter 10.
The next test examines the replication of additional attributes. For the test, user objects were created, and filled
with different sets of attributes. In the first test, only mandatory attributes were set. For the next test, one
attribute was added to the mandatory attributes, then three added, then five added. All additional attributes were
string attributes filled with 10 characters. The numbers in quotation marks show the overhead per attribute. For
the replication of one user with five additional attributes, for example, this is (13,451 bytes – 13,019 bytes )/5 =
86 bytes.
Replication of additional attributes.
#Users Mandatory attributes Plus 1 attribute Plus 3 attributes Plus 5 attributes
1 13,019 13,233 13,439 13,451

"214" "80" "86"
10 47,037 47,917 49,923 51,765

"88" "96" "96"
100 386,148 396,308 416,107 435,496

"102" "99" "96"
Replication of additional attributes. (continued)
#Users Mandatory attributes Plus 1 attribute Plus 3 attributes Plus 5 attributes
500 1,914,087 1,966,967 2,064,423 2,160,454

"106" "102" '94"
1,000 3,818,256 3,919,177 4,123,535 4,328,794

"101" "103" "107"
5,000 19,123,820 19,619,815 20,628,381 21,611,973

"99" "102" "98"
Again, the traffic is very predictable. Adding one attribute to the object adds around 100 bytes of traffic. This
makes it easy to compute additional traffic caused by replicating objects with a specific attribute set.
The next test concentrates on group replication. Group size depends on the number of members. This test shows
how much overhead is created for a single group member (results are in bytes transferred). The numbers in
quotation marks show the overhead per group member. To replicate 1 group with 100 members, this is: (29,212
bytes – 11,309 bytes) / 100 = 179 bytes.
Group replication test results.
#Groups No members 10 members 20 members 100 members
1 11,309 13,023 15,028 29,212

"171" "186" "179"
10 26,902 45,180 36,199 206,193

"183" "191" "179
100 187,754 370,333 549,351 2,007,563

"183" "181" "182"
500 905,015 1,822,257 2,745,787 9,956,677

"183" "184" "181"
1,000 1,815,170 3,633,795 5,458,848 19,920,866

"182" "182" "181"
The results again show a very predictable pattern. The overhead per group member is around 180 bytes.
The next test shows one of the most common operations: password changes. In this scenario, the PDC emulator
was used for the password change, and only the replication traffic between this domain controller and a replication
partner was captured. The numbers in the second column represent the bytes per operation. The third column
shows the bytes per changed password.
Password change traffic.
#Users Bytes Bytes/user
1 10,805 1,842
10 12,811 385
100 59,856 509
500 275,422 533

1,000 444,085 425
5,000 3,014,610 601
Again the results are predictable: about 500 - 600 bytes/user. The test stops at 5,000 password changes, since
more than that many per day would be rare; if users changed their passwords every 14 days, this would be the
equivalent of 90,000 users in the same domain and in the same site. (Inter-site replication works differently, and is
covered later.) Even if a company uses Windows 2000 or Windows NT workstations exclusively, with 45,000 users
working on 45,000 workstations, the resulting 3 MB each day for password changes would be rare. And remember:
intra-site traffic assumes a good network connection.
To summarize, intra-site domain replication is very predictable. Replicating more objects or attributes just
increases network traffic following the same ratio. Intra-site replication assumes good network connection, so
domain controllers don't waste expensive CPU cycles on compression.
Intra-Site GC Replication
Intra-site global catalog replication involves two domain controllers (one of which is a global catalog) that belong to
different domains. The global catalog holds a partial replica of the domain-naming context of the other domain, and
because only this subset of attributes has to be replicated, replication between these two domain controllers is also
called partial replication.
Figure 11.2: Intra-site global catalog replication.
This scenario examines the traffic between Red-Sales1 (domain controller in Sales.Microsoft.com) and Red-MS1
(domain controller in Microsoft.com), and a global catalog server.
The first test examines the traffic generated for objects. Except for domain replication, group type plays a role in
global catalog server replication. Universal groups publish the group memberships in the GCs, but global groups do
not, so more replication traffic is expected for universal groups than for global groups.
The table shows the bytes per object. The numbers in quotation marks are the domain replication numbers for
comparison.
Intra-site replication traffic.

1 12,401 11,601 11,437 11,101

"13,019" "11,309" "11,145" "10,277"
10 35,595 26,783 26,862 23,011

"47,037" "26,902" "26,823" "22,848"
100 272,877 183,123 183,205 145,199

"386,148" "187,754" "185,606" "149,736"
500 1,323,177 879,823 879,990 690,042

"1,914,087" "905,015" "906,079" "715,577"
1,000 2,640,974 1,750,665 1,751,239 1,370,457

"3,818,256" "1,815,170" "1,803,090" "1,436,085"
5,000 13,189,354 8,735,103 8,745,150 6,860,815

"19,123,820" "8,985,915"
The test shows that the replicated objects for GC replication are smaller than for domain replication. For user
objects, the difference is not big. For smaller objects (non-security principals such as volume), the traffic is around
2/3 of what is replicated within a domain.
Universal and global groups are the same size because they were created with no members.
The next two tables compare global and universal groups.
Global groups.
1 11,601 11,519 11,437 11,437
10 26,783 26,783 26,783 26,783
100 183,123 183,369 183,369 183,041
The amount of data does not change if members are added to the group because Global Groups do not replicate
members to the GC.
Universal groups.

1 11,437 13,491 17,149 31,731
10 26,862 46,816 67,256 245,908
100 183,205 388,725 593,623 2,207,641
Universal Group replication traffic depends heavily on the number of group members. To replicate 100 groups of
100 members each, the traffic is 12 times as big as for the comparable Global Group.
Intra-site GC replication is predictable. The objects replicated are smaller than within a domain—they can be as
much as 1/3 smaller. However, this relates only to objects that were created with the minimum possible number of
attributes set. If additional attributes are used, they won't be replicated to the global catalog, so the ratio goes
down. However, if you change the schema so that attributes are added to partial replication, or if applications
(such as messaging systems) add them, global catalog server replication traffic increases. Group type is also
relevant for the traffic to the global catalog, because universal groups replicate their group members.
Inter-Site Domain Replication
The next scenario covers inter-site domain replication, which involves two domain controllers in different sites
within the same domain. These serve as bridgehead servers, and are the only domain controllers of this particular
domain that replicate over a WAN link. Once they receive updated information, they distribute it to the other
domain controllers in their site.
This scenario examines replication between Red-Sales1 and Mil-Sales2. Both domain controllers are in the
Sales.Microsoft.com domain, but are in different sites (Redmond and Milan).
Figure 11.3: Inter-site domain replication.
Only object creation was tested. Changing the number of group members is not a factor because group members
are always replicated between domain controllers of the same domain.
The table shows the traffic for object creation. The numbers in quotation marks are the intra-site results for the
same operations for comparison:
Traffic generated by object creation.

1 14,108 10,437 11,227 9,667

"13,019" "11,309" "11,145" "10,277"
10 45,563 25,683 26,741 21,691

"47,037" "26,902" "26,823" "22,848"
100 39,583 28,743 29,675 22,602

"386,148" "187,754" "185,606" "149,736"
500 173,105 102,404 119,180 81,691

"1,914,087" "905,015" "906,079" "715,577"
1,000 291,041 194,926 199,054 151,989

"3,818,256" "1,815,170" "1,803,090" "1,436,085"
The results demonstrate how compression works. Up to a certain size, data is not compressed. In fact, for small
replications (such as replicating one user) there is slightly more traffic than in the intra-site case. This is caused by
the need to source more naming contexts (schema and configuration). Once the size of the data that has to be
replicated exceeds 50,000 bytes, compression kicks in and reduces the amount of data considerably. A good
example is the replication of 10 users and 100 users. Replicating 100 users causes much less network traffic (per
user) than replicating 10 users. This is clearly the result of compression.
Inter-Site Global Catalog Replication—RPC–over–IP
The next scenario is inter-site GC replication, which involves two domain controllers (one a GC) that belong to
different domains and are replicating schema, configuration, and the partial domain naming context. This type of
replication can use RPC-over-IP or the SMTP transport. The first test uses RPCs.
Figure 11.4: Inter-site global catalog replication.
In the example, Mil-Sales2 (a GC in Sales.Microsoft.com) replicates partial Microsoft.com information from Red-
MS1. Note that Red-MS1, which is also a GC, would not use Mil-Sales2 as a source for the Sales.Microsoft.com
naming context, because Red-MS1 can find a closer domain controller in Sales.Microsoft.com (in this case, Red-
Sales1 is in the same site).
For this replication set, two factors are of interest: how does partial inter-site replication compare to partial intra-
site replication, and how does group membership affect the overall picture?
The first table gives an overview of partial replication of objects. The numbers in quotation marks are the figures
for intra-site GC replication, for comparison.
Partial inter-site replication.
1 12,565 11,471 11,389 11,183

"12,401" "11,601" "11,437" "10,277"
10 36,018 26,895 26,813 23,171

"35,595" "26,783" "26,682" "23,011"
100 32,391 28,600 28,379 24,598

"272,877" "183,123" "183,205" "145,199"
500 121,481 101,858 102,200 83,099

"1,323,177" "879,823" "877,990" "690,042"
1,000 233,503 194,047 194,357 170,918

"2,640,974" "1,750,665" "1,751,239" "1,370,457"
The table shows interesting differences between inter- and intra-site replication; again, replicating 100 users
causes much less network traffic (per user) than replicating 10 users. In fact, inter-site replication of 1,000 users
generates less traffic than intra-site replication of 100 users.
The next two tables show group memberships again, beginning with global groups. The numbers are much smaller
again, compared to intra-site replication. The number of group members does not change the picture.
Global groups.
1 10,437 11,951 11,389 11,553

"11,601" "11,519" "11,437" "11,437"
10 25,683 26,141 26,223 26,223

"26,783" "26,783" "26,783" "26,783"
100 28,743 28,227 28,319 28,781

"183,123" "183,369" "183,369" "183,041"
Universal groups.
1 11,227 17,010 15,786 32,270

"11,437" "13,491" "17,149" "31,731"
10 26,741 46,898 12,999 17,902

"26,862" "46,816" "67,256" "245,908"
100 29,675 39,120 46,912 107,551

"183,205" "388,725" "593,623" "2,207,641"
Again, the numbers are much lower than for intra-site replication. However, this time traffic increases with the
number of group members.
Inter-Site global catalog replication—SMTP Transport
This uses the same scenario, replicating between one global catalog and a domain controller that belongs to a
different domain; the machines reside in different sites. This time, the SMTP transport is used.
The table shows the replication traffic. The RPC numbers are added in quotation marks.
Inter-site global catalog replication.
Object replication in bytes Inter-site RPC replication
No. Objects Users Global Universal Volumes

Groups Groups
1 22,253 20,714 20,855 20,078

"12,565" "11,471" "11,389" "11,183"
10 52,887 40,499 40,417 35,409

"36,018" "26,895" "26,813" "23,171"
100 59,675 55,537 55,587 41,375

"32,391" "28,600" "28,379" "24,598"
500 224,804 203,787 203,629 182,324

"121,481" "101,858" "102,200" "83,099"
1,000 440,165 281,916 394,434 349,389

"233,503" "194,047" "194,357" "170,918"
Again, compression helps to minimize the traffic. The threshold at which compression kicks in is higher when
compared to the RPC transport; this threshold is around 65,000 bytes. Also, the SMTP transport creates more
traffic overall than the RPC transport—about 80% to 100% more.
Top of page
Summary of Network Traffic Analysis

To summarize, here are some replication recommendations:
• Intra-site replication assumes good network connectivity so domain controllers can save CPU cycles (for
client logons, search operations etc.) by not compressing data for intra-site replication.
• Replication traffic is predictable. Use the tables in this chapter to find the data for your objects. If you set
additional attributes on objects, add 100 bytes per attribute with a string size up to 10 characters.
• Partial replication (global catalog replication) is smaller than normal replication. The difference is bigger
when more attributes are used on objects.
• Inter-site replication adds compression. If there is a slow link between domain controllers, create a new
site.
• Inter-site replication is scheduled. This reduces communication between domain controllers.
• The SMTP transport creates more network traffic than the RPC Site connector. Use RPCs between sites
whenever possible.
How can you choose between the two inter-site transports?
• If good network connectivity is available and fast client logon is desired—use one site.
• If reduced network traffic is desired, but the connection between domain controllers is fairly reliable—use
multiple sites and the RPC-over-IP replication connector.
• If the network connection is unreliable, or domain controllers have no direct network connection
(connected only through a messaging system)—use the SMTP replication connector. Remember that it can
be used only for schema, configuration, and partial replication, not for replication between two domain
controllers in the same domain.
What Is the Active Directory Replication Model?

Updated: March 28, 2003
2003 with SP2, Windows Server 2008, Windows Server 2008 R2
What Is the Active Directory Replication Model?

In this section
• Replication Model Components
• Technologies Related to Active Directory Replication
• Active Directory Replication Dependencies
• Related Information
Active Directory replication is the means by which changes to directory data are transferred between domain
controllers in an Active Directory forest. The Active Directory replication model defines the mechanisms that allow
directory updates to be transferred automatically between domain controllers to provide a seamless replication
solution for the Active Directory distributed directory service.
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 AD DS.
Note
• This discussion of the replication model and related mechanisms for transferring directory data between
domain controllers does not include the topic of replication topology. Replication topology is the set of
connections that are generated by the Knowledge Consistency Checker (KCC) to enable replication to take
place between domain controllers.
Active Directory is distributed by means of directory partitions. In addition to directory partitions that store forest-
wide data, each domain controller stores a replica of a single domain directory partition, which contains data that is
specific to one or more closely aligned business units—the users, computers, organizational units, and network
resources that are managed by the same set of service and data administrators. Because each domain controller
stores only one domain directory partition, Active Directory can scale to hundreds or thousands of domains storing
millions of objects.
To efficiently synchronize data between domain controllers that store the same domain, Active Directory replication
transfers updates according to directory partition. Each domain controller receives directory updates to the data
that is stored in its domain only, as well as updates that are stored in the two directory partitions that store
configuration and schema data for the forest.
Note
• In Windows Server 2003 forests, domain controllers can also store application directory partitions, which
store application data that can be replicated to only the domain controllers that store the directory
partition, irrespective of domain.
Active Directory replication manages the transfer of these updates to the appropriate domain controllers
automatically, keeping domain data up-to-date among all domain controllers in the domain, regardless of location.
In the process, all domain controllers in the forest are also updated with changes to forest-wide data.
Replication Model Components

To globally distribute the directory service, the Active Directory replication model incorporates the components in
the following table.
Replication Model Components and Advantages
Component Description Advantage
Multimaster Every domain controller can receive originating updates to Provides fault tolerance,
replication data for which it is authoritative, rather than having a single eliminating the dependency on a
domain controller that receives all original updates (single- single domain controller to
master replication, such as Windows NT 4.0 replication). maintain directory operations.
Pull replication Domain controllers request (pull) changes rather than send Reduces unnecessary network
(push) changes that might not be needed. traffic.
Store-and- Each domain controller communicates with a subset of Balances the replication load
forward domain controllers to transfer replication changes, rather among many domain controllers.
replication than one domain controller being responsible for
communicating with every other domain controller that
requires the change.
State-based Each domain controller tracks the state of replication Conflicts and unnecessary
replication updates. replication are reduced.
The Active Directory replication model ensures:
• Domain controller availability. Multimaster replication ensures that all domain controllers are available
for updates, eliminating the potential for slow service if only a single updatable domain controller were
available.
• Efficient transfer of data. State-based and pull replication ensures the minimum replication traffic and
the maximum efficiency to retrieve only the changes that are needed.
• Reliable consistency. Directory consistency is guaranteed within the same period of replication latency.
• Conflict resolution. Even if two administrators change the same attribute on different domain controllers
at the same time, conflict resolution ensures that only one of the values is replicated to all domain
controllers.
Replication Latency
Multimaster replication involves latency — the period of time for an update that occurs on the originating domain
controller to reach all other domain controllers that need it. To address replication latency, multimaster replication
ensures loose consistency with convergence, as follows:
• Loose consistency means that the replicas are not guaranteed to be consistent with each other at any
particular point in time because changes can originate from any replica at any time.
• Convergence means that if the system is allowed to reach a steady state in which no new updates are
occurring and all previous updates have been completely replicated, all replicas of the same directory
partition are guaranteed to converge on the same set of values.
With multimaster replication, it is not necessary for every domain controller to replicate with every other domain
controller. Instead, the system implements a robust set of connections that determines which domain controllers
replicate to which other domain controllers to ensure that networks are not overloaded with replication traffic and
that replication latency is not so long that it inconveniences users. The set of connections through which changes
are replicated to domain controllers in an enterprise is called the replication topology.
Although it involves latency, multimaster update capability provides high availability of write access to directory
objects because several servers can contain writable copies of an object. Each domain controller in the domain can
accept updates independently, without communicating with other domain controllers. Active Directory replication
resolves any conflicts that occur when multiple updates are made to a single directory object.
State-based Vs. Log-based Replication

In state-based replication, each domain controller (master) in the multimaster system applies updates to its replica
as they arrive, without maintaining a change log file. In a typical log-based replication system (also called “change-
based”), each master keeps a log of the updates that it originated and communicates its log to every other replica.
After a log has arrived at a replica, the replica applies the log, bringing itself more up-to-date. In this process, the
destination receives and stores a record of all changes, not just the changes it needs.
Active Directory replication relies on the current “state” (the current values of all objects) of the source replica
instead of logs. The current state includes metadata that is used to resolve conflicts and to avoid sending the full
replica on each replication cycle.
Generally speaking, a directory partition replica maintains all of its objects in a list ordered by last modification.
This list is a log of sorts, but one whose size is a tiny fraction of the size of the replica itself. A typical replication
request can be satisfied by examining only the last few objects on the list because the replication destination
server is aware of how much of its replication source’s list of changes have already been processed.
Multimaster Vs. Single-master Replication

Although a single-master model is adequate for a directory that has a small number of replicas and for an
environment where all of the changes can be applied centrally, this approach does not scale beyond small
organizations nor does it address the needs of decentralized organizations.
Multimaster replication provides the following advantages over single-master replication:
• If one domain controller becomes inoperable, other domain controllers can continue to update the
directory. In single-master replication, if the master becomes inoperable, directory updates cannot take
place. For example, if the failed server holds your password and your password has expired, you cannot
reset your password and therefore you cannot log on to the domain.
• Servers that are capable of making changes to the directory can be distributed across the network and
can be deployed in multiple locations.
• By creating multiple replicas of the directory and keeping the replicas consistent, the directory service can
handle more queries per second. Directory services must handle a large number of queries compared to
the number of updates they must process. A typical ratio of queries to updates is 99:1.
Pull Vs. Push Replication

In push replication, a source domain controller sends unsolicited information to update a destination domain
controller. Push replication is problematic because it is difficult for the source to know what information the
destination needs. The destination can receive the same information from another source. Therefore, a source can
send unnecessary information to a destination.
Technologies Related to Active Directory Replication

File Replication service (FRS) is related to Active Directory replication because it requires the Active Directory
replication topology. FRS is a multimaster replication service that is used to replicate files and folders in the System
Volume (SYSVOL) shared folder on domain controllers and in Distributed File System (DFS) shared folders. FRS
works by detecting changes to files and folders and then replicating the updated files and folders to other replica
members, which are connected in a replication topology.
FRS uses the replication topology that is generated by the KCC to replicate the SYSVOL files to all domain
controllers in the domain. SYSVOL files are required by all domain controllers for Active Directory to function. For
more information about FRS and how it uses the Active Directory replication topology, see “FRS Technical
Reference.” For more information about SYSVOL, see “Data Store Technical Reference.” For more information
about DFS, see “DFS Technical Reference.”
Active Directory Replication Dependencies
Active Directory replication has the following dependencies:
• DNS. The Domain Name System (DNS) that resolves DNS names to IP addresses. Active Directory
requires that DNS is properly designed and deployed so that domain controllers can correctly resolve DNS
names of replication partners.
• Remote procedure call (RPC). Active Directory replication requires IP connectivity and the Remote
Procedure Call (RPC) to transfer updates between replication partners.
• Kerberos v5 authentication. The authentication protocol for both authentication and encryption that is
required for all Active Directory RPC replication.
• LDAP protocol. The primary access protocol for Active Directory. Replication of an entire replica of an
Active Directory domain, as occurs when Active Directory is installed on an additional domain controller in
an existing domain, uses LDAP communication rather than RPC.
The following diagram shows the interaction of these components within the replication process.
Replication Interactions with Other Technologies
What Is the Global Catalog?

Updated: June 3, 2010
In this section
• Common Global Catalog Scenarios
• Global Catalog Dependencies and Interactions
The global catalog is a distributed data repository that contains a searchable, partial representation of every object
in every domain in a multidomain Active Directory Domain Services (AD DS) forest. The global catalog is stored on
domain controllers that have been designated as global catalog servers and is distributed through multimaster
replication. Searches that are directed to the global catalog are faster because they do not involve referrals to
different domain controllers.
Note
In Windows Server® 2003 and Microsoft Windows® 2000 Server, the directory service is named
Active Directory. In Windows Server 2008 R2 and Windows Server 2008, the directory service is named
Active Directory Domain Services. The rest of this topic refers to AD DS, but the information is also applicable to
Active Directory.
In addition to configuration and schema directory partition replicas, every domain controller in a forest stores a full,
writable replica of a single domain directory partition. Therefore, a domain controller can locate only the objects in
its domain. Locating an object in a different domain would require the user or application to provide the domain of
the requested object.
The global catalog provides the ability to locate objects from any domain without having to know the domain name.
A global catalog server is a domain controller that, in addition to its full, writable domain directory partition replica,
also stores a partial, read-only replica of all other domain directory partitions in the forest. The additional domain
directory partitions are partial because only a limited set of attributes is included for each object. By including only
the attributes that are most used for searching, every object in every domain in even the largest forest can be
represented in the database of a single global catalog server.
Note
A global catalog server can also store a full, writable replica of an application directory partition, but objects in
application directory partitions are not replicated to the global catalog as partial, read-only directory partitions.
The global catalog is built and updated automatically by the AD DS replication system. The attributes that are
replicated to the global catalog are identified in the schema as the partial attribute set (PAS) and are defined by
default by Microsoft. However, to optimize searching, you can edit the schema by adding or removing attributes
that are stored in the global catalog.
In Windows 2000 Server environments, any change to the PAS results in full synchronization (update of all
attributes) of the global catalog. Later versions of Windows Server reduce the impact of updating the global catalog
by replicating only the attributes that change.
In a single-domain forest, a global catalog server stores a full, writable replica of the domain and does not store
any partial replica. A global catalog server in a single-domain forest functions in the same manner as a non-global-
catalog server except for the processing of forest-wide searches.
Common Global Catalog Scenarios

The following events require a global catalog server:
• Forest-wide searches. The global catalog provides a resource for searching an AD DS forest. Forest-
wide searches are identified by the LDAP port that they use. If the search query uses port 3268, the query
is sent to a global catalog server.
• User logon. In a forest that has more than one domain, two conditions require the global catalog during
user authentication:
• In a domain that operates at the Windows 2000 native domain functional level or higher, domain
controllers must request universal group membership enumeration from a global catalog server.
• When a user principal name (UPN) is used at logon and the forest has more than one domain, a
global catalog server is required to resolve the name.
• Universal Group Membership Caching: In a forest that has more than one domain, in sites that have
domain users but no global catalog server, Universal Group Membership Caching can be used to enable
caching of logon credentials so that the global catalog does not have to be contacted for subsequent user
logons. This feature eliminates the need to retrieve universal group memberships across a WAN link from
a global catalog server in a different site.
Note
Universal groups are available only in a domain that operates at the Windows 2000 native domain functional
level or higher.
• Exchange Address Book lookups. Servers running Microsoft Exchange Server rely on access to the global
catalog for address information. Users use global catalog servers to access the global address list (GAL).
Search Requests
Because a domain controller that acts as a global catalog server stores objects for all domains in the forest, users
and applications can use the global catalog to locate objects in any domain within a multidomain forest without a
referral to a different server.
When a forest consists of a single domain, every domain controller has a full, writable copy of every object in the
domain and forest. However, it is important to retain the global catalog on at least one domain controller because
many applications use port 3268 for searching. For example, if you do not have any global catalog servers, the
Search command on the Start menu cannot locate objects in AD DS.
The replicas that are replicated to the global catalog also include the access permissions for each object and
attribute. If you are searching for an object that you do not have permission to access, you do not see the object in
the list of search results. Users can find only objects to which they are allowed access.
User Logon Support

In addition to its role as a search provider, in a forest that has more than one domain, the global catalog has a role
as an identity source during the user logon process. Universal groups can provide access to resources outside of
the users domain. User principal names (UPNs) can specify a domain other than the domain of the user. By making
universal group membership and UPN domain-user mapping information available on all global catalog servers, the
global catalog provides the definitive source for groups that are capable of providing access in more than one
domain and names that do not unequivocally identify the domain of the user.
Universal Group Membership

During the domain logon process, the user must be authenticated. During the authentication process, the user is
validated (the domain controller verifies the identity of the user) and the user receives authorization data for
access to resources. To provide authorization data of a user, the authenticating domain controller retrieves the
security identifiers (SIDs) for all security groups of which the user is a member and adds these SIDs to the user’s
access token. In a forest that has more than one domain, the global catalog is the only location where
memberships of all universal groups in that forest can be ascertained. For this reason, access to a global catalog
server is required for successful authentication in a domain that can have universal groups.
The global catalog stores the membership (the member attribute) of only universal groups. The membership of
other groups can be ascertained at the domain level.
Because a universal group can have members from domains other than the domain where the group object is
stored and can be used to provide access to resources in any domain, only a global catalog server is guaranteed to
have all universal group memberships that are required for authentication.
For example, a user might be a member of a universal group that has its group object stored in a different domain
but provides access to resources in the user’s domain. To ensure that the user can be authorized to access
resources appropriately in this domain, the domain controller must have access to the membership of all universal
groups in the forest.
If a global catalog server is not available, the user logon fails.
User Principal Name

A user principal name (UPN) is a logon name that takes the form of an e-mail address. A UPN specifies the user ID
followed by a DNS domain name, separated by an "@" character (for example, jsmith@contoso.com). UPNs allow
administrative management of the UPN suffix to provide logon names that:
• Match the user’s e-mail name.
• Do not reveal the domain structure of the forest.
When a user account is created, the UPN suffix is generated by default as userName@ DnsDomainName, but it can
be changed administratively. For example, in a forest that has four domains, the UPN suffix might be configured to
map to the external DNS name for the organization. The userPrincipalName attribute of the user account
identifies the UPN and is replicated to the global catalog.
When you use a UPN to log on to a domain, your workstation contacts a global catalog server to resolve the name
because the UPN suffix is not necessarily the domain for which the contacted domain controller is authoritative. If
the DNS domain name in the UPN suffix is not a valid DNS domain, the logon fails. Assuming the UPN suffix is a
valid DNS name, the global catalog server returns the name of the AD DS domain to your workstation, which then
queries DNS for a domain controller in that domain.
If a company has more than one forest and uses trust relationships between the domains in the different forests, a
UPN cannot be used to log on to a domain that is outside the user’s forest because the UPN is resolved in the
global catalog of the user’s forest.
Universal Group Membership Caching

Universal Group Membership Caching eliminates the need for a domain controller in a multidomain forest to contact
a global catalog server during the logon process in domains where universal groups are available. Caching group
membership reduces WAN traffic, which helps in sites where updating the cached group membership of security
principals, including user and computer accounts, generates less traffic than replicating the global catalog to the
site.
Use the following criteria to determine if a site is a good candidate for Universal Group Membership Caching:
• Number of users and computers in the site: The site has less than 500 combined users and computers,
including transient users who log on occasionally but not on a regular basis. The cache of a user who logs
on once continues to be updated periodically for 180 days after the first logon. A general limit of
500 membership caches can be updated at a time. If greater than 500 security principals have cached
group memberships, some caches might not be updated.
• Number of domain controllers: Each domain controller performs a refresh on every user in its site once
every eight hours. Depending on the number of domains in the forest, 500 security principals and two
domain controllers could generate more WAN traffic than placing a global catalog server in the site.
Therefore, you need to rationalize the WAN costs when exceeding 500 security principals and two domain
controllers.
• Tolerance for high latency in group updates. Because domain controllers in the site where Universal Group
Membership Caching is enabled update the membership caches every eight hours, and because
credentials are always taken from the cache, updates to group memberships are not reflected in the
security principal’s credentials for up to eight hours.
Address Book Lookups

Exchange Server uses the global catalog to store mail recipient data that enables clients in a forest to send and
receive e-mail messages.
Global Catalog Dependencies and Interactions

Global catalog servers have the following dependencies and interactions with other Windows Server technologies:
• AD DS installation. When AD DS is installed on the first domain controller in a forest, the installation
application creates that domain controller as a global catalog server.
• AD DS replication. The global catalog is built and maintained by AD DS replication:
• Subsequent to forest creation, when a domain controller is designated as a global catalog server,
AD DS replication automatically transfers PAS replicas to the domain controller, including the partial
replica of every domain in the forest other than the local domain.
• To facilitate intersite replication of global catalog server updates, AD DS replication selects global
catalog servers as bridgehead servers whenever a global catalog server is present in a site and
domains that are not present in the site exist in other sites in the forest.
• Domain Name System (DNS). Global catalog server clients depend on DNS to provide the IP address of
global catalog servers. DNS is required to advertise global catalog servers for domain controller location.
• Net Logon service. Global catalog advertisement in DNS depends on the Net Logon service to perform DNS
registrations. When replication of the global catalog is complete, or when a global catalog server starts,
the Net Logon service publishes service (SRV) resource records in DNS that specifically advertise the
domain controller as a global catalog server.
• Domain controller Locator: When a global catalog server is requested (by a user or application that
launches a search over port 3268, or by a domain controller that is authenticating a user logon), the
domain controller Locator queries DNS for a global catalog server.
In the following diagram, global catalog interactions include tracking a global catalog server through the following
interactions, which are indicated by boxes:
• Active Directory installation of a new forest: Global catalog creation occurs during AD DS installation
of the first domain controller in the forest.

• Net Logon registration: Resource records are registered in DNS to advertise the domain controller as a
global catalog server.
• AD DS replication:
• When a new domain controller (DC2) is created and an administrator designates it as a global
catalog server, replication of the PAS from DC1 occurs.
• DC1 in DomainA replicates changes for DomainA to DC2, and DC2 replicates updates to data for
DomainB to DC1.
• DC location: The dotted lines enclose the processes whereby two clients locate a global catalog server by
querying DNS:
• A through C: (A) ClientX sends a query to the global catalog, which prompts (B) a DNS query to
locate the closest global catalog server, and then (C) the client contacts the returned global catalog
server DC2 to resolve the query.
• 1 through 5: (1) ClientY logs on to the domain, which prompts (2) a DNS query for the closest
domain controllers. (3) ClientY contacts the returned domain controller DC3 for authentication. (4) DC3
queries DNS to find the closest global catalog server and then (5) contacts the returned global catalog
server DC2 to retrieve the universal groups for the user.
Interactions with Other Windows Technologies

The global catalog solves the problem of how to locate domain data that is not stored on a domain controller in the
domain of the client that requires the information. By using different ports for standard LDAP queries (port 389)
and global catalog queries (port 3268), AD DS effectively separates forest-wide queries that require a global
catalog server from local, domainwide queries that can be serviced by the domain controller in the user’s domain.
What Is Active Directory Replication Topology?

What Is Active Directory Replication Topology?

In this section
• Replication Within and Between Sites
• Technologies Related to Active Directory Replication Topology
• Active Directory Replication Topology Dependencies
Replication of updates to Active Directory objects are transmitted between multiple domain controllers to keep
replicas of directory partitions 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.
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 AD DS.
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. Site objects can be configured to
include a set of subnets that provide local area network (LAN) network speeds. As such, replication within sites
generally occurs at high speeds between domain controllers that are on the same network segment. Similarly, site
link objects can be configured to represent the wide area network (WAN) links that connect LANs. Replication
between sites usually occurs over these WAN links, which might be costly in terms of bandwidth. To accommodate
the differences in distance and cost of replication within a site and replication between sites, the intrasite
replication topology is created to optimize speed, and the intersite replication topology is created to minimize cost.
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 (from what source domain controller to what destination
domain controller) to create these connections.
Replication Within and Between Sites

The KCC creates separate replication topologies to transfer Active Directory updates within a site and between all
configured sites in the forest. The connections that are used for replication within sites are created automatically
with no additional configuration. Intrasite replication takes advantage of LAN network speeds by providing
replication as soon as changes occur, without the overhead of data compression, thus maximizing CPU efficiency.
Intrasite replication connections form a ring topology with extra shortcut connections where needed to decrease
latency. The fast replication of updates within sites facilitates timely updates of domain data. In deployments
where large datacenters constitute hub sites for the centralization of mission-critical operations, directory
consistency is critical.
Replication between sites is made possible by user-defined site and site link objects that are created in Active
Directory to represent the physical LAN and WAN network infrastructure. When Active Directory sites and site links
are configured, the KCC creates an intersite topology so that replication flows between domain controllers across
WAN links. Intersite replication occurs according to a site link schedule so that WAN usage can be controlled, and is
compressed to reduce network bandwidth requirements. Site link settings can be managed to optimize replication
routing over WAN links. The connections that are created between sites form a spanning tree for each directory
partition in the forest, merging where common directory partitions can be replicated over the same connection.
In remote branch locations, replication of updates from the hub sites is optimized for network availability. Thus,
because intrasite replication is optimized for speed, branch locations across WAN links can be assured of receiving
data from hub sites that is up-to-date and reliable; but because intersite replication is scheduled, branch sites
receive this replication only at intervals that are deemed appropriate and cost-effective for remote operations.
Technologies Related to Active Directory Replication Topology

The following technologies interact with Active Directory replication.
File Replication Service

File Replication service (FRS) is related to Active Directory replication because it requires the Active Directory
replication topology. FRS is a multimaster replication service that is used to replicate files and folders in the system
volume (SYSVOL) shared folder on domain controllers and in Distributed File System (DFS) shared folders. FRS
works by detecting changes to files and folders and then replicating the updated files and folders to other replica
members, which are connected in a replication topology.
FRS uses the replication topology that is generated by the KCC to replicate the SYSVOL files to all domain
controllers in the domain. SYSVOL files are required by all domain controllers for Active Directory to function. For
more information about FRS and how it uses the Active Directory replication topology, see “FRS Technical
Reference”. For more information about SYSVOL, see “Data Store Technical Reference.”
SMTP
Simple Mail Transfer Protocol (SMTP) is a packaging protocol that can be used as an alternative to the remote
procedure call (RPC) replication transport. SMTP can be used to transport nondomain replication over IP networks
in mail-message format. Where networks are not fully routed, e-mail is sometimes the only transport method
available.
Active Directory Replication Topology Dependencies

Active Directory replication topology has the following dependencies:
• Routable IP infrastructure. The replication topology is dependent upon a routable IP infrastructure
from which you can map IP subnet address ranges to site objects. This mapping generates the information
that is used by client workstations to communicate with domain controllers that are close by, when there
is a choice, rather than those that are located across WAN links.
• DNS. The Domain Name System (DNS) resolves DNS names to IP addresses. Active Directory replication
topology requires that DNS is properly designed and deployed so that domain controllers can correctly
resolve the DNS names of replication partners.
DNS also stores service (SRV) resource records that provide site affinity information to clients searching
for domain controllers, including domain controllers that are searching for replication partners. Every
domain controller registers these records so that they can be located according to site.
• Net Logon service. Net Logon is required for DNS registrations.
• RPC. Active Directory replication requires IP connectivity and RPC to transfer updates between replication
partners within sites. RPC is required for replication between two sites containing domain controllers in the
same domain, but SMTP is an alternative where RPC cannot be used and domain controllers for the same
domain are all located in one site so that intersite replication of domain data is not required.
• Intersite Messaging. Intersite Messaging is required for SMTP intersite replication and for site coverage
calculations. If the forest functional level is Windows 2000, Intersite Messaging is also required for
intersite topology generation.
The following diagram shows the interaction of these technologies with the replication topology, which is indicated
by the two-way connections between each set of domain controllers.
Replication Topology and Dependent Technologies
Active Directory Service Interfaces

Purpose
Active Directory Service Interfaces (ADSI) is a set of COM interfaces used to access the features
of directory services from different network providers. ADSI is used in a distributed computing
environment to present a single set of directory service interfaces for managing network
resources. Administrators and developers can use ADSI services to enumerate and manage the
resources in a directory service, no matter which network environment contains the resource.
ADSI enables common administrative tasks, such as adding new users, managing printers, and
locating resources in a distributed computing environment.
Where Applicable
Network Administrators can use ADSI to automate common tasks, such as adding users and
groups, managing printers, and setting permissions on network resources.
Independent Software Vendors and end-user developers can use ADSI to "directory enable" their
products and applications. Services can publish themselves in a directory, clients can use the
directory to find the services, and both can use the directory to find and manipulate other objects
of interest. Because Active Directory Service Interfaces are independent of the underlying
directory service(s), directory-enabled products and applications can operate successfully in
multiple network and directory environments.
Developer Audience
You can write ADSI client applications in many languages. For most administrative tasks, ADSI
defines interfaces and objects accessible from Automation-compliant languages like Microsoft
Visual Basic, Microsoft Visual Basic Scripting Edition (VBScript), and Java to the more
performance and efficiency-conscious languages such as C and C++. A good foundation in COM
programming is useful to the ADSI programmer.
Run-Time Requirements
Active Directory runs on Windows Server 2008, Microsoft Windows Server 2003, and
Windows 2000 Server domain controllers. However, client applications using ADSI may be written
and run on Windows Vista, Windows XP, Windows 2000, Windows NT 4.0, Windows 98, and
Windows 95. In addition, developers will want the Platform Software Development Kit (SDK), also
available on the MSDN Web site. To investigate the contents of Active Directory, use the Active
Directory Users and Computers MMC snap-in. This snap-in replaces the Adsvw tool that was
available for previous versions of Windows.
In This Section
Topic Description
About ADSI General information about ADSI.

Using ADSI Programmer's Guide to using ADSI.
ADSI Quick-start Tutorials Using ADSI with Automation to manage directories.
ADSI Reference Documentation of ADSI interfaces and methods.
Domain and Forest Trusts Technical Reference

2003 with SP2
Trust technology is the foundation for the security architecture in Microsoft Windows Server 2003 networks using
the Active Directory directory service. Trusts enable service administrators to implement an authentication and
authorization strategy for sharing resources across domains or forests and provide a mechanism for centralizing
management of multiple domains and forests.
How Domain and Forest Trusts Work

Updated: August 10, 2010
In this section
• Trust Architecture
• Trust Processes and Interactions
• Network Ports used by Trusts
Active Directory provides security across multiple domains or forests through domain and forest trust relationships.
Before authentication can occur across trusts, Windows must first determine whether the domain being requested
by a user, computer or service has a trust relationship with the logon domain of the requesting account. To make
this determination, the Windows security system computes a trust path between the domain controller for the
server that receives the request and a domain controller in the domain of the requesting account.
The access control mechanisms provided by Active Directory and the Windows distributed security model provide
an optimal environment for the operation of domain and forest trusts. For these trusts to function properly, every
workstation and server must have a direct trust path to a domain controller in the domain in which it is located.
The trust path is implemented by the Net Logon service through an authenticated remote procedure call (RPC)
connection to the trusted domain authority, which is the domain controller. In addition, a secured channel extends
to other Active Directory domains through interdomain trust relationships. This secured channel is used to obtain
and verify security information, including security identifiers (SIDs) for users and groups.
This section describes the inner workings of trusts, discusses the various types of trusts that can be used, provides
a detailed list of referral and logon processes that involve trusts, and lists the network ports that trusts can use.
Trust Architecture
Applications integrated with Windows Server 2003 and Active Directory use components of the operating system to
establish and maintain trusts. A number of these components help form the trust architecture that provides an
effective communication infrastructure for Active Directory. These include authentication protocols, the Net Logon
service, the Local Security Authority (LSA), and the Trusted Domain Objects (TDOs) stored in Active Directory.
These trust components are shown in the following illustration.
Trust Components
NTLM Protocol (Msv1_0.dll)
The NTLM authentication protocol is dependent on the Net Logon service on domain controllers for client
authentication and authorization information. This protocol authenticates clients that do not use Kerberos
authentication. NTLM uses trusts to pass authentication requests between domains.
Kerberos Protocol (Kerberos.dll)

The Kerberos V5 authentication protocol is dependent on the Net Logon service on domain controllers for client
authentication and authorization information. The Kerberos protocol connects to an online Key Distribution Center
(KDC) and the Active Directory account store for session tickets. The Kerberos protocol also uses trusts for cross-
realm ticket-granting services (TGS) and to validate Privilege Attribute Certificates (PACs) across a secured
channel. The Kerberos protocol performs cross-realm authentication only with non-Windows-brand operating
system Kerberos realms such as an MIT Kerberos realm and does not need to interact with the Net Logon service.
Net Logon (Netlogon.dll)

The Net Logon service maintains a secured channel from a Windows-based computer to a domain controller. It is
also used in the following trust related processes:
• Trust setup and management – Net Logon helps maintain trust passwords, gathers trust information and
verifies trusts by interacting with the LSA process and the TDO. For Forest trusts, the trust information
includes the Forest Trust Information (FTInfo) record, which includes the set of namespaces that a trusted
forest claims to manage, annotated with a field that indicates whether each claim is actually trusted by
the trusting forest.
• Authentication – Supplies user credentials over a secured channel to a domain controller and returns the
domain SIDs and user rights for the user
• Domain controller location – Helps with finding or locating domain controllers in a domain or across
domains
• Pass-through validation – Credentials of users in other domains are processed by Net Logon. When a
trusting domain needs to verify the identity of a user, it passes the user’s credentials through Net Logon
to the trusted domain for verification
• Privilege Attribute Certificate (PAC) verification – When a server using the Kerberos protocol for
authentication needs to verify the PAC in a service ticket, it sends the PAC across the secure channel to its
domain controller for verification.
LSA (Lsasrv.dll)
The Local Security Authority (LSA) is a protected subsystem that maintains information about all aspects of local
security on a system (collectively known as local security policy) and provides various services for translation
between names and identifiers. The LSA security subsystem provides services in both kernel mode and user mode
for validating access to objects, checking user privileges, and generating audit messages. LSA is responsible for
checking the validity of all session tickets presented by services in trusted or untrusted domains.
Tools
Administrators can use Active Directory Domains and Trusts, Netdom and Nltest to expose, create, remove or
modify trusts. Active Directory Domains and Trusts is the Microsoft Management Console (MMC) that is used to
administer domain trusts, domain and forest functional levels, and user principal name suffixes. The Netdom and
Nltest command line tools can be used to find, display, create and manage trusts. These tools communicate
directly with the LSA authority on a domain controller.
Active Directory
The Active Directory directory service stores information about objects on a network and makes this information
available to users and network administrators. Trusts can be used to extend the reach of Active Directory domains
and forests to other domains, forests or realms within an organization.
Trusted Domain Object

Each domain or forest trust within an organization is represented by a Trusted Domain Object (TDO) stored in the
System container within its domain.
TDO Contents
The information contained in a TDO can vary depending on whether a TDO was created by a domain trust or by a
forest trust. When a domain trust is created, attributes such as the DNS domain name, domain SID, trust type,
trust transitivity, and the reciprocal domain name are represented in the TDO. Forest trust TDOs store additional
attributes to identify all of the trusted namespaces from the partner forest. These attributes include domain tree
names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID)
namespaces.
Because trusts are stored in Active Directory as TDOs, all domains in a Windows Server 2003 forest have
knowledge of the trust relationships that are in place throughout the forest. Similarly, when two or more forests
are joined together through forest trusts, the forest root domains in each forest have knowledge of the trust
relationships that are in place throughout all of the domains in trusted Windows Server 2003 forests. External
trusts to a Windows NT 4.0 domain do not create TDOs in Active Directory.
TDO Passwords
Both domains in a trust relationship share a password, which is stored in the TDO object in Active Directory. As
part of the account maintenance process, every thirty days, the trusting domain controller changes the password
stored in the TDO. Because all two-way trusts are actually two one-way trusts going in opposite directions, the
process occurs twice for two-way trusts. To change a password, domain controllers in domains on each side of the
trust complete the following process:
1. The primary domain controller (PDC) emulator in the trusting domain creates a new password.
A domain controller in the trusted domain never initiates the password change; it is always initiated by the
trusting domain PDC emulator.
2. The domain controller in the trusting domain sets the OldPassword field of the TDO object to the previous
NewPassword field.
3. The domain controller in the trusting domain sets the NewPassword field of the TDO object to the new
password.
Keeping a copy of the previous password makes it possible to revert to the old password if the domain
controller in the trusted domain fails to receive the change, or if the change is not replicated before a
request is made that uses the new trust password.
4. The domain controller in the trusting domain makes remote call to a domain controller in the trusted
domain asking it to set the password on the trust account to the new password.
5. The domain controller in the trusted domain changes the trust password to the new password.
The password is now changed on both domain controllers. Normal replication distributes the TDO objects to the
other domain controllers in the domain. However, is possible for the domain controller in the trusting domain to
change the password without successfully updating a domain controller in the trusted domain. This might occur
because a secured channel, which is required to process the password change, could not be established. It is also
possible that the domain controller in the trusted domain might be unavailable at some point during the process
and might not receive the updated password.
To deal with situations in which the password change is not successfully communicated, the domain controller in
the trusting domain never changes the new password unless it has successfully authenticated (set up a secured
channel) using the new password. This is why both the old and new passwords are kept in the TDO object of the
trusting domain. Because a password change is not finalized until authentication using the password succeeds, the
old, stored password can be used over the secured channel until the domain controller in the trusted domain
receives the new password, thus enabling uninterrupted service.
If authentication using the new password fails because the password is invalid, the trusting domain controller tries
to authenticate using the old password. If it authenticates successfully with the old password, it resumes the
password change process within 15 minutes.
Most trust passwords propagate to all domain controllers within a day. Trust passwords have a default lifetime of
30 days, by which time all domain controllers will have received the new password.
Practical Limitations of Trusts

While Windows Server 2003 can support a large number of trusts between many security authorities, and there are
some limitations to trust functionality. These limitations are associated with the number of TDOs, the length of
trust paths, and the ability of clients to discover available trusts.
Number of TDOs
TDOs are associated with domains, and as the number of TDOs increases, the processing performance of these
links declines. Testing indicates that the time to complete operations related to TDOs, such as authentication
across domains, deteriorates noticeably if the Active Directory implementation in an organization contains more
than 2400 TDOs. Few organizations, however, require such a large number of trusts, and Windows Server 2003
places no absolute limit on the number of trust links that a domain can maintain with other domains or forests.
Trust Path Limits

There is a limit to the number of trust links that can be used effectively in a Windows Server 2003 network. In
Windows Server 2003, Kerberos clients can traverse a maximum of 10 trust links to locate a requested resource in
another domain. If the trust path between the domains exceeds this limit, the attempt to access the domain fails.
This problem can be addressed by creating external trusts to target domains in order to bypass excessively long
trust paths.
Trust Search Limits

When a client searches out a trust path, the search is limited to trusts that are established directly with a domain
and those that are transitive within a forest. A child domain, for example, cannot use an external trust between its
parent domain and a domain in another forest. This is because a complete trust path must be constructed before a
client can begin to work its way along the path to a requested resource domain. Windows Server 2003 does not
support blind referrals; if a client cannot identify a trust path, it will not attempt to seek access to a requested
resource in another domain. Child domains cannot identify external trusts or realm trusts to security authorities
outside of their forest because the TDOs that represent those trusts are published only within the domain that
shares the trust, not to Global Catalogs. Clients are therefore unaware of trusts that their domains share with
security authorities other than their parent or child domains, and are thus unable to use them to access resources.
Trust Flow
The flow of secured communications over trusts determines the elasticity of a trust: how you create or configure a
trust determines how far the communication extends within a forest or across forests. The flow of communication
over trusts is determined by the direction of the trust (one-way or two-way) and the transitivity of the trust
(transitive or nontransitive).
One-Way and Two-Way Trusts

Trust relationships that are established to enable access to resources can be either one-way or two-way. A one-
way trust is a unidirectional authentication path created between two domains. In a one-way trust between
Domain A and Domain B, users in Domain A can access resources in Domain B. However, users in Domain B cannot
access resources in Domain A. Some one-way trusts can be either nontransitive or transitive depending on the type
of trust being created.
All domain trusts in an Active Directory forest are two-way, transitive trusts. When a new child domain is created,
a two-way, transitive trust is automatically created between the new child domain and the parent domain. In a
two-way trust, Domain A trusts Domain B and Domain B trusts Domain A. This means that authentication requests
can be passed between the two domains in both directions. Some two-way relationships can be nontransitive or
transitive depending on the type of trust being created. An Active Directory domain can establish a one-way or
two-way trust with:
• Windows Server 2003 domains in the same forest.
• Windows Server 2003 domains in a different forest.
• Windows NT 4.0 domains.
• Kerberos V5 realms.
Transitive and Nontransitive Trusts

Transitivity determines whether a trust can be extended outside of the two domains with which it was formed. A
transitive trust can be used to extend trust relationships with other domains; a nontransitive trust can be used to
deny trust relationships with other domains.
Each time you create a new domain in a forest, a two-way, transitive trust relationship is automatically created
between the new domain and its parent domain. If child domains are added to the new domain, the trust path
flows upward through the domain hierarchy extending the initial trust path created between the new domain and
its parent domain. Transitive trust relationships flow upward through a domain tree as it is formed, creating
transitive trusts between all domains in the domain tree.
Authentication requests follow these trust paths, so accounts from any domain in the forest can be authenticated
by any other domain in the forest. With a single logon process, accounts with the proper permissions can access
resources in any domain in the forest. The following figure shows that all domains in Tree 1 and Tree 2 have
transitive trust relationships by default. As a result, users in Tree 1 can access resources in domains in Tree 2 and
users in Tree 1 can access resources in Tree 2, when the proper permissions are assigned at the resource.
Default Transitive Trust Relationships
In addition to the default transitive trusts established in a Windows Server 2003 forest, by using the New Trust
Wizard you can manually create the following transitive trusts.
• Shortcut trust. A transitive trust between domains in the same domain tree or forest that is used to
shorten the trust path in a large and complex domain tree or forest.
• Forest trust. A transitive trust between one forest root domain and another forest root domain.
• Realm trust. A transitive trust between an Active Directory domain and a Kerberos V5 realm.
A nontransitive trust is restricted to the two domains in the trust relationship and does not flow to any other
domains in the forest. A nontransitive trust can be a two-way trust or a one-way trust.
Nontransitive trusts are one-way by default, although you can also create a two-way relationship by creating two
one-way trusts. Nontransitive domain trusts are the only form of trust relationship possible between:
• A Windows Server 2003 domain and a Windows NT domain

• A Windows Server 2003 domain in one forest and a domain in another forest (when not joined by a forest
trust)
By using the New Trust Wizard, you can manually create the following nontransitive trusts:
• External trust. A nontransitive trust created between a Windows Server 2003 domain and a Windows NT,
Windows 2000, or Windows Server 2003 domain in another forest. When you upgrade a Windows NT
domain to a Windows Server 2003 domain, all existing Windows NT trusts are preserved intact. All trust
relationships between Windows Server 2003 domains and Windows NT domains are nontransitive.
• Realm trust. A nontransitive trust between an Active Directory domain and a Kerberos V5 realm.
Trust Types
Although all trusts enable authenticated access to resources, trusts can have different characteristics. The types of
domains included in the trust relationship affect the type of trust that is created. For example, a trust between two
child domains in different forests is always an external trust, but trusts between two Windows Server 2003 forest
root domains can be either external trusts or forest trusts.
Two types of trusts are created automatically when you use the Active Directory Installation Wizard. Four other
types of trusts can be manually created by using either the New Trust Wizard or the Netdom command-line tool.
Automatic Trusts
By default, two-way transitive trusts are automatically created when a new domain is added to a domain tree or
forest root domain by using the Active Directory Installation Wizard. The two default trust types are parent-child
trusts and tree-root trusts.
Parent-child trust
A parent-child trust relationship is established whenever a new domain is created in a tree. The Active Directory
installation process automatically creates a trust relationship between the new domain and the domain that
immediately precedes it in the namespace hierarchy (for example, corp.tailspintoys.com is created as the child of
tailspintoys.com). The parent-child trust relationship has the following characteristics:
• It can exist only between two domains in the same tree and namespace.
• The parent domain is always trusted by the child domain.
• It must be transitive and two-way. The bidirectional nature of transitive trust relationships allows the
global directory information in Active Directory to replicate throughout the hierarchy.
Tree-root trust
A tree-root trust is established when you add a new domain tree to a forest. The Active Directory installation
process automatically creates a trust relationship between the domain you are creating (the new tree root) and the
forest root domain. A tree-root trust relationship has the following restrictions:
• It can be established only between the roots of two trees in the same forest.
• It must be transitive and two-way.
Manual Trusts
In Windows Server 2003 there are four trust types that must be created manually: shortcut trusts are used for
optimization between domain trees in the same forest; external, realm, and forest trusts help provide
interoperability with domains outside of the forest, with other forests, or with realms. These trust types must be
created by using the New Trust Wizard or the Netdom command-line tool.
Shortcut Trusts
Shortcut trusts are one-way or two-way transitive trusts that can be used when administrators need to optimize
the authentication process. Authentication requests must initially travel a trust path between domain trees. A trust
path is the series of domain trust relationships that must be traversed in order to pass authentication requests
between any two domains. In a complex forest, the time required to traverse the trust path can impact
performance. You can significantly reduce this time by using shortcut trusts.
Shortcut trusts speed up logon and access times to resources in a domain that is deep within the hierarchy of
another domain tree. The following figure illustrates trust relationships between two trees in a Windows
Server 2003 forest.
Trusts Within a Single Windows 2000 Server or Windows Server 2003 Forest
In this example, the following conditions are true:
• A two-way transitive tree-root trust exists between corp.tailspintoys.com and corp.wingtiptoys.com.
• Parent-child trust relationships exist between parent and child domains in both trees of the forest.
Because the two trees trust each other, all domains in Tree 1 and Tree 2 have access to resources in all
domains in the forest.
• A one-way shortcut trust exists between the rome.europe.corp.tailspintoys.com and
usa.corp.wingtiptoys.com domains. This creates an alternate path by which users in the

usa.corp.wingtiptoys.com domain can access resources in the rome.europe.corp.tailspintoys.com domain.
The shortcut trust shortens the trust path needed to reach the intended domain by cutting the number of
hops required for authentication from three (rome.europe.corp.tailspintoys.com to
europe.corp.tailspintoys.com to corp.tailspintoys.com to corp.wingtiptoys.com) to one
(rome.europe.corp.tailspintoys.com to usa.corp.wingtiptoys.com), which increases the speed of
authentication.
• Because the shortcut trust is one-way, authentication requests made from the
rome.europe.corp.tailspintoys.com domain to the usa.corp.wingtiptoys.com domain still need to travel the

longer trust path.
When a two-way shortcut trust is established between two domains located in separate domain trees, the time
needed to fulfill authentication requests originating in either domain is reduced. For example, when a two-way trust
is established between the usa.corp.wingtiptoys.com domain and the rome.europe.corp.tailspintoys.com domain,
authentication requests made from either domain to the other can utilize the new, two-way shortcut trust path.
External Trusts
An external trust is a trust relationship that can be created between Active Directory domains that are in different
forests or between an Active Directory domain and a Windows NT 4.0 or earlier domain. An external trust
relationship has the following characteristics:
• It is nontransitive.
• It must be established manually in each direction to create a two-way external trust relationship. In
Windows Server 2003 you can create both sides of the external two-way trust at once by using the New
Trust Wizard.
• It enforces SID filter quarantining by default in Windows Server 2003. External trusts created from the
trusting domain use SID filter quarantining to verify that incoming authentication requests made from
security principals in the trusted domain contain only SIDs of security principals in the trusted domain.
SID filter quarantining ensures that any misuse of the SID history attribute on security principals
(including inetOrgPerson) in the trusted forest cannot pose a threat to the integrity of the trusting forest.
External trusts provide access to resources in a domain outside of the forest that is not already joined by a forest
trust. The following illustration shows how external trusts can be used between a Windows Server 2003 forest and
a Windows 2000 forest.
External trusts Between a Windows Server 2003 Forest and a Windows 2000 Forest
In this example, two external trust relationships exist between domains in the Windows Server 2003 forest and the
Windows 2000 forest. The direction of the one-way external trust arrow indicates that the
sales.corp.worldwideimporters.com domain trusts the rome.europe.corp.tailspintoys.com domain, which means
that users in the rome.europe.corp.tailspintoys.com domain can access resources in the
sales.corp.worldwideimporters.com domain.
The direction of the two-way external trust arrow indicates that both the europe.corp.tailspintoys.com domain and
the sales.corp.worldwideimporters.com domain trust each other. This relationship allows for authentication
requests to be passed between the two domains, coming from either direction, to any shared resources in those
two domains.
This configuration allows:
• Users in the europe.corp.tailspintoys.com domain to access resources in the
sales.corp.worldwideimporters.com domain
• Users in the sales.corp.worldwideimporters.com domain to access resources in the
europe.corp.tailspintoys.com domain
• Users in the rome.europe.corp.tailspintoys.com domain to access resources in the
sales.corp.worldwideimporters.com domain
It does not allow:
• Users in the rome.europe.corp.tailspintoys.com domain or europe.corp.tailspintoys.com domain to access
resources in the corp.worldwideimporters.com domain
• Users in the sales.corp.worldwideimporters.com domain to access resources in either the
corp.tailspintoys.com or rome.europe.corp.tailspintoys.com domain

When a trust is established between a domain in a forest and a domain outside of that forest, security principals
from the external domain can access resources in the internal domain. Active Directory creates a foreign security
principal object in the internal domain to represent each security principal from the trusted external domain. These
foreign security principals can become members of domain local groups in the internal domain. Directory objects
for foreign security principals are created by Active Directory and should not be manually modified. You can view
foreign security principal objects from Active Directory Users and Computers by enabling advanced features.
The following figure illustrates a trust configuration that includes an external trust relationship between a domain in
a Windows Server 2003 forest and a Windows NT 4.0 domain.
External Trust Between a Windows NT 4.0 Domain and a Child Domain in a Windows Server 2003
Forest
This configuration allows users in the europe.corp.tailspintoys.com domain to access resources in the
Windows NT 4.0 domain. It does not allow the Windows NT 4.0 domain to access resources in the
europe.corp.tailspintoys.com domain or for any trusted domains that the europe.corp.tailspintoys.com domain
trusts.
All forest trusts in Windows Server 2003 Active Directory enforce SID filtering. Applying SID filtering to trusts helps
to prevent malicious users who have domain administrator level access in the trusted domain from granting to
themselves, or other user accounts in their domain, elevated user rights to the trusting domain.
Realm Trusts
A trust relationship can be established between a non-Windows Kerberos realm and a Windows 2000 or Windows
Server 2003 domain. This trust relationship allows cross-platform interoperability with security services based on
other Kerberos V5 implementations.
A non-Windows Kerberos realm trust relationship has the following characteristics:
• It is used only by the Kerberos V5 authentication protocol. It is not used by NTLM or other authentication
protocols.
• It is one-way by default. One-way trust relationships must be established in each direction to create a
two-way trust relationship. In Windows Server 2003 you can create both sides of the two-way realm trust
at once by using the New Trust Wizard.
• It is nontransitive by default, but can be made transitive.
• When the direction of trust is from a non-Windows Kerberos realm to a Windows Server 2003 domain, the
non-Windows Kerberos realm trusts all security principals in the Windows Server 2003 domain.
• When the direction of trust is from a Windows Server 2003 domain to a non-Windows Kerberos realm,
account mappings in Active Directory are used to map a foreign Kerberos identity in a trusted non-
Windows Kerberos realm to a local account identity in a Windows Server 2003 domain.
• The Windows Server 2003 domain uses only the account to which the non-Windows principal is mapped
(the proxy account) to evaluate access to domain objects that have security descriptors. This is required
because non-Windows Kerberos tickets do not contain all of the authorization data that is needed for
Windows Server 2003. All such Windows Server 2003 proxy accounts can be used in groups and on access
control lists (ACLs) to control access on behalf of the non-Windows security principal. MIT account
mappings are managed through Active Directory Users and Computers.
• When the direction of trust is from a non-Windows Kerberos realm to a Windows Server 2003 domain,
users in the Windows Server 2003 domain can access resources in the non-Windows Kerberos realm, as is
the case for Realm 1 in the following illustration. When the direction of trust is from a
Windows Server 2003 domain to a non-Windows Kerberos realm, users in the non-Windows Kerberos
realm can access the resources in the Windows Server 2003 domain, as is the case for Realm 1 and
Realm 2.
Transitive and Non-Transitive Realm Trusts from a Domain in a Windows Server 2003 Forest
This configuration allows:
• Users in Realm 1 and Realm 2 to access resources in the europe.corp.tailspintoys.com domain

• Users in the europe.corp.tailspintoys.com domain to access resources in Realm 1
It does not allow users in the europe.corp.tailspintoys.com domain to access resources in Realm 2.
Note
• In Windows 2000, if you create a non-Windows Kerberos realm trust relationship by using Active Directory
Domains and Trusts, the trust is one-way and nontransitive. To work around this, you can use the Netdom
tool (Netdom.exe) to establish two-way, transitive, non-Windows Kerberos realm trust relationships. In
Windows Server 2003, you can use the New Trust Wizard to create one-way or two-way and transitive or
nontransitive realm trusts.
Realm trusts are not as comprehensive as domain trusts. For instance, user principals from the Kerberos realm do
not have the authorization data that Windows Server 2003-based services need for access control. In order for this
authorization data to be added to the user’s ticket, an account mapping mechanism is used. Selected domain user
accounts are used to provide identity for Kerberos principals in the trusted realm. These mappings are kept on the
SecurityID property on the user account object. They can be managed through Active Directory Users and
Computers.
Forest Trusts
Forest trusts help you to manage a segmented Windows Server 2003 Active Directory infrastructure within your
organization by providing support for accessing resources and other objects across multiple Windows Server 2003
forests. Forest trusts are useful for Application Service Providers, companies undergoing mergers or acquisitions,
collaborative business extranets, and companies seeking a solution for administrative autonomy.
Forest trusts can provide the following benefits:
• Simplified management of resources across two Windows Server 2003 forests by reducing the number of
external trusts necessary to share resources.
• Complete two-way trust relationships with every domain in each forest.
• Use of user principal name (UPN) authentication across two forests.
• Use of both the Kerberos V5 and NTLM authentication protocols to improve the trustworthiness of
authorization data transferred between forests.
• Flexibility of administration. Administrative tasks can be unique to each forest.
• Secured data within each forest. Sensitive data can be protected so that only users within that forest can
access it.
• Isolated 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 in a trusting forest.
• Enforcement of SID filtering in Windows Server 2003. SID filtering ensures that any misuse of the SID
history attribute on security principals (including inetOrgPerson) in the trusted forest cannot pose a threat
to the integrity of the trusting forest.
Enforcing SID filtering on forest trusts does not prevent use of SID history in migrations to domains within
the same forest and does not affect your universal group access control strategy.
By using forest trusts you can link two different Windows Server 2003 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.
A forest trust can be created only between a forest root domain in one Windows Server 2003 forest and a forest
root domain in another Windows Server 2003 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 Windows
Server 2003 forests in a single organization.
Two Forest Trusts Between Three Windows Server 2003 Forests
In this example, a two-way transitive forest trust exists between the forest root domains in Forest 1 and Forest 2,
and another two-way transitive forest trust exists between the forest root domains in Forest 3 and Forest 2. This
configuration allows:
• Users in Forest 2 to access resources in any domain in either Forest 1 or Forest 3
• Users in Forest 3 to access resources in any domain in Forest 2
• Users in Forest 1 to access resources in any domain in Forest 2
This configuration does not allow users in Forest 1 to access resources in Forest 3 or vice versa. To allow users in
both Forest 1 and Forest 3 to share resources, a two-way transitive trust must be created between the two forests.
If a one-way forest trust is created between two forests, members of the trusted forest can utilize resources
located in the trusting forest. However, the trust operates in only one direction. For example, when a one-way,
forest trust is created between Forest 1 (the trusted forest) and Forest 2 (the trusting forest), members of Forest 1
can access resources located in Forest 2, but members of Forest 2 cannot access resources located in Forest 1
using the same trust.
Consequently, as shown in the example, a two-way forest trust between two forests allows members from either
forest to utilize resources located in the other forest; domains in each respective forest trust domains in the other
forest implicitly.
There are specific requirements that must be met for using forest trusts. Before you can create a forest trust, you
need to verify that all domain controllers in both forests are running Windows Server 2003. You also need to verify
that you have the correct Domain Name System (DNS) infrastructure in place and that you have established the
appropriate functionality level for Active Directory. This means that the forest must be raised to the Windows
Server 2003 functional level and that you cannot install additional Windows 2000 or Windows NT Server 4.0
domain controllers in the forest.
Forest trusts can only be created when one of the following DNS configurations is in place in your infrastructure:
• A single root DNS server is the root DNS server for both forest DNS namespaces: the root zone contains
delegations for each of the DNS namespaces and the root hints of all DNS servers include the root DNS
server.
• Where there is no shared root DNS server, and the root DNS servers for each forest DNS namespace are
running a member of the Windows Server 2003 family, DNS conditional forwarders are configured in each
DNS namespace to route queries for names in the other namespace.
• Where there is no shared root DNS server, and the root DNS servers for each forest DNS namespace are
not running a member of the Windows Server 2003 family, DNS secondary zones are configured in each
DNS namespace to route queries for names in the other namespace.
To create a forest trust, the administrator creating the trust must be a member of the Domain Admins group (in
the forest root domain) or the Enterprise Admins group in Active Directory. Each trust is assigned a password that
the administrators in both forests must know. Members of Enterprise Admins in both forests can create the trusts
in both forests at once and, in this scenario, a password that is cryptographically random is automatically
generated and written for both forests.
Members of the Incoming Forest Trust Builders group can create one-way, incoming forest trusts. For example,
members of this group residing in Forest A can create a one-way, incoming forest trust from Forest B. This one-
way, incoming forest trust allows users in Forest A to access resources located in Forest B. Members of this group
are granted the permission Create Inbound Forest Trust on the forest root domain. This group has no default
members.
All Windows NT Server 4.0, Windows 2000, Windows XP clients can use the forest trust for authentication.
However, Windows NT Server 4.0 clients support only NTLM and they do not support user principal names (UPNs)
for logging on to the network. Windows Server 2003 forest trusts cannot be created between a Windows
Server 2003 forest and a Windows 2000 forest.
Trust Processes and Interactions

Many inter-domain and inter-forest transactions depend on domain or forest trusts in order to complete various
tasks. This section describes the processes and interactions that occur as resources are accessed across trusts and
authentication referrals are evaluated.
Overview of Authentication Referral Processing

When a request for authentication is referred to a domain, the domain controller in that domain 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, before it authenticates the user to access resources in the
domain. The authentication process that occurs between trusted domains varies according to the authentication
protocol in use. The Kerberos V5 and NTLM protocols in Windows 2000 Server and Windows Server 2003 process
referrals for authentication to a domain differently, as do the other authentication protocols, such as Digest, and
SChannel, that Windows 2000 Server and Windows Server 2003 support.
Kerberos V5 Referral Processing

If the client uses Kerberos V5 for authentication, it requests a ticket to the server in the target domain from a
domain controller in its account domain. The Kerberos Key Distribution Center (KDC) acts as a trusted intermediary
between the client and server; it provides a session key that enables the two parties to authenticate each other. If
the target domain is different from the current domain, the KDC follows a logical process to determine whether an
authentication request can be referred:
1. Is the current domain trusted directly by the domain of the server that is being requested?
• If yes, send the client a referral to the requested domain.
• If no, go to the next step.
2. Does a transitive trust relationship exist between the current domain and the next domain on the trust
path?
• If yes, send the client a referral to the next domain on the trust path.
• If no, send the client a logon-denied message.
NTLM Referral Processing

If the client uses NTLM for authentication, the initial request for authentication goes directly from the client to the
resource server in the target domain. This server creates a challenge to which the client responds. The server then
sends the user’s response to a domain controller in its computer account domain. This domain controller checks the
user account against its security accounts database. If the account does not exist in the database, the domain
controller determines whether to perform pass-through authentication, forward the request, or deny the request by
using the following logic:
1. Does the current domain have a direct trust relationship with the user’s domain?
• If yes, the domain controller sends the credentials of the client to a domain controller in the
user’s domain for pass-through authentication.
• If no, go to the next step.
2. Does the current domain have a transitive trust relationship with the user’s domain?
• If yes, pass the authentication request on to the next domain in the trust path. This domain
controller repeats the process by checking the user’s credentials against its own security accounts
database.
• If no, send the client a logon-denied message.
Other Authentication Protocol Referral Processing

Windows 2000 Server and Windows Server 2003 also support both Digest and Schannel authentication across
forest trusts. This enables technologies such as Web servers to complete their tasks in a multiple domain
environment. The Secure Sockets Layer (SSL) protocol and certificate mapping to Active Directory user accounts
use Schannel, and Internet Information Services (IIS) uses Digest. Digest and SChannel authentication between
trusted domains might be required in cases where a firewall between trusting forests or domains allows only HTTP
traffic through. Digest can be carried in HTTP headers.
The Windows 2000 Server and Windows Server 2003 authentication negotiation determines the authentication
protocol that is used over trusts, as long as the generic pass-through mechanism can find the appropriate domain
controller in the target domain. Administrators can also choose to implement a security support provider (SSP) for
another authentication protocol. If the SSP is compatible with the Windows 2000 Server and Windows Server 2003
distributed systems, it will work over trusts across domain boundaries in the same way that standard
Windows 2000 Server and Windows Server 2003 SSPs work across domains.
Kerberos-Based Processing of Authentication Requests Over Domain Trusts

Active Directory domains within the same forest are implicitly connected by two-way, transitive trusts, so that
authentication requests from one domain to another are routed to provide a seamless access to resources across
domains. Domain controllers running Windows 2000 or Windows Server 2003 authenticate users and applications
using one of two authentication protocols: Kerberos V5 or NTLM. Once authenticated in their own domain, users
can attempt to gain access to resources from any domain in the forest using the Active Directory authorization
process.
To access a shared resource in another domain by using Kerberos authentication, a user’s computer 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 user’s computer and the server. The
user’s computer presents this trusted ticket to the server in the trusting domain for authentication.
The following illustration and corresponding steps provide a detailed description of the Kerberos authentication
process that is used when a computer running Windows 2000 Professional, Windows 2000 Server, Windows XP
Professional, or a member of the Windows Server 2003 family attempts to access resources from a server located
in another domain.
Kerberos Authentication Process Over Domain Trusts
1. User1 logs on to Workstation1 using credentials from the europe.corp.tailspintoys.com domain. As part of
this process, the authenticating domain controller issues User1 a ticket-granting ticket (TGT). This ticket is
required for User1 to be authenticated to resources. The user then attempts to access a shared resource
(\\fileserver1\share) on a file server located in the asia.corp.tailspintoys.com domain.
2. Workstation1 contacts the Kerberos Key Distribution Center (KDC) on a domain controller in its domain
(ChildDC1) and requests a service ticket for the FileServer1 service principal name (SPN).
3. ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any
domains in the forest contain this SPN. The global catalog sends the requested information back to
ChildDC1.
4. ChildDC1 sends the referral to Workstation1.
5. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain
controller (ChildDC2) in the Child2 domain. ForestRootDC1 sends the referral to Workstation 1.
6. Workstation1 contacts the KDC on ChildDC2 and negotiates a ticket for the user to gain access to
FileServer1.
7. Once Workstation1 has a service ticket, it sends the ticket to FileServer1, which reads the user’s security
credentials and constructs an access token accordingly.
Each domain has its own set of security policies governing access to resources. These policies do not cross from
one domain to another.
Kerberos-Based Processing of Authentication Requests Over Forest Trusts

When two Windows Server 2003 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.
When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and
stores the information in a TDO. Trusted namespaces include domain tree names, user principal name (UPN)
suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. TDO
objects are replicated to the global catalog.
Before authentication protocols can follow the forest trust path, the service principal name (SPN) of the resource
computer must be resolved to a location in the other forest. An SPN can be one of the following: the Domain Name
System (DNS) name of a host, the DNS name of a domain, or the distinguished name of a service connection point
object.
When a workstation in one forest attempts to access data on a resource computer in another forest, 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.
The following illustration and corresponding steps provide a detailed description of the Kerberos authentication
process that is used when computers running Windows 2000 Professional, Windows XP Professional, Windows 2000
Server, or a member of the Windows Server 2003 family attempt to access resources from a computer located in
another forest.
Kerberos Authentication Process Over Forest Trusts

1. User1 logs on to Workstation1 using credentials from the europe.corp.tailspintoys.com domain. The user
then attempts to access a shared resource on FileServer1 located in the usa.corp.wingtiptoys.com forest.
2. Workstation1 contacts the Kerberos Key Distribution Center (KDC) on a domain controller in its domain
(ChildDC1) and requests a service ticket for the FileServer1 SPN.
3. ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any
domains in the tailspintoys.com forest contain this SPN. Because a global catalog is limited to its own
forest, the SPN is not found. The global catalog then checks its database for information about any forest
trusts that are established with its forest, and, if found, it compares the name suffixes listed in the forest
trust trusted domain object (TDO) to the suffix of the target SPN to find a match. Once a match is found,
the global catalog provides a routing hint back to ChildDC1. Routing hints help direct authentication
requests toward the destination forest, and are only used when all traditional authentication channels
(local domain controller and then global catalog) fail to locate a SPN.
4. ChildDC1 sends a referral for its parent domain back to Workstation1.
5. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain
controller (ForestRootDC2) in the forest root domain of the wingtiptoys.com forest.
6. Workstation1 contacts ForestRootDC2 in the wingtiptoys.com forest for a service ticket to the requested
service.
7. ForestRootDC2 contacts its global catalog to find the SPN, and the global catalog finds a match for the
SPN and sends it back to ForestRootDC2.
8. ForestRootDC2 then sends the referral to usa.corp.wingtiptoys.com back to Workstation1.
9. Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for User1 to gain access to
FileServer1.
10. Once Workstation1 has a service ticket, it sends the service ticket to FileServer1, which reads User1’s
security credentials and constructs an access token accordingly.
Network Ports used by Trusts

Because trusts must be deployed across various network boundaries, they might have to span one or more
firewalls. When this is the case, you can either tunnel trust traffic across a firewall or open specific ports in the
firewall to allow the traffic to pass through. In Windows Server 2003, this procedure is simplified through
configurable remote procedure call (RPC) ports for the main trust services. The two main configurable RPC ports
are the Local Security Authority RPC port and the Net Logon RPC port.
The Local Security Authority (LSA) RPC port.
This port is used for trust creation and other access to the LSA policy database.
The Net Logon RPC port.
This port is used for NTLM authentication and secured channel communications.
The following table shows the list of ports that might need to be opened before you establish trusts.
Ports Required for Trusts
Task Outbound Ports Inbound Ports From–To
Set up trusts on both sides from LDAP (389 UDP and N/A Internal domain domain
the internal forest TCP) controllers–External
Microsoft SMB (445 domain domain controllers
TCP) (all ports)
Kerberos (88 UDP)
Endpoint resolution —
portmapper (135 TCP)
Net Logon fixed port
Trust validation from the internal LDAP (389 UDP) N/A Internal domain domain
forest domain controller to the Microsoft SMB (445 controllers–External
external forest domain controller TCP) domain domain controllers
(outgoing trust only) (all ports)
Use Object picker on the external N/A LDAP (389 UDP and External server–Internal
forest to add objects that are in TCP) domain PDCs (Kerberos)
an internal forest to groups and Windows NT Server 4.0 External domain domain
DACLs directory service fixed controllers–Internal domain
port domain controllers (Net
Net Logon fixed port Logon)
Kerberos (88 UDP)
Endpoint resolution
Set up trust on the external forest N/A LDAP (389 UDP and External domain domain
from the external forest TCP) controllers–Internal domain
Microsoft SMB (445 domain controllers (all
TCP) ports)
Kerberos (88 UDP)
Use Kerberos authentication Kerberos (88 UDP) N/A Internal client–External

(internal forest client to external domain domain controllers
forest) (all ports)
Use NTLM authentication (internal N/A Endpoint resolution – External domain domain
forest client to external forest) portmapper (135 TCP) controllers–Internal domain
Net Logon fixed port domain controllers (all
ports)
Join a domain from a computer in LDAP (389 UDP and N/A Internal client–External
the internal network to an TCP) domain domain controllers
external domain Microsoft SMB (445 (all ports)
TCP)
Kerberos (88 UDP)
Windows NT Server 4.0

directory service fixed
port
To specify the services that you want to run on a fixed port, you must appropriately configure the registry for that
port.
The information here is provided as a reference for use in troubleshooting or verifying that the required settings
are applied. It is recommended that you do not directly edit the registry unless there is no other alternative.
Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as
a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use
Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather
than editing the registry directly. If you must edit the registry, use extreme caution.
Settings for the Local Security Authority (LSA) RPC port are stored in the TCP/IP Port entry in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters registry key.
Settings for the Net Logon RPC port are stored in the DCTcpipPort entry in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry key.
Active Directory Lightweight Directory Services
Purpose
Microsoft Active Directory Lightweight Directory Services (AD LDS) is an independent mode of
Active Directory that provides dedicated directory services for applications.
Where Applicable
Although AD LDS independently provides directory storage and access for applications, AD LDS
uses the same standard application programming interfaces (APIs) as Active Directory to manage
and access the application data. The resulting conceptual and programming compatibility makes
AD LDS ideal for applications that require directory services, but do not require the complete
infrastructure features of Active Directory.
Developer Audience
AD LDS is a directory services solution for developers who are familiar with programming for
Active Directory. Developers who are unfamiliar with Active Directory will find that integrating AD
LDS as a directory service for their applications is easier than using the complete features of
Active Directory. In both cases, AD LDS provides a directory services solution for developers who
seek compatibility and consistency with Active Directory.
Run-Time Requirements
AD LDS runs with the full feature set on the Microsoft Windows Server 2008 operating system.
Previous versions of AD LDS (ADAM) can run on any edition of Windows Server 2003 and on
Microsoft Windows XP Professional.
In This Section
Topic Description
About Active Directory Lightweight Directory General information about AD LDS.

Services
Using Active Directory Lightweight Directory Tasks and examples of programming with AD
Services LDS.
Active Directory Lightweight Directory Services AD LDS programming elements.
Reference

Active Directory

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Active Directory

Caricato da

Copyright:

Formati disponibili

Active Directory

Active Directory is a technology created by Microsoft that provides a variety of network

Forests, trees, and domains

Example of the geographical organizing of zones of

Flat-filed, simulated hierarchy

Structural divisions to improve performance

The actual division of an organization's information infrastructure into a hierarchy of one or

Role Name Scope Description

Trusts in Windows 2000 (native mode)

Windows 2000 Server – supports the following types of trusts:

• Two-way transitive trusts.

Additional trusts can be created by administrators. These trusts can be:

Integrating Unix into Active Directory

Active Directory Operations Guide

Sites are used in Active Directory to:

• Optimize replication between domain controllers.

The KCC and Replication Topology

Bridgehead Server Selection

Site Management Tasks and Procedures

Table 1.21 Site Management Tasks and Procedures

Tasks Procedures Tools Frequency

Add a new site. • Create a site object. • Active As needed

• Create a subnet object and associate Directory Sites

it with the site.or and Services

• Associate an existing subnet object

you are linking. Directory Sites

• Determine the ISTG role owner for a

• Determine the ISTG role owner for a

subnet and determine the site • DNS snap-in

Remove a site. • Determine whether the server object • Active As needed

has child objects. Directory Sites

from the site.

• Delete the site object.

• Determine the ISTG role owner for a

Adding a New Site

• An existing site is directly connected to more than 20 sites.

• A bridgehead server has more than 20 inbound connections.

• The forest has 200 or more sites.

Procedures for Adding a New Site

1. Create a site object and add it to an existing site link.

2. Associate a range of IP addresses with the site, as follows:

• Associate an existing subnet object with the new site.

Adding a Subnet to the Network

Procedures for Adding a Subnet

2. Create a subnet object and associate it with the appropriate site.

Linking Sites for Replication

Procedures for Creating a Site Link

1. Determine the names of the sites you are linking.

a. Determine the ISTG role owner for the site.

b. Generate the replication topology on the ISTG.

Changing Site Link Properties

These settings control intersite replication as follows:

open schedule window (default is every 180 minutes).

over other higher-cost links.

Procedures for Configuring Site Links

a. Determine the ISTG role owner for the site.

b. Generate the replication topology on the ISTG.

Moving a Domain Controller to a Different Site

• IP address, including the subnet mask and default gateway.

• DNS server addresses.

• WINS server addresses (if appropriate).

preferred or alternate DNS server.

Preferred Bridgehead Server Status