Active Directory Structure

Active Directory Structure and Storage
Technologies
The Active Directory structure and storage architecture consists of four parts:
 Active Directory domains and forests. Forests, domains, and organizational units (OUs)
make up the core elements of the Active Directory logical structure. A forest defines a
single directory and represents a security boundary. Forests contain domains.
 Domain Name System (DNS) support for Active Directory. DNS provides a name
resolution service for domain controller location and a hierarchical design that
Active Directory can use to provide a naming convention that can reflect organizational
structure.
 Schema. The schema provides object definitions that are used to create the objects that
are stored in the directory.
 Data store. The data store is the portion of the directory that manages the storage and
retrieval of data on each domain controller.
The following figure illustrates the Active Directory data structure and storage
architecture.
Active Directory Data Structure and Storage Architecture

Active Directory Domains and Forests
Domains partition the directory into smaller sections within a single forest. This
partitioning results in more control over how data is replicated so that an efficient
replication topology can be established and network bandwidth is not wasted by
replicating data where it is not required. OUs make it possible to group resources in a
domain for management purposes, such as applying Group Policy or delegating control
to administrators.
The following figure illustrates the relationships of OUs, domains, and forests in the
logical structure architecture.
Logical Structure Architecture

DNS Support for Active Directory
Active Directory uses DNS as its domain controller location mechanism. When any of the
principal Active Directory operations, such as authentication, updating, or searching, is
performed, domain joined computers use DNS to locate Active Directory domain
controllers, and these domain controllers use DNS to locate each other. For example,
when a network user with an Active Directory user account logs on to an
Active Directory domain, the user’s computer uses DNS to locate a domain controller for
the Active Directory domain to which the user wants to log on.
To log on to a network that consists of an Active Directory forest, a client workstation
must first be able to locate a nearby domain controller. The domain controller is
necessary for initial authentication of both the workstation and the user and for
subsequent authorization of the user for the files and resources to which the user needs
access. The support that is provided to Active Directory by DNS enables a client
workstation to locate a domain controller.
Active Directory Schema
The Active Directory schema contains definitions for all the objects that are used to
store information in the directory. There is one schema per forest. However, a copy of
the schema exists on every domain controller in the forest. This way, every domain
controller has quick access to any object definition that it might need, and every domain
controller uses the same definition when it creates a given object. The data store relies
on the schema to provide object definitions, and the data store uses those definitions to
enforce data integrity. The result is that all objects are created uniformly, and it does not
matter which domain controller creates or modifies an object because all domain
controllers use the same object definition.
The following figure illustrates the relationship of the schema to the data store in the
schema architecture.
Schema Architecture
Active Directory Data Store
The Active Directory data store is made up of several components that together provide
directory services to directory clients. These components include the following:
 Four interfaces:
o Lightweight Directory Access Protocol (LDAP)
o Replication (REPL) and domain controller management interface
o Messaging API (MAPI)

o Security Accounts Manager (SAM)
 Three service components:
o Directory System Agent (DSA)
o The database layer
o Extensible Storage Engine (ESE)
 The directory database where the data is actually stored
The following figure illustrates the relationships of these components in the data store
architecture.
Data Store Architecture
Active Directory Structure and Storage Components
You can define some components for structure and storage in Active Directory, while
others are defined by the system and cannot be modified.
 Forests, domains, and OUs are components that constitute the logical structure of
Active Directory. You define them during the installation of Active Directory.
 DNS support for Active Directory includes components that are used to locate domain
controllers and that use DNS naming schemes. Each domain in a forest must adhere to
DNS naming schemes, and domains are organized in a root and subordinate domain
hierarchy.
 The schema is a single component that exists inside the directory. The schema contains
definitions of the objects that are used to store information in the directory. These
object definitions include two primary components: classSchema objects and
attributeSchema objects.
 The data store consists of three layers of components. The first layer provides the
interfaces that clients need to access the directory. The second layer provides the
services that perform the operations that are associated with reading data from and
writing data to the directory database. The third layer is the database itself, which exists
as a single file on the hard disk of each domain controller.
Active Directory Domains and Forests
The logical structure of Active Directory is a hierarchical structure of Active Directory
domains and OUs in a forest. The relationships of the components in the logical
structure control access to stored data, and they control how information is replicated
between the various domain controllers in the forest. The main components of the
Active Directory logical structure are described in the following table.
Domain and Forest Components

Component Description
A forest is the highest level of the logical structure hierarchy. An
Active Directory forest represents a single self-contained directory. A
forest is a security boundary, which means that administrators in a forest

Forest
have complete control over all access to information that is stored inside
the forest and to the domain controllers that are used to implement the
forest.
Domains partition the information that is stored inside the directory into
smaller portions so that the information can be more easily stored on
various domain controllers and so that administrators have a greater
degree of control over replication. Data that is stored in the directory is
replicated throughout the forest from one domain controller to another.
Some data that is relevant to the entire forest is replicated to all domain
Domain
controllers. Other data that is relevant only to a specific domain is
replicated only to domain controllers in that particular domain. A good
domain design makes it possible to implement an efficient replication
topology. This is important because it enables administrators to manage
the flow of data across the network, that is, to control how much data is
replicated and where that replication traffic takes place.
OUs provide a means for administrators to group resources, such as user
accounts or computer accounts, so that the resources can be managed as

OU
one unit. This makes it much easier to apply Group Policy to multiple
computers or to control the access of many users to a single resource.

OUs also make it easier to delegate control over resources to various
administrators.
DNS Support for Active Directory
In Active Directory, DNS is the means by which directory clients locate, or discover,
domain controllers. The primary components of the architecture for DNS support of
Active Directory include the domain controller Locator, Active Directory domain names
in DNS, and Active Directory DNS objects.
The following table describes the Active Directory components that help directory
clients locate nearby domain controllers.
Active Directory DNS Support Components
Active Directory/DNS
Description
Component
Locator, which is implemented in the Net Logon service,
enables a client to locate a domain controller. Locator
Locator contains Internet Protocol (IP)/DNS–compatible and
Windows NT 4.0–compatible locators, which provide
interoperability in a mixed Active Directory environment.
Every Active Directory domain has a DNS domain name (for

Active Directory domain
example, cohovineyard.com), and every domain joined
names in DNS
computer has a DNS name (for example,
Active Directory/DNS
Description
Component
server1.cohovineyard.com). Architecturally, domains and
computers are represented both as objects in Active Directory
and as nodes in DNS.
When DNS data is stored in Active Directory, each DNS zone
is an Active Directory container object (class dnsZone). The
Active Directory DNS dnsZone object contains a DNS node object (class dnsNode)
objects for every unique name in that zone. The dnsNode object has
a dnsRecord multivalued attribute that contains a value for
every resource record that is associated with that DNS name.
For more information about DNS support for Active Directory, see “DNS Support for
Active Directory Technical Reference.”
Active Directory Schema
Everything that is stored in Active Directory is stored in an object. A definition for every
type of object is stored in the schema. The definitions themselves consist of two types of
objects: class objects and attribute objects. Classes define groups of attributes that are
used to describe common objects. New object definitions are created by combining
various class objects and attribute objects to make new combinations that contain the
necessary attributes to meet the storage requirements of the new object type. The two
main types of object definitions that are stored in the Active Directory schema are
described in the following table.
Schema Components
classSchema objects are object definitions that are stored in the
schema, and they are used to define classes. classSchema objects
define groups of attributes that have something in common. For
example, an object that is used to store a user account needs to
store the user’s logon name, first name, last name, and password. It
classSchema
is possible to create a user class that has a logon name attribute, a
objects
first name attribute, a last name attribute, and a password attribute.
Anytime a new user account is created, the directory uses the user
class as the definition, and every user account object that is created
uses those attributes. classSchema objects can be nested to create
more complex objects.
attributeSchema objects define the individual attributes of a single
object. For example, a user account object has a number of attributes
that are used to store and define various pieces of data that are
related to a user account, such as a logon name attribute and a

attributeSchema
password attribute. Each of these attributes also has its own
objects
attributes that specify the type of data that it stores, the syntax of
the data that it stores, and whether or not the attribute is required or
optional. The directory service uses attributeSchema objects to store
data and verify that the stored data is valid.
Active Directory Data Store

The Active Directory data store is implemented on every domain controller in the forest.
The data store consists of components that store and retrieve data inside the directory.
The components of the Active Directory data store are described in the following table.
Data Store Components
Interfaces (LDAP,
The data store interfaces provide a way for directory clients and other
REPL, MAPI,
directory servers to communicate with the data store.
SAM)
The DSA (which runs as Ntdsa.dll on each domain controller) provides
the interfaces through which directory clients and other directory
DSA (Ntdsa.dll) servers gain access to the directory database. In addition, the DSA
enforces directory semantics, maintains the schema, guarantees
object identity, and enforces data types on attributes.
The database layer is an application programming interface (API) that
resides in Ntdsa.dll and provides an interface between applications
and the directory database to protect the database from direct
interaction with applications. Calls from applications are never made

Database layer
directly to the database; they go through the database layer. In
addition, because the directory database is flat — with no hierarchical
namespace — the database layer provides the database with an
abstraction of an object hierarchy.

The ESE (which runs as Esent.dll) communicates directly with
ESE (Esent.dll) individual records in the directory database on the basis of an object’s
relative distinguished name attribute.
The data store stores directory information in a single database file. In
Database files addition, the data store also uses log files, to which it temporarily
writes uncommitted transactions.
Domain Controller Roles

A domain controller is a server that is running a version of the Windows Server®
operating system and has Active Directory® Domain Services installed.
When you install Windows Server on a computer, you can choose to configure a specific
server role for that computer. When you want to create a new forest, a new domain, or
an additional domain controller in an existing domain, you configure the server with the
role of domain controller by installing AD DS.
By default, a domain controller stores one domain directory partition consisting of

information about the domain in which it is located, plus the schema and configuration
directory partitions for the entire forest. A domain controller that runs Windows
Server 2008 R2, Windows Server 2008, or Windows Server 2003 can also store one or
more application directory partitions. There are also specialized domain controller roles
that perform specific functions in an AD DS environment. These specialized roles include
global catalog servers and operations masters.
Global Catalog Servers

Every domain controller stores the objects for the domain in which it is installed.
However, a domain controller designated as a global catalog server stores the objects
from all domains in the forest. For each object that is not in the domain for which the
global catalog server is authoritative as a domain controller, a limited set of attributes is
stored in a partial replica of the domain. Therefore, a global catalog server stores its own
full, writable domain replica (all objects and all attributes) plus a partial, read-only
replica of every other domain in the forest. The global catalog is built and updated
automatically by the AD DS replication system. The object attributes that are replicated
to global catalog servers are the attributes that are most likely to be used to search for
the object in AD DS. 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.
The global catalog makes it possible for clients to search AD DS without having to be
referred from server to server until a domain controller that has the domain directory
partition storing the requested object is found. By default, AD DS searches are directed
to global catalog servers.
The first domain controller in a forest is automatically created as a global catalog server.
Thereafter, you can designate other domain controllers to be global catalog servers if
they are needed.
Operations Masters
Domain controllers that hold operations master roles are designated to perform specific
tasks to ensure consistency and to eliminate the potential for conflicting entries in the
Active Directory database. AD DS defines five operations master roles: the schema
master, domain naming master, relative identifier (RID) master, primary domain
controller (PDC) emulator, and infrastructure master.
The following operations masters perform operations that must occur on only one
domain controller in the forest:
 Schema master
 Domain naming master
domain controller in a domain:
 Primary Domain Controller (PDC) emulator
 Infrastructure master
 Relative ID (RID) master
Understanding Domain and Forest Functionality
Domain and forest functionality
Domain and forest functionality, which is available in Windows Server® 2008
Active Directory Domain Services (AD DS), provides a way to enable domain-wide
features or forest-wide Active Directory features in your network environment. Different
levels of domain functionality and forest functionality are available, depending on your
network environment.
If all the domain controllers in your domain or forest are running Windows Server 2008
or Microsoft® Windows Server® 2003 and the domain and forest functional level is set
to Windows Server 2008 or Windows Server 2003, all domain-wide features and forest-
wide features are available. When Microsoft Windows® 2000 domain controllers are
included in your domain or forest with domain controllers running Windows Server 2008
or Windows Server 2003, Active Directory features are limited.
Domain functionality
Domain functionality enables features that affect the entire domain and that domain
only. In Windows Server 2008 AD DS, three domain functional levels are available:
Windows 2000 native (the default), Windows Server 2003, and Windows Server 2008.
The following table lists the domain functional levels and their corresponding supported
domain controllers:
Domain functional level Domain controllers supported
Windows 2000
Windows 2000 native Windows Server 2003
Windows Server 2008
Windows Server 2003

Windows Server 2003
Windows Server 2008
Windows Server 2008 Windows Server 2008
When you raise the domain functional level, domain controllers running earlier
operating systems cannot be introduced into the domain. For example, if you raise the
domain functional level to Windows Server 2003, you cannot add domain controllers
running Windows 2000 Server to the domain. If you raise the domain functional level to
Windows Server 2008, you cannot add domain controllers running Windows Server 2003
to the domain.
The following table describes the domain-wide features that are enabled for the
Windows Server 2008 AD DS domain functional levels.

Domain
Enabled features
functional level
All default Active Directory features and the following features:
 Universal groups are enabled for both distribution groups and security
groups.
Windows 2000
 Group nesting.
native
 Group conversion is enabled, which makes conversion possible
between security groups and distribution groups.
 Security identifier (SID) history.
All default Active Directory features, all features from the
Windows 2000 native domain functional level, plus the following
features:
 The availability of the domain management tool, Netdom.exe, to
prepare for domain controller rename.

Windows
Server 2003  Update of the logon time stamp. The lastLogonTimestamp attribute
is updated with the last logon time of the user or computer. This
attribute is replicated within the domain.
 The ability to set the userPassword attribute as the effective
password on the inetOrgPerson object and user objects.

Domain
Enabled features
functional level
 The ability to redirect Users and Computers containers. By default, two
well-known containers are provided for housing computer and
user/group accounts: cn=Computers,<domain root> and
cn=Users,<domain root>. This feature makes it possible to define a
new well-known location for these accounts.
 Authorization Manager can store its authorization policies in AD DS.
 Constrained delegation is included, which makes it possible for
applications to take advantage of the secure delegation of user
credentials by means of the Kerberos authentication protocol. You can
configure delegation to be allowed only to specific destination
services.
 Selective authentication is supported, which makes it possible to
specify the users and groups from a trusted forest who are allowed to
authenticate to resource servers in a trusting forest.
All default Active Directory features, all features from the
Windows Server 2003 domain functional level, plus the following
Windows features:
Server 2008
 Distributed File System Replication support for SYSVOL, which
provides more robust and detailed replication of SYSVOL contents.

Domain
Enabled features
functional level
 Advanced Encryption Services (AES 128 and 256) support for the
Kerberos authentication protocol.
 Last Interactive Logon Information, which displays the time of the last
successful interactive logon for a user, from what workstation, and the
number of failed logon attempts since the last logon.
 Fine-grained password policies, which make it possible for password
policies and account lockout policies to be specified for users and
global security groups in a domain.
Forest functionality
Forest functionality enables features across all the domains in your forest. Three forest
functional levels are available: Windows 2000 (default), Windows Server 2003 interim,
and Windows Server 2003. By default, forests operate at the Windows 2000 functional
level. You can raise the forest functional level to Windows Server 2003 or Windows
Server 2008.
The following table lists the forest functional levels and their corresponding supported
domain controllers.
Forest functional level Domain controllers supported
Windows 2000
Windows 2000 (default)
Windows Server 2003
Windows Server 2008
Windows Server 2003

Windows Server 2003
Windows Server 2008
Windows Server 2008 Windows Server 2008
When you raise the forest functional level, domain controllers running earlier operating
systems cannot be introduced into the forest. For example, if you raise the forest
functional level to Windows Server 2003, domain controllers running
Windows 2000 Server cannot be added to the forest.
The following table describes the forest-wide features that are enabled for the
Windows 2000, Windows Server 2003, and Windows Server 2008 forest functional levels.
Forest
functional Enabled features
level
Windows 2000 All default Active Directory features.
All default Active Directory features, plus the following features:
Windows
 Forest trust
Server 2003
 Domain rename
Forest
level
 Linked-value replication (Changes in group membership store and
replicate values for individual members instead of replicating the
entire membership as a single unit.) This results in lower network
bandwidth and processor usage during replication and eliminates the
possibility of lost updates when different members are added or
removed concurrently at different domain controllers.
 The ability to deploy a read-only domain controller (RODC) that runs
Windows Server 2008.
 Improved Knowledge Consistency Checker (KCC) algorithms and
scalability. The intersite topology generator (ISTG) uses improved
algorithms that scale to support forests with a greater number of sites
than can be supported at the Windows 2000 forest functional level.
 The ability to create instances of the dynamic auxiliary class called
dynamicObject in a domain directory partition.
 The ability to convert an inetOrgPerson object instance into a User
object instance, and the reverse.
 The ability to create instances of the new group types, called
application basic groups and Lightweight Directory Access Protocol
(LDAP) query groups, to support role-based authorization.

Forest
level
 Deactivation and redefinition of attributes and classes in the schema.
This functional level provides all of the features that are available at
the Windows Server 2003 forest functional level, but no additional

Windows
features. All domains that are subsequently added to the forest,
Server 2008
however, will operate at the Windows Server 2008 domain functional
level by default.
Domain Controller Roles

When you install Windows Server on a computer, you can choose to configure a specific
server role for that computer. When you want to create a new forest, a new domain, or
an additional domain controller in an existing domain, you configure the server with the
role of domain controller by installing AD DS.
By default, a domain controller stores one domain directory partition consisting of

information about the domain in which it is located, plus the schema and configuration
directory partitions for the entire forest. A domain controller that runs Windows
Server 2008 R2, Windows Server 2008, or Windows Server 2003 can also store one or
more application directory partitions. There are also specialized domain controller roles
that perform specific functions in an AD DS environment. These specialized roles include
global catalog servers and operations masters.
Global Catalog Servers
Every domain controller stores the objects for the domain in which it is installed.
However, a domain controller designated as a global catalog server stores the objects
from all domains in the forest. For each object that is not in the domain for which the
global catalog server is authoritative as a domain controller, a limited set of attributes is
stored in a partial replica of the domain. Therefore, a global catalog server stores its own
full, writable domain replica (all objects and all attributes) plus a partial, read-only
replica of every other domain in the forest. The global catalog is built and updated
automatically by the AD DS replication system. The object attributes that are replicated
to global catalog servers are the attributes that are most likely to be used to search for
the object in AD DS. 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.
The global catalog makes it possible for clients to search AD DS without having to be
referred from server to server until a domain controller that has the domain directory
partition storing the requested object is found. By default, AD DS searches are directed
to global catalog servers.
The first domain controller in a forest is automatically created as a global catalog server.
Thereafter, you can designate other domain controllers to be global catalog servers if
they are needed.
Operations Masters
Domain controllers that hold operations master roles are designated to perform specific
tasks to ensure consistency and to eliminate the potential for conflicting entries in the
Active Directory database. AD DS defines five operations master roles: the schema
master, domain naming master, relative identifier (RID) master, primary domain
controller (PDC) emulator, and infrastructure master.
domain controller in the forest:
 Schema master
 Domain naming master
domain controller in a domain:
 Primary Domain Controller (PDC) emulator
 Infrastructure master
 Relative ID (RID) master
Active Directory naming

Active Directory domain names are usually the full Domain Name System (DNS) name of
the domain. However, for backward compatibility, each domain also has a pre-
Windows 2000 name for use by computers running pre-Windows 2000 operating
systems. The pre-Windows 2000 domain name can be used to log on to a Windows
Server 2003 domain from computers running pre-Windows 2000 operating systems
using the DomainName\UserName format. This same format can also be used to log on
to a Windows Server 2003 domain from computers running Windows 2000,
Windows XP, or servers running Windows Server 2003. Users can also log on to
computers running Windows 2000, Windows XP, or servers running Windows
Server 2003 using the user principal name (UPN) associated with their user account.
User accounts
In Active Directory, each user account has a user logon name, a pre-Windows 2000 user
logon name (security account manager account name), and a UPN suffix. The
administrator enters the user logon name and selects the UPN suffix when creating the
user account. Active Directory suggests a pre-Windows 2000 user logon name using the
first 20 bytes of the user logon name. Administrators can change the pre-Windows 2000
logon name at any time.
In Active Directory, each user account has a UPN based on IETF RFC 822, Standard for
the Format of ARPA Internet Text Messages. The UPN is composed of the user logon
name and the UPN suffix joined by the @ sign.
Note
 Do not add the @ sign to the user logon name or to the UPN suffix. Active Directory
automatically adds it when it creates the UPN. A UPN that contains more than one @ sign
is invalid.
Important
 Windows NT 4.0 and earlier domains allowed the use of a period (.) at the end of a user
logon name as long as the user logon name did not consist solely of period characters.
Windows Server 2003 domains do not allow the use of a period or multiple periods at the
end of a user logon name.
The second part of the UPN, the UPN suffix, identifies the domain in which the user
account is located. This UPN suffix can be the DNS domain name, the DNS name of any
domain in the forest, or it can be an alternative name created by an administrator and
used just for log on purposes. This alternative UPN suffix does not need to be a valid
DNS name.
In Active Directory, the default UPN suffix is the DNS name of the domain in which user
account created. In most cases, this is the domain name registered as the enterprise
domain on the Internet. Using alternative domain names as the UPN suffix can provide
additional logon security and simplify the names used to log on to another domain in
the forest.
For example, if your organization uses a deep domain tree, organized by department
and region, domain names can get quite long. The default user UPN for a user in that
domain might be sales.westcoast.microsoft.com. The logon name for a user in that
domain would be *user@sales.westcoast.microsoft.com*. Creating a UPN suffix of
"microsoft" would allow that same user to log on using the much simpler logon name of
*user@microsoft*. For more information about user accounts, see User and computer
accounts and Object names.
You can add or remove UPN suffixes using Active Directory Domains and Trusts. For
more information, see Add user principal name suffixes.
Computer accounts
Each computer account created in Active Directory has a relative distinguished name, a
pre-Windows 2000 computer name (security account manager account name), a primary
DNS suffix, a DNS host name, and a service principal name (SPN). The administrator
enters the computer name when creating the computer account. This computer name is
used as the Lightweight Directory Access Protocol (LDAP) relative distinguished name.
Active Directory suggests the pre-Windows 2000 name using the first 15 bytes of the
relative distinguished name. The administrator can change the pre-Windows 2000 name
at any time.
The DNS name for a host is called a full computer name and is a DNS fully qualified
domain name (FQDN). The full computer name is a concatenation of the computer
name (the first 15 bytes of the SAM account name of the computer account without the
"$" character) and the primary DNS suffix (the DNS domain name of the domain in
which the computer account exists). It is listed on the Computer Name tab in System
Properties in Control Panel.
By default, the primary DNS suffix portion of the FQDN for a computer must be the
same as the name of the Active Directory domain where the computer is located. To
allow different primary DNS suffixes, a domain administrator may create a restricted list
of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain
object container. This attribute is created and managed by the domain administrator
using Active Directory Service Interfaces (ADSI) or the Lightweight Directory Access
Protocol (LDAP).
For more information, see Object names and User and computer accounts.
The service principal name (SPN) is a multivalue attribute. It is usually built from the DNS
name of the host. The SPN is used in the process of mutual authentication between the
client and the server hosting a particular service. The client finds a computer account
based on the SPN of the service to which it is trying to connect. The SPN can be
modified by members of the Domain Admins group.
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 .
For information about creating, modifying, and querying quotas, default quotas, and
tombstone quota factors, see Dsadd, Dsmod, and Dsquery.
User and computer accounts

 07/29/2013
 9 minutes to read
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with
SP1, Windows Server 2003 with SP2
User and computer accounts

Active Directory user accounts and computer accounts represent a physical entity such
as a computer or person. User accounts can also be used as dedicated service accounts
for some applications.
User accounts and computer accounts (as well as groups) are also referred to as security
principals. Security principals are directory objects that are automatically assigned
security IDs (SIDs), which can be used to access domain resources. A user or computer
account is used to:
 Authenticate the identity of a user or computer.
A user account enables a user to log on to computers and domains with an

identity that can be authenticated by the domain. For information about
authentication, see Access control in Active Directory. Each user who logs on to the
network should have his or her own unique user account and password. To
maximize security, you should avoid multiple users sharing one account.
 Authorize or deny access to domain resources.
Once the user has been authenticated, the user is authorized or denied access to
domain resources based on the explicit permissions assigned to that user on the
resource. For more information, see Security information for Active Directory.
 Administer other security principals.
Active Directory creates a foreign security principal object in the local domain to
represent each security principal from a trusted external domain. For more
information about foreign security principals, see When to create an external trust.
 Audit actions performed using the user or computer account.
Auditing can help you monitor account security. For more information about
auditing, see Auditing overview.
User accounts
The Users container located in Active Directory Users and Computers displays the three
built-in user accounts: Administrator, Guest, and HelpAssistant. These built-in user
accounts are created automatically when you create the domain.
Each built-in account has a different combination of rights and permissions. The
Administrator account has the most extensive rights and permissions over the domain,
while the Guest account has limited rights and permissions. The table below describes
each default user account on domain controllers running Windows Server 2003.
Default user account Description
Administrator account The Administrator account has full control of the domain and can assign user rights and acces
permissions to domain users as necessary. This account must be used only for tasks that requi
administrative credentials. It is recommended that you set up this account with a strong passw
more information, see Strong passwords. For additional security considerations for accounts w
administrative credentials, see Active Directory Best practices.
The Administrator account is a default member of the Administrators, Domain Admins, Enter
Admins, Group Policy Creator Owners, and Schema Admins groups in Active Directory. The
Administrator account can never be deleted or removed from the Administrators group, but it
renamed or disabled. Because the Administrator account is known to exist on many versions o
Windows, renaming or disabling this account will make it more difficult for malicious users t
gain access to it. For more information about how to rename or disable a user account, see Re
local user account or Disable or enable a user account.
The Administrator account is the first account created when you set up a new domain using th
Directory Installation Wizard.
 Important When the Administrator account is disabled, it can still be used to gain acc
domain controller using Safe Mode.
Guest account The Guest account is used by people who do not have an actual account in the domain. A use
account is disabled (but not deleted) can also use the Guest account. The Guest account does
a password.
You can set rights and permissions for the Guest account just like any user account. By defau
Guest account is a member of the built-in Guests group and the Domain Guests global group,
allows a user to log on to a domain. The Guest account is disabled by default, and it is recomm
that it stay disabled.
Default user account Description
HelpAssistant account The primary account used to establish a Remote Assistance session. This account is created
(installed with a Remote automatically when you request a Remote Assistance session and has limited access to the co
Assistance session) The HelpAssistant account is managed by the Remote Desktop Help Session Manager service
be automatically deleted if no Remote Assistance requests are pending. For more information
Remote Assistance, see Administering Remote Assistance.
Securing user accounts

If built-in account rights and permissions are not modified or disabled by a network
administrator, they could be used by a malicious user (or service) to illegally log on to a
domain using the Administrator or Guest identity. A good security practice for
protecting these accounts is to rename or disable them. Because it retains its security ID
(SID), a renamed user account retains all its other properties, such as its description,
password, group memberships, user profile, account information, and any assigned
permissions and user rights.
To obtain the security of user authentication and authorization, create an individual user
account for each user who will participate on your network by using Active Directory
Users and Computers. Each user account (including the Administrator and Guest
account) can then be added to a group to control the rights and permissions assigned
to the account. Using accounts and groups that are appropriate for your network
ensures that users logging on to a network can be identified and can access only the
permitted resources.
You can help defend your domain from attackers by requiring strong passwords and
implementing an account lockout policy. Strong passwords reduce the risk of intelligent
guessing and dictionary attacks on passwords. For more information, see Strong
passwords and Password Best practices for passwords.
An account lockout policy decreases the possibility of an attacker compromising your

domain through repeated logon attempts. This is because an account lockout policy
determines how many failed logon attempts a user account can have before it is
disabled. For more information, see Apply or modify account lockout policy.
For more information about securing user accounts, see Securing Active Directory.
Account options
Each Active Directory user account has a number of account options that determine how
someone logging on with that particular user account is authenticated on the network.
You can use the following options to configure password settings and security-specific
information for user accounts:
Account option Description
User must change Forces a user to change their password the next time the user logs on to the network. Use this op
password at next logon you want to ensure that the user will be the only person to know their password.
User cannot change Prevents a user from changing their password. Use this option when you want to maintain contro
password user account, such as for a guest or temporary account.
Password never expires Prevents a user password from expiring. It is recommended that Service accounts should have th
enabled and should use strong passwords. For more information about strong passwords, see Str
passwords.
Store passwords using Allows a user to log on to a Windows network from Apple computers. If a user is not logging on
reversible encryption Apple computer, this option should not be used. For more information, see Store passwords usin
reversible encryption.
Account is disabled Prevents a user from logging on with the selected account. Many administrators use disabled acc
templates for common user accounts. For more information, see Disable or enable a user accoun
Smart card is required Requires that a user possess a smart card to log on to the network interactively. The user must al
for interactive logon smart card reader attached to their computer and a valid personal identification number (PIN) fo
card. When this option is selected, the password for the user account is automatically set to a ran
complex value. For more information about smart cards, see Logging on to a computer with a sm
and Authentication process.
Account is trusted for Allows a service running under this account to perform operations on behalf of other user accou
delegation network. A service running under a user account (otherwise known as a service account) that is t
delegation can impersonate a client to gain access to resources on the computer where the servic
running or on other computers. In a forest set to the Windows Server 2003 functional level, this
found on the Delegation tab, and is only available for accounts that have been assigned service p
names (SPNs), as set using the setspn command from the Windows Support Tools. This is a sec
sensitive capability and should be cautiously assigned. For more information, see Allow a user t
trusted for delegation and Delegating authentication.
Account option Description
This option is only available on domain controllers running Windows Server 2003 where the do
functionality is set to Windows 2000 mixed or Windows 2000 native. On domain controllers run
Windows Server 2003 where the domain functional level is set to Windows Server 2003, the De
tab is used to configure delegation settings. The Delegation tab only appears for accounts which
assigned SPN. For more information about domain functionality, see Domain and forest function
more information about configuring delegation in a Windows Server 2003 domain, see Allow a
trusted for delegation.
Account is sensitive Allows control over a user account, such as for a guest or temporary account. This option can be
and cannot be this account cannot be assigned for delegation by another account.
delegated
Use DES encryption Provides support for the Data Encryption Standard (DES). DES supports multiple levels of encry
types for this account including MPPE Standard (40-bit), MPPE Standard (56-bit), MPPE Strong (128-bit), IPSec DES
IPSec 56-bit DES, and IPSec Triple DES (3DES). For more information about DES encryption,
encryption.
Do not require Provides support for alternate implementations of the Kerberos protocol. Domain controllers run
Kerberos Windows 2000 or Windows Server 2003 can use other mechanisms to synchronize time. Becaus
preauthentication preauthentication provides additional security, use caution when enabling this option. For more
information about Kerberos, see Kerberos V5 authentication.
InetOrgPerson accounts
Active Directory provides support for the InetOrgPerson object class and its associated
attributes defined in RFC 2798. The InetOrgPerson object class is used in several non-
Microsoft LDAP and X.500 directory services to represent people within an organization.
Support for InetOrgPerson makes migrations from other LDAP directories to Active
Directory more efficient. The InetOrgPerson object is derived from the user class and
can be used as a security principal just like the user class. For information about creating
an inetOrgPerson user account, see Create a new user account.
When the domain functional level has been set to Windows Server 2003, you can set the
userPassword attribute on InetOrgPerson and user objects as being the effective
password just like you can with the unicodePwd attribute.
Computer accounts
Every computer running Windows NT, Windows 2000, Windows XP, or a server running
Windows Server 2003 that joins a domain has a computer account. Similar to user
accounts, computer accounts provide a means for authenticating and auditing computer
access to the network and to domain resources. Each computer account must be
unique.
Note Computers running Windows 95 and Windows 98 do not have advanced security
features and are not assigned computer accounts.
User and computer accounts can be added, disabled, reset, and deleted using Active
Directory Users and Computers. A computer account can also be created when you join
a computer to a domain. For more information about user and computer accounts, see
Active Directory naming and Object names.
When the domain functional level has been set to Windows Server 2003, a new
lastLogonTimestamp attribute is used to track the last logon time of a user or computer
account. This attribute is replicated within the domain and can provide you with
important information regarding the history of a user or computer.
Object names
 06/06/2011
Object names
Every object in Active Directory is an instance of a class defined in the schema. Each
class has attributes that ensure:
 Unique identification of each object (instance of a class) in a directory data store

 Backward compatibility with security IDs used in Windows NT 4.0 and earlier
 Compatibility with LDAP standards for directory object names
For more information about schema, classes, and attributes, see Schema.
Each object in Active Directory can be referenced by several different names. Active
Directory creates a relative distinguished name and a canonical name for each object
based upon information that was provided when the object was created or modified.
Each object can also be referenced by its distinguished name, which is derived from the
relative distinguished name of the object and all of its parent container objects.
 The LDAP relative distinguished name uniquely identifies the object within its
parent container. For example, the LDAP relative distinguished name of a
computer named my computer is CN=mycomputer. Relative distinguished names
must be unique in that users cannot have the same name within an organizational
unit.
 The LDAP distinguished name is globally unique. For example, the distinguished
name of a computer named mycomputer in the MyOrganizationalUnit
organizational unit in the microsoft.com domain is CN=mycomputer,
OU=MyOrganizationalUnit, DC=microsoft, DC=com.
 The canonical name is constructed the same way as the distinguished name, but it
is represented using a different notation. The canonical name of the computer in
the previous example would be
Microsoft.com/MyOrganizationalUnit/mycomputer.
Security principal objects are Active Directory objects that are assigned security IDs
(SIDs) and can be used to log on to the network and can be assigned access to domain
resources. An administrator needs to provide names for security principal objects (user
accounts, computer accounts, and groups) that are unique within a domain.
Consider what occurs when a new user account is added to your directory. You provide
a name the user must use to log on to the network, the name of the domain that
contains the user account, and other descriptive data, such as first name, last name,
telephone number and so on (called attributes). All this information is recorded in the
directory.
The names of security principal objects can contain all Unicode characters except the
special LDAP characters defined in RFC 2253. This list of special characters includes: a
leading space; a trailing space; and any of the following characters: # , + " \ < > ;
Security principal names must conform to the following guidelines:
Type of
account
name Maximum size Special limitations
User Computers running Windows Server 2003 and A user account cannot consist solely of periods (.) or sp
account Windows 2000 can use a user principal name end in a period. Any leading periods or spaces are crop
(UPN) for a user account. Computers running of the @ symbol is not supported with the logon forma
Windows NT 4.0 and earlier are limited to 20 Windows NT 4.0 and earlier, which is DomainName\U
characters or 20 bytes depending upon the Windows 2000 logon names are unique to the domain a
character set; individual characters may require Windows Server 2003 logon names are unique within t
more than one byte.
Computer NetBIOS = 15 characters, or 15 bytes A computer account cannot consist solely of numbers,
account depending upon the character set; individual or spaces. Any leading periods or spaces are cropped.
characters may require more than one byte.
DNS = 63 characters or 63 bytes depending

upon the character set and 255 characters for a
fully qualified domain name (FQDN)
individual characters may require more than
one byte.
Group 63 characters, or 63 bytes depending upon the A group account cannot consist solely of numbers, peri
account character set; individual characters may require spaces. Any leading periods or spaces are cropped.
more than one byte.
Note
 If the administrator changes the default security settings, then it is possible to use
computer names containing more than 15 characters. For more information, see Active
Directory naming.
From the information provided by the person who creates the security principal object,
Active Directory generates a security ID (SID), and a globally unique ID used to identify
the security principal. Active Directory also creates an LDAP relative distinguished name,
based on the security principal name. An LDAP distinguished name and a canonical
name are derived from the relative distinguished name and the names of the domain
and container contexts in which the security principal object is created.
If your organization has several domains, it is possible to use the same user name or
computer name in different domains. The SID, globally unique ID, LDAP distinguished
name, and canonical name generated by Active Directory will uniquely identify each
user, computer, or group in the forest. If the security principal object is renamed or
moved to a different domain, the SID, LDAP relative distinguished name, LDAP
distinguished name, and canonical name will change, but the globally unique ID
generated by Active Directory will not change.
Security principal objects, such as user accounts, may be renamed, moved, or contained
within a nested domain hierarchy. To reduce the effect of renaming, moving, or
assigning user account names within a nested domain hierarchy, Active Directory
provides a method for simplifying user logon names. For information about user logon
names, see Active Directory naming and Add user principal name suffixes, and User and
computer accounts.
Organizational units
 06/06/2011
Organizational units
A particularly useful type of directory object contained within domains is the
organizational unit. Organizational units are Active Directory containers into which you
can place users, groups, computers, and other organizational units. An organizational
unit cannot contain objects from other domains.
An organizational unit is the smallest scope or unit to which you can assign Group Policy
settings or delegate administrative authority. Using organizational units, you can create
containers within a domain that represent the hierarchical, logical structures within your
organization. You can then manage the configuration and use of accounts and
resources based on your organizational model. For more information about Group
Policy settings, see Group Policy (pre-GPMC).
As shown in the figure, organizational units can contain other organizational units. A
hierarchy of containers can be extended as necessary to model your organization's
hierarchy within a domain. Using organizational units will help you minimize the number
of domains required for your network.
You can use organizational units to create an administrative model that can be scaled to
any size. A user can have administrative authority for all organizational units in a domain
or for a single organizational unit. An administrator of an organizational unit does not
need to have administrative authority for any other organizational units in the domain.
For more information about delegating administrative authority, see Delegating
administration.
Active Directory server roles

 06/06/2011
Active Directory server roles

Computers that function as servers within a domain can have one of two roles: member
server or domain controller. A server that is not in a domain is a stand-alone server.
Member servers
A member server is a computer that:
 Runs an operating system in the Windows 2000 Server family or the Windows
Server 2003 family.
 Belongs to a domain.
 Is not a domain controller.
A member server does not process account logons, participate in Active Directory
replication, or store domain security policy information.
Member servers typically function as the following types of servers: file servers,
application servers, database servers, Web servers, certificate servers, firewalls, and
remote access servers. For more information about server roles, see Server roles.
The following security-related features are common to all member servers:
 Member servers adhere to Group Policy settings that are defined for the site,
domain, or organizational unit.
 Access control for resources that are available on a member server.
 Member server users have assigned user rights.
 Member servers contain a local security account database, the Security Accounts
Manager (SAM).
Domain controllers
A domain controller is a computer that:
 Runs an operating system in the Windows 2000 Server family or the Windows
Server 2003 family.
 Uses Active Directory to store a read-write copy of the domain database,

participate in multimaster replication, and authenticate users.
Domain controllers store directory data and manage communication between users and
domains, including user logon processes, authentication, and directory searches.
Domain controllers synchronize directory data using multimaster replication, ensuring
consistency of information over time. For more information about multimaster
replication, see Replication overview.
Active Directory supports multimaster replication of directory data between all domain
controllers in a domain; however, multimaster replication is not appropriate for some
directory data replication. In this case, a domain controller, called the operations master,
will process data. In an Active Directory forest, there are at least five different operations
master roles that are assigned to one or more domain controllers. For more information
about operations masters, see Operations master roles.
As the needs of your computing environment change, you might want to change the
role of a server. Using the Active Directory Installation Wizard, you can install Active
Directory on a member server to make it a domain controller, or you can remove Active
Directory from a domain controller to make it a member server. For more information
about domain controllers, see Domain controllers.
Note
 You cannot install Active Directory on a computer running Windows Server 2003, Web
Edition, but you can join the computer to an Active Directory domain as a member server.
For more information about Windows Server 2003, Web Edition, see Overview of Windows
Server 2003, Web Edition.
Active Directory clients

 06/06/2011
Active Directory clients

With the Active Directory client, many of the Active Directory features available on
Windows 2000 Professional or Windows XP Professional are available to computers
running Windows 95, Windows 98, and Windows NT 4.0.
 Site awareness
You can log on to the domain controller that is closest to the client in the network.
For more information, see Locating a domain controller.
 Active Directory Service Interfaces (ADSI)
You can use scripting to Active Directory. ADSI also provides a common
programming API to Active Directory programmers.
 Distributed File System (DFS)
You can access DFS shared resources on servers running Windows 2000 and
Windows Server 2003.
 NTLM version 2 authentication
You can use the improved authentication features in NTLM version 2.
For more information about enabling NTML version 2, see article Q239869, "How
to Enable NTLM 2 Authentication," in the Microsoft Knowledge Base.
 Active Directory Windows Address Book (WAB) property pages
You can change properties, such as phone number and address, on user object
pages.
 Active Directory search capability
From the Start button, you can locate printers and people in a Windows 2000
Server or Windows Server 2003 domain.
For information about publishing printers in Active Directory, see article Q234619,
"Publishing a Printer in Windows 2000 Active Directory," in the Microsoft
Knowledge Base.
Windows 2000 Professional and Windows XP Professional provide functionality that the
Active Directory client on Windows 95, Windows 98, and Windows NT 4.0 does not,
including Kerberos V5 support; Group Policy or IntelliMirror support; and service
principal name (SPN), or mutual authentication. You can take advantage of these
additional features by upgrading to Windows 2000 Professional or Windows XP
Professional.
To install the Active Directory client, see the Active Directory client page at the Microsoft
Web site.
Domain controllers
 06/06/2011
Domain controllers
When you create the first domain controller in your organization, you are also creating
the first domain, the first forest, the first site, and installing Active Directory. Domain
controllers running Windows Server 2003 store directory data and manage user and
domain interactions, including user logon processes, authentication, and directory
searches. Domain controllers are created by using the Active Directory Installation
Wizard. For more information, see Using the Active Directory Installation Wizard.
Note
 You cannot install Active Directory on a computer running Windows Server 2003, Web
Edition, but you can join the computer to an Active Directory domain as a member server.
For more information about Windows Server 2003, Web Edition, see Overview of Windows
Server 2003, Web Edition.
When using domain controllers in your organization, you will want to think about how
many domain controllers you’ll need, the physical security of those domain controllers, a
plan for backing up the domain data, and upgrading domain controllers.
Determining the number of domain controllers

you need
A small organization using a single local area network (LAN) might need only one
domain with two domain controllers for high availability and fault tolerance. A larger
organization with many network locations will need one or more domain controllers in
each site to provide high availability and fault tolerance.
If your network is divided into sites, it is often good practice to put at least one domain
controller in each site to enhance network performance. When users log on to the
network, a domain controller must be contacted as part of the logon process. If clients
must connect to a domain controller located in a different site, the logon process can
take a long time. For more information, see Replication between sites.
By creating a domain controller in each site, user logons are processed more efficiently
within the site. For information about how to create additional domain controllers, see
Create an additional domain controller.
To optimize network traffic, you can also configure domain controllers to receive
directory replication updates only during off-peak hours. For information about how to
schedule site replication, see Configure site link replication availability.
The best network performance is available when the domain controller at a site is also a
global catalog. This way, the server can fulfill queries about objects in the entire forest.
However, enabling many domain controllers as global catalogs can increase the
replication traffic on your network. For more information about the global catalog, see
The role of the global catalog. For more information about adding global catalogs to
sites, see Global catalogs and sites.
In domains with more than one domain controller, do not enable the domain controller
holding the infrastructure master role as a global catalog. For more information, see
Operations master roles.
Physical security
Physical access to a domain controller can provide a malicious user unauthorized access
to encrypted passwords. For this reason, it is recommended that all domain controllers
in your organization be locked in a secured room with limited public access. You can use
additional security measures such as Syskey for extra protection on domain controllers.
For more information about Syskey, see The system key utility.
Backing up domain controllers

You can back up domain directory partition data and data from other directory
partitions by using Backup, which is included with the Windows Server 2003 family, from
any domain controller in a domain. By using the backup tool on a domain controller,
you can:
 Back up Active Directory while the domain controller is online.
 Back up Active Directory using batch file commands.

 Back up Active Directory to removable media, an available network drive, or a file.
 Back up other system and data files.
When you use the backup tool on a domain controller it will automatically back up all of
the system components and all of the distributed services upon which Active Directory is
dependent. This dependent data, which includes Active Directory, is known collectively
as the System State data.
On a domain controller running Windows Server 2003, the System State data consists of
the system startup files; the system registry; the class registration database of COM+ (an
extension to the Component Object Model); the SYSVOL directory; Certificate Services
database (if installed); Domain Name System (if installed); Cluster service (if installed);
and Active Directory. It is recommended that you regularly back up System State data.
For general information about the System State, see System State data. For more
information about how to back up the System State, see Back up System State data. For
more information about how to restore a System State backup, see Restore System
State data.
You can install Active Directory on a server running Windows Server 2003 by using a
restored backup taken from a domain controller running Windows Server 2003. For
more information, see Creating an additional domain controller.
Upgrading domain controllers

On domain controllers running Windows NT 4.0, you will first need to upgrade the
primary domain controller (PDC) to successfully upgrade the domain. Once the PDC has
been upgraded, you can upgrade the backup domain controllers (BDCs). For more
information, see Upgrading from a Windows NT domain.
If you currently have a Windows 2000 forest that does not have any domain controllers
running Windows Server 2003, you will need to prepare the forest and the target
domain before you can upgrade domain controllers running Windows 2000. For more
information, see Upgrading from a Windows 2000 domain.
Renaming domain controllers

 04/24/2013
Renaming domain controllers

The ability to rename domain controllers running Windows Server 2003 provides you
with the flexibility to make changes in a Windows Server 2003 domain whenever the
need arises. Rename a domain controller to:
 Restructure your network for organizational and business needs.
 Make management and administrative control easier.
When you rename a domain controller, you must ensure that there will be no
interruption in the ability of clients to locate or authenticate to the renamed domain
controller, except when the domain controller is restarted. The recommended practice
for renaming a domain controller without interruption to clients is to use the Netdom
tool. To rename a domain controller using the Netdom tool, the domain functional level
must be set to Windows Server 2003. For more information about renaming a domain
controller, see Rename a domain controller.
The System Properties dialog box can also be used to rename a domain controller, and
it does not require the functional level to be raised to Windows Server 2003. Using this
dialog box may result in a service interruption to clients. For more information about
functional levels, see Domain and forest functionality.
The new name of the domain controller is automatically updated to Domain Name
System (DNS) and Active Directory. Once the new name propagates to DNS and Active
Directory, clients are then capable of locating and authenticating to the renamed
domain controller. DNS and Active Directory replication latency may delay client ability
to locate or authenticate to the renamed domain controller. The length of time this
takes depends on specifics of your network and the replication topology of your
particular organization.
During replication latency, clients may not be able to access the newly renamed domain
controller. This might be acceptable for clients that try to locate and authenticate to a
particular domain controller since other domain controllers should be available to
process the authentication request.
Connecting to domain
controllers running Windows
2000
 06/06/2011
Connecting to domain controllers running

Windows 2000
When you need to connect to a domain controller running Windows 2000 from a
domain controller running Windows Server 2003, a number of Active Directory
administrative tools are available, such as Active Directory Domains and Trusts.
The following Windows Server 2003 Active Directory administrative tools will sign and
encrypt all LDAP traffic by default:
 Active Directory Users and Computers
 Active Directory Sites and Services
 Active Directory Domains and Trusts
 Active Directory Schema
 ADSI Edit
 Dsrm.exe
 Dsmove.exe
 Dsadd.exe
 Dsmod.exe
 Dsget.exe
 Dsquery.exe
Signing LDAP traffic guarantees that the packaged data comes from a known source
and that it has not been tampered with. The Active Directory administrative tools in
Windows 2000 do not sign and encrypt all LDAP traffic by default. In order to maintain a
secure network, it is strongly recommended that you upgrade all domain controllers
running Windows 2000 to Service Pack 3 or later.
You can use the corresponding Active Directory administrative tools in Windows 2000 to
manage Windows 2000 domain controllers that do not have the Windows 2000 Server
Service Pack 3 or later installed. However, traffic is not signed and encrypted by LDAP on
domain controllers running Windows 2000.
Although it is not recommended, you can disable encrypted and signed LDAP traffic
used with Active Directory administrative tools on a server running Windows
Server 2003 or on a computer running Windows XP Professional that has the Windows
Server 2003 Administration Tools Pack installed. For more information, see Disable
signed or encrypted LDAP traffic.
Domains
 06/06/2011
Domains
Domains are units of replication. All of the domain controllers in a particular domain can
receive changes and replicate those changes to all other domain controllers in the
domain. Each domain in Active Directory is identified by a Domain Name System (DNS)
domain name and requires one or more domain controllers. If your network requires
more than one domain, you can easily create multiple domains.
One or more domains that share a common schema and global catalog are referred to
as a forest. The first domain in a forest is referred to as the forest root domain. For more
information about forests, see Creating a new forest. If multiple domains in the forest
have contiguous DNS domain names, then the structure is referred to as a domain tree.
For more information, see Active Directory naming and Creating a new domain tree.
A single domain can span multiple physical locations or sites and can contain millions of
objects. Site structure and domain structure are separate and flexible. A single domain
can span multiple geographical sites, and a single site can include users and computers
belonging to multiple domains. For more information, see Sites overview.
A domain provides several benefits:
 Organizing objects.
You do not need to create separate domains merely to reflect your company's
organization of divisions and departments. Within a domain, you can use
organizational units for this purpose. Using organizational units helps you manage
the accounts and resources in the domain. You can then assign Group Policy
settings and place users, groups, and computers into the organizational units.
Using a single domain greatly simplifies administrative overhead. For more
information, see Organizational units.
 Publishing resources and information about domain objects.
A domain stores only the information about objects located in that domain, so by
creating multiple domains, you are partitioning or segmenting the directory to
better serve a disparate user base. When using multiple domains, you can scale the
Active Directory directory service to accommodate your administrative and
directory publishing requirements. For more information, Publishing resources.
 Applying a Group Policy object to the domain consolidates resource and

security management.
A domain defines a scope or unit of policy. A Group Policy object (GPO) establishes
how domain resources can be accessed, configured, and used. These policies are
applied only within the domain and not across domains. For more information
about applying GPOs, see Group Policy (pre-GPMC).
 Delegating authority eliminates the need for a number of administrators with

broad administrative authority.
Using delegated authority in conjunction with Group Policy objects and group
memberships enables you to assign an administrator rights and permissions to
manage objects in an entire domain or in one or more organizational units within
the domain. For more information about delegating administrative control, see
Delegating administration.
 Security policies and settings (such as user rights and password policies) do
not cross from one domain to another.
Each domain has its own security policies and trust relationships with other
domains. However, the forest is the final security boundary. For more information,
see Creating a new forest.
 Each domain stores only the information about the objects located in that
domain.
By partitioning the directory this way, Active Directory can scale to very large
numbers of objects.
Creating a domain
You create a domain by creating the first domain controller for a domain. To do this,
install Active Directory on a member server running Windows Server 2003 by using the
Active Directory Installation Wizard. The wizard uses the information that you provide to
create the domain controller and create the domain within the existing domain structure
of your organization. Depending on the existing domain structure, the new domain
could be the first domain in a new forest, the first domain in a new domain tree, or a
child domain of an existing domain tree. For more information, see Creating a new
forest, Creating a new domain tree, and Creating a new child domain.
A domain controller provides the Active Directory directory service to network users and
computers, stores directory data, and manages user and domain interactions, including
user logon processes, authentication, and directory searches. Every domain must contain
at least one domain controller. For more information, see Domain controllers.
After you create the first domain controller for a domain, you can create additional
domain controllers in an existing domain for fault tolerance and high availability of the
directory. For more information, see Creating an additional domain controller.
Planning for multiple domains

Some reasons to create more than one domain are:
 Different password requirements between departments or divisions
 Massive numbers of objects

 Decentralized network administration
 More control of replication
Although using a single domain for an entire network has several advantages, to meet
additional scalability, security, or replication requirements you may consider creating
one or more domains for your organization. Understanding how directory data is
replicated between domain controllers will help you plan the number of domains
needed by your organization. For more information about replication, see How
replication works.
Removing a domain
In order to remove a domain, you must first remove Active Directory from all of the
domain controllers associated with that domain. Once Active Directory has been
removed from the last domain controller the domain will be removed from the forest
and all of the information in that domain will be deleted. A domain can only be removed
from the forest if it has no child domains. If this is the last domain in the forest,
removing this domain will also delete the forest.
For more information about how to remove a domain, see Remove a domain.
Caution
 Removing a domain will result in the permanent loss of amy data contained in that
domain. This includes all user, group, and computer accounts.
Before removing Active Directory from a domain controller, you should first remove any
application directory partitions from that domain controller. For more information, see
Application directory partitions and Create or delete an application directory partition.
Trust relationships between domains

Trust relationships are automatically created between adjacent domains (parent and
child domains) when a domain is created in Active Directory. In a forest, a trust
relationship is automatically created between the forest root domain and any tree root
domains or child domains that are subordinate to the forest root domain. Because these
trust relationships are transitive, users and computers can be authenticated between any
domains in the forest. For more information about trust relationships, see Trust
transitivity.
When upgrading a Windows NT domain to a Windows Server 2003 domain, the existing
one-way trust relationship between that domain and any other domains remains intact.
This includes all trusts with other Windows NT domains. If you are creating a new
Windows Server 2003 domain and want trust relationships with any Windows NT
domains, you must create external trusts with those domains. For more information
about external trusts, see When to create an external trust.
Renaming domains
 06/06/2011
Renaming domains
The ability to rename a domain provides you with the flexibility to make important
changes to your forest structure and namespace as the needs of your organization
change. Renaming domains can accommodate acquisitions, mergers, name changes, or
reorganizations. Domain rename allows you to:
 Change the Domain Name System (DNS) and NetBIOS names of any domain in the
forest (including the forest root domain).
 Restructure the position of any domain in the forest (except the forest root
domain).
You can only rename domains in a forest where all of the domain controllers are
running Windows Server 2003 and the forest functional level has been raised to
Windows Server 2003. For more information, see Domain and forest functionality.
Forest restructuring
Using domain rename, you can also restructure the hierarchy of domains in your forest
so that a domain residing in one domain tree can be moved to another domain tree.
Restructuring a forest allows you to move a domain anywhere within the forest in which
it resides (except the forest root domain). This includes the ability to move a domain so
that it becomes the root of its own domain tree.
You can use the domain rename utility (Rendom.exe) to rename or restructure a domain.
A domain rename will affect every domain controller in your forest and is a multistep
process that requires a detailed understanding of the operation. For more information
about this process and to download the Rendom.exe tool, see the Windows Server 2003
Active Directory Domain Rename Tools page at the Microsoft Web site.
 06/06/2011
In this article
1. Domain and forest functionality
2. Domain functionality
3. Forest functionality
Domain and forest functionality, introduced in Windows Server 2003 Active Directory,
provides a way to enable domain- or forest-wide Active Directory features within your
network environment. Different levels of domain functionality and forest functionality
are available depending on your environment.

If all domain controllers in your domain or forest are running Windows Server 2003 and
the functional level is set to Windows Server 2003, all domain- and forest-wide features
are available. When Windows NT 4.0 or Windows 2000 domain controllers are included
in your domain or forest with domain controllers running Windows Server 2003, Active
Directory features are limited. For more information about how to enable domain- or
forest-wide features, see Raising domain and forest functional levels.
The concept of enabling additional functionality in Active Directory exists in
Windows 2000 with mixed and native modes. Mixed-mode domains can contain
Windows NT 4.0 backup domain controllers and cannot use Universal security groups,
group nesting, and security ID (SID) history capabilities. When the domain is set to
native mode, Universal security groups, group nesting, and SID history capabilities are
available. Domain controllers running Windows 2000 Server are not aware of domain
and forest functionality.
Domain functionality
Domain functionality enables features that will affect the entire domain and that domain
only. Four domain functional levels are available: Windows 2000 mixed (default),
Windows 2000 native, Windows Server 2003 interim, and Windows Server 2003. By
default, domains operate at the Windows 2000 mixed functional level.
The following table lists the domain functional levels and their corresponding supported
domain controllers.
Domain functional level Domain controllers supported
Windows NT 4.0
Windows 2000 mixed (default) Windows 2000
Windows Server 2003 family
Windows 2000
Windows 2000 native
Windows NT 4.0
Windows Server 2003 interim
Windows Server 2003 Windows Server 2003 family
Once the domain functional level has been raised, domain controllers running earlier
operating systems cannot be introduced into the domain. For example, if you raise the
domain functional level to Windows Server 2003, domain controllers running
Windows 2000 Server cannot be added to that domain.
The following table describes the domain-wide features that are enabled for three of the
domain functional levels. For information about the Windows Server 2003 interim
functional level, see Upgrading from a Windows NT domain.
Windows 2000 Windows 2000 Windows

Domain feature
mixed native Server 2003
Domain controller rename
tool Disabled Disabled Enabled

Domain feature
For more information, see
Renaming domain
controllers.
Different location option
for user and computer
accounts
For more information about

Disabled Disabled Enabled
how to redirect the default
location for user and
computer accounts, see
Redirect the Users and
Computers Containers.
Update logon timestamp

the lastLogonTimestamp
attribute, see User and
computer accounts.
User password on
InetOrgPerson object
InetOrgPerson objects, see

Domain feature
User and computer
accounts.
Enabled Enabled
Universal Groups Enabled for
distribution groups. Allows both Allows both

security and security and
Group types and Group Disabled for security
distribution distribution
scope. groups.
groups. groups.
Enabled for
distribution groups.
Group Nesting Disabled for security Enabled Enabled
groups, except for

For more information, see Allows full group Allows full
domain local security
Nesting groups. nesting. group nesting.
groups that can have
global groups as
members.
Enabled
Enabled
Converting Groups Disabled Allows conversion

Allows
between security
For more information, see No group conversion
groups and
Converting groups. conversions allowed. between
distribution
security groups
groups.
Domain feature
and distribution
groups.
Enabled
Enabled
Allows
Allows migration
migration of
SID history Disabled of security
security
principals from
principals from
one domain to
one domain to
another.
another.
Forest functionality
Forest functionality enables features across all the domains within your forest. Three
forest functional levels are available: Windows 2000 (default), Windows Server 2003
interim, and Windows Server 2003 . By default, forests operate at the Windows 2000
functional level. You can raise the forest functional level to Windows Server 2003 .
The following table lists the forest functional levels and their corresponding supported
domain controllers:
Windows NT 4.0
Windows 2000 (default)
Windows 2000
Windows NT 4.0
Windows Server 2003interim
Windows Server 2003 Windows Server 2003 family
Once the forest functional level has been raised, domain controllers running earlier
operating systems cannot be introduced into the forest. For example, if you raise the
forest functional level to Windows Server 2003, domain controllers running
Windows 2000 Server cannot be added to the forest.
If you are upgrading your first Windows NT 4.0 domain so that it becomes the first
domain in a new Windows Server 2003 forest, you can set the domain functional level to
Windows Server 2003 interim. For more information, see Upgrading from a Windows NT
domain.
The following table describes the forest-wide features that are enabled for the
Windows 2000 and Windows Server 2003 forest functional levels.

Windows
Forest feature Windows 2000
Server 2003
Global catalog replication Enabled if both replication
improvements partners are running Windows
Server 2003. Enabled

For more information, see Global
catalog replication. Otherwise, disabled.
Defunct schema objects
Disabled Enabled
Deactivating a class or attribute.
Forest trusts
Disabled Enabled
For more information, see Forest
trusts.
Linked value replication
Disabled Enabled
For more information, see How
replication works.
Domain rename
Disabled Enabled
For more information, see Renaming
domains.
Improved Active Directory
replication algorithms Disabled Enabled

Windows
Forest feature Windows 2000
Server 2003
Replication overview.
Dynamic auxiliary classes.
Disabled Enabled
For more information, see New
features for Active Directory.
InetOrgPerson objectClass change
For more information about Disabled

InetOrgPerson objects, see User and
computer accounts.
Raising domain and forest

functional levels
 06/06/2011
Raising domain and forest functional levels

When Active Directory is installed on a server running Windows Server 2003, a set of
basic Active Directory features is enabled by default. For more information about the
new default features, see New features for Active Directory.
In addition to the basic Active Directory features on individual domain controllers, there
are new domain- and forest-wide Active Directory features available when all domain
controllers in a domain or forest are running Windows Server 2003.
To enable the new domain-wide features, all domain controllers in the domain must be
running Windows Server 2003, and the domain functional level must be raised to
Windows Server 2003 . For information about raising the domain functional level, see
Raise the domain functional level.
To enable new forest-wide features, all domain controllers in the forest must be running
Windows Server 2003, and the forest functional level must be raised to Windows
Server 2003 . Before raising the forest functional level to Windows Server 2003 , verify
that all domains in the forest are set to the domain functional level of Windows 2000
native or Windows Server 2003 . Note that domains that are set to the domain
functional level of Windows 2000 native will automatically be raised to Windows
Server 2003 at the same time the forest functional level is raised to Windows Server 2003
. For information about raising the forest functional level, see Raise the forest functional
level.
Application directory partitions

 06/06/2011
Application directory partitions

An application directory partition is a directory partition that is replicated only to
specific domain controllers. A domain controller that participates in the replication of a
particular application directory partition hosts a replica of that partition. Only domain
controllers running Windows Server 2003 can host a replica of an application directory
partition.
Applications and services can use application directory partitions to store application-
specific data. Application directory partitions can contain any type of object, except
security principals. TAPI is an example of a service that stores its application-specific
data in an application directory partition.
Application directory partitions are usually created by the applications that will use them
to store and replicate data. For testing and troubleshooting purposes, members of the
Enterprise Admins group can manually create or manage application directory partitions
using the Ntdsutil command-line tool.
One of the benefits of an application directory partition is that, for redundancy,

availability, or fault tolerance, the data in it can be replicated to different domain
controllers in a forest. The data can be replicated to a specific domain controller or any
set of domain controllers anywhere in the forest. This differs from a domain directory
partition in which data is replicated to all domain controllers in that domain. Storing
application data in an application directory partition instead of in a domain directory
partition may reduce replication traffic because the application data is only replicated to
specific domain controllers. Some applications may use application directory partitions
to replicate data only to servers where the data will be locally useful.
Another benefit of application directory partitions is that applications or services that

use Lightweight Directory Access Protocol (LDAP) can continue using it to access and
store their application data in Active Directory. For more information, see Managing
application directory partitions.
Application directory partition naming

An application directory partition is part of the overall forest namespace just like a
domain directory partition. It follows the same Domain Name System (DNS) and
distinguished names naming conventions as a domain directory partition. An application
directory partition can appear anywhere in the forest namespace that a domain
directory partition can appear.
There are three possible application directory partition placements within your forest
namespace:
 A child of a domain directory partition.

 A child of an application directory partition.
 A new tree in the forest.
If you created an application directory partition called example1 as a child of the

microsoft.com domain, the DNS name of the application directory partition would be
example1.microsoft.com. The distinguished name of the application directory partition
would be dc=example1, dc=microsoft, dc=com.
If you then created an application directory partition called example2 as a child of

example1.microsoft.com, the DNS name of the application directory partition would be
example2.example1.microsoft.com and the distinguished name would be dc=example2,
dc=example1, dc=microsoft, dc=com.
If the domain microsoft.com was the root of the only domain tree in your forest, and
you created an application directory partition with the DNS name of example1 and the
distinguished name of dc=example1, this application directory partition is not in the
same tree as the microsoft.com domain. This application directory partition would be
the root of a new tree in the forest.
Domain directory partitions cannot be children of an application directory partition. For

example, if you created an application directory partition with the DNS name of
example1.microsoft.com, you could not create a domain with the DNS name of
domain.example1.microsoft.com.
Application directory partition replication

The Knowledge Consistency Checker (KCC) automatically generates and maintains the
replication topology for all application directory partitions in the enterprise. When an
application directory partition has replicas in more than one site, those replicas follow
the same intersite replication schedule as the domain directory partition.
Notes
 Objects stored in an application directory partition are never replicated to the

global catalog as read-only replicas. Any domain controller running Windows
Server 2003 can hold a replica, including global catalogs.
 Additionally, if an application requests data through the global catalog port, that
query will not return any objects from an application directory partition, even if the
computer hosting the application directory partition is also hosting the global
catalog. This is done so that LDAP queries to different global catalogs will not
return inconsistent results because the application directory partition is replicated
to only one of the global catalogs.
Security descriptor reference domain

Every container and object on the network has a set of access control information
attached to it. Known as a security descriptor, this information controls the type of
access allowed by users, groups, and computers. If the object or container is not
assigned a security descriptor by the application or service that created it, then it is
assigned the default security descriptor for that object class as defined in the schema.
This default security descriptor is ambiguous in that it may assign members of the
Domain Admins group read permissions to the object, but it does not specify to what
domain the domain administrators belong. When this object is created in a domain
naming partition, that domain naming partition is used to specify which Domain Admins
group actually is assigned read permission. For example, if the object is created in
mydomain.microsoft.com then members of the mydomain Domain Admins group would
be assigned read permission.
When an object is created in an application directory partition, the definition of the

default security descriptor is difficult because an application directory partition can have
replicas on different domain controllers belonging to different domains. Because of this
potential ambiguity, a default security descriptor reference domain is assigned when the
application directory partition is created.
The default security descriptor reference domain defines what domain name to use
when an object in the application directory partition needs to define a domain value for
the default security descriptor. The default security descriptor reference domain is
assigned at the time of creation.
If the application directory partition is a child of a domain directory partition, by default,

the parent domain directory partition becomes the security descriptor reference domain.
If the application directory partition is a child object of another application directory
partition, the security descriptor reference domain of the parent application directory
partition becomes the reference domain of the new, child, application directory
partition. If the new application directory partition is created as the root of a new tree,
then the forest root domain is used as the default security descriptor reference domain.
You can manually specify a security reference domain using Ntdsutil. However, if you
plan to change the default security descriptor reference domain of a particular
application directory partition, you should do so before creating the first instance of that
partition. To do this, you must prepare the cross-reference object and change the
default security reference domain before completing the application directory partition
creation process. For information about precreating the cross-reference object, see
Prepare a cross-reference object. For information about changing the default security
reference domain, see Set an application directory partition reference domain.
Managing application directory

partitions
 06/06/2011
Managing application directory partitions

You can use the following tools to create, delete, or manage application directory
partitions.
 application-specific tools from the application vendor
 Ntdsutil command-line tool
 LDP
 Active Directory Service Interfaces (ADSI)
For information about creating and managing application directory partitions with ADSI,
see Active Directory Service Interfaces (ADSI) at the Microsoft Web site. For information
about LDP, see Administration tools for the Active Directory schema.
For information about the Ntdsutil command-line tool, see Ntdsutil.
The following provides information about using Ntdsutil to create and manage
application directory partitions.
Creating an application directory partition

When you create an application directory partition, you are creating the first instance of
this partition. You can create an application directory partition by using the create nc
option in the domain management menu of Ntdsutil. When creating an application
directory partition using LDP or ADSI, provide a description in the description attribute
of the domain DNS object that indicates the specific application that will use the
partition. For example, if the application directory partition will be used to store data for
a Microsoft accounting program, the description could be Microsoft accounting
application. Ntdsutil does not facilitate the creation of a description. For more
information, see Create or delete an application directory partition.
Deleting an application directory partition

When you delete an application directory partition, you are removing all replicas of that
partition from your forest. You can delete an application directory partition by using the
delete nc command in the domain management menu of Ntdsutil. The deletion
process will need to replicate to all domain controllers that contain a replica of the
application directory partition before the deletion process is complete. Any data that is
contained in the application directory partition will be lost.
The Active Directory Promotion Wizard (Dcpromo) cannot demote a domain controller if
that domain controller holds a copy of an application directory partition. For more
information, see Create or delete an application directory partition.
Adding and removing a replica of an

application directory partition
An application directory partition replica is an instance of an partition on another
domain controller. The information in the application directory partition is replicated
between the domain controllers. Application directory partition replicas are created for
either redundancy or data access purposes. You can add a replica of an application
directory partition by using the add nc replica command in the domain management
menu of Ntdsutil. You can remove an application directory partition replica by using the
delete nc replica command in the domain management menu of Ntdsutil. For more
information, see Add or remove an application directory partition replica.
Setting application directory partition

reference domain
The security descriptor reference domain defines a domain name for the default security
descriptor for objects in the application directory partition. By default, the security
descriptor reference domain is the parent domain of the application directory partition.
If the application directory partition is a child of another application directory partition,
the default security descriptor reference domain is the security descriptor reference
domain of the parent application directory partition. If the application directory partition
has no parent, the forest root domain becomes the default security descriptor reference
domain. You can use Ntdsutil to change the default security descriptor reference
domain. For more information, see Set an application directory partition reference
domain.
Setting replication notification delays

Changes made to a particular directory partition on a particular domain controller are
replicated to the other domain controllers that contain that directory partition. The
domain controller on which the change was made notifies its replication partners that it
has a change. You can configure how long the domain controller will wait to send the
change notification to its first replication partner. You can also configure how long it
waits to send the subsequent change notification to its remaining replication partners.
These delays can be set for any directory partition (including domain directory
partitions) on a particular domain controller. For more information, see Set a notification
delay.
Displaying application directory partition

information
Any domain controller that holds a replica of a particular directory partition (including
application directory partitions) is said to be a member of the replica set for that
directory partition. You can use Ntdsutil to list the domain controllers that are members
of a particular replica set for an application directory partition. An addition of a domain
controller to the replica set attribute on the cross-reference object does not create the
replica, but it will display when the list nc replica command is used in Ntdsutil. The
creation of the instance must replicate before the creation of the replica is complete. For
more information, see Display application directory partition information.
Delegating the creation of application

directory partitions
There are two things that happen when creating an application directory partition:
 Creation of the cross-reference object.
 Creation of the application directory partition root node.

Normally only members of the Enterprise Admins group can create an application
directory partition. However, it is possible for a member of the Enterprise Admins group
to prepare a cross-reference object for the application directory partition and to
delegate the rest of the process to someone with more limited permissions.
The cross-reference object for an application directory partition holds several valuable
pieces of information, including the domain controllers that are to have a replica of this
partition and the security descriptor reference domain. The partition root node is the
Active Directory object at the root of the partition
The Enterprise Admin can create the cross-reference object then delegate to a person or
group with less permissions the right to create the application directory partition root
node. Both creation of the cross-reference object and the application directory partition
root node can be accomplished using Ntdsutil.
After using Ntdsutil to create the cross-reference object, the enterprise administrator
must modify the cross-reference object's access control list to allow the delegated
administrator to modify this cross-reference. This will allow the delegated administrator
to create the application directory partition and modify the list of domain controllers
that holds replicas of this application directory partition. The delegated administrator
must use the names of the application directory partition and the domain controller
name that were specified during the precreation process. For more information, see
Prepare a cross-reference object.
For more information about application directory partitions, see Application directory
partitions.
Groups
 06/06/2011
Groups
A group is a collection of user and computer accounts, contacts and other groups that
can be managed as a single unit. Users and computers that belong to a particular group
are referred to as group members.
Using groups can simplify administration by assigning a common set of permissions and
rights to many accounts at once, rather than assigning permissions and rights to each
account individually. For an overview of permissions and rights, see Access control
overview.
Groups can be either directory-based or local to a particular computer. Groups in Active

Directory are directory objects that reside within a domain and organizational unit
container objects. Active Directory provides a set of default groups upon installation,
and also allows the option to create groups. For more information, see Default groups.
Local groups, which exist on local computers and not in Active Directory, are discussed
in Default local groups.
Groups in Active Directory allow you to:
 Simplify administration by assigning permissions on a shared resource to a group,

rather than to individual users. This assigns the same access on the resource to all
members of that group.
 Delegate administration by assigning user rights once to a group through Group

Policy, and then adding necessary members to the group that you want to have
the same rights as the group.
 Create e-mail distribution lists. For more information, see Group types.
Groups are characterized by their scope and their type. The scope of a group
determines the extent to which the group is applied within a domain or forest. For
information about group scope, see Group scope. The group type determines whether a
group can be used to assign permissions from a shared resource (for security groups) or
if a group can be used for e-mail distribution lists only (for distribution groups). For
information about security groups and distribution groups, see Group types.
There are also groups for which you cannot modify or view the memberships. These
groups are referred to as special identities and are used to represent different users at
different times, depending on the circumstances. For example, the Everyone group
represents all current network users, including guests and users from other domains. For
more information, see Special identities.
Group scope
 10/06/2014
SP1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows
Server 2012 R2
Group scope
Any group, whether it is a security group or a distribution group, is characterized by a
scope that identifies the extent to which the group is applied in the domain tree or
forest. The boundary, or reach, of a group scope is also determined by the domain
functional level setting of the domain in which it resides. There are three group scopes:
universal, global, and domain local.
The following table describes the differences between the scopes of each group.
Group Group can include as members… Group can be assigned Group scope can be
scope permissions in… converted to…
Universal  Accounts from any domain Any domain or forest  Domain local
within the forest in which this
Universal Group resides  Global (as long
other universa
 Global groups from any domain exist as memb
within the forest in which this
Universal Group resides
 Universal groups from any

domain within the forest in
which this Universal Group
resides
Global  Accounts from the same Member permissions can be assigned Universal (as long as
domain as the parent global in any domain member of any other
group groups)
 Global groups from the same

domain as the parent global
group
Domain  Accounts from any domain Member permissions can be assigned Universal (as long as
local only within the same domain as the domain local groups
 Global groups from any domain parent domain local group members)
 Universal groups from any

domain
 Domain local groups but only

from the same domain as the
parent domain local group
Note
The information in this table implies that the domain functional level is set to either
Windows 2000 native or Windows Server 2003. When the domain functional level is set
to Windows 2000 mixed or Windows Server 2003 interim, security groups with universal
scope cannot be created, although distribution groups with universal scope are still
permitted.
When to use groups with domain local scope

Groups with domain local scope help you define and manage access to resources within
a single domain. For example, to give five users access to a particular printer, you can
add all five user accounts in the printer permissions list. If, however, you later want to
give the five users access to a new printer, you must again specify all five accounts in the
permissions list for the new printer.
With a little planning, you can simplify this routine administrative task by creating a
group with domain local scope and assigning it permission to access the printer. Put the
five user accounts in a group with global scope, and then add this group to the group
having domain local scope. When you want to give the five users access to a new
printer, assign the group with domain local scope permission to access the new printer.
All members of the group with global scope automatically receive access to the new
printer.
When to use groups with global scope

Use groups with global scope to manage directory objects that require daily
maintenance, such as user and computer accounts. Because groups with global scope
are not replicated outside their own domain, you can change accounts in a group
having global scope frequently without generating replication traffic to the global
catalog. For more information about groups and replication, see How replication works.
Although rights and permissions assignments are valid only within the domain in which
they are assigned, by applying groups with global scope uniformly across the
appropriate domains, you can consolidate references to accounts with similar purposes.
This simplifies and rationalizes group management across domains. For example, in a
network with two domains, Europe and UnitedStates, if you have a group with global
scope called GLAccounting in the UnitedStates domain, create a group called
GLAccounting in the Europe domain (unless the accounting function does not exist in
the Europe domain).
It is strongly recommended that you use global groups or universal groups instead of
domain local groups when you specify permissions on domain directory objects that are
replicated to the global catalog. For more information, see Global catalog replication.
Note
When the domain functional level is set to Windows 2000 mixed, members of global
groups can include only accounts from the same domain.
When to use groups with universal scope

Use groups with universal scope to consolidate groups that span domains. To do this,
add the accounts to groups with global scope, and then nest these groups within
groups that have universal scope. When you use this strategy, any membership changes
in the groups that have global scope do not affect the groups with universal scope.
For example, in a network with two domains, Europe and UnitedStates, and a group that
has global scope called GLAccounting in each domain, create a group with universal
scope called UAccounting that has as its members the two GLAccounting groups,
UnitedStates\GLAccounting and Europe\GLAccounting. The UAccounting group can
then be used anywhere in the enterprise. Any changes in the membership of the
individual GLAccounting groups will not cause replication of the UAccounting group.
If the forest functional level is Windows Server 2003 or higher, changes to the
membership of universal groups are replicated to each global catalog server using
linked-value replication. This means that only the changed membership is replicated,
rather than the entire group. If the forest functional level is lower than Windows Server
2003, you should not change the membership of a group with universal scope
frequently because any changes to these group memberships cause the entire
membership of the group to be replicated to every global catalog in the forest. For
more information about universal groups and replication, see Global catalogs and sites.
For more information about linked value replication, see How the Active Directory
Replication Model Works.
Note
When the domain functional level is set to Windows 2000 mixed, you cannot create
security groups with universal scope.
Changing group scope

When you create a new group, by default the new group is configured as a security
group with global scope, regardless of the current domain functional level. Although
changing a group scope is not allowed in domains with a domain functional level of
Windows 2000 mixed, the following conversions are allowed in domains with the
domain functional level of Windows 2000 native or Windows Server 2003:
 Global to universal. This conversion is allowed only if the group that you want to
change is not a member of another global scope group.
 Domain local to universal. This conversion is allowed only if the group that you
want to change does not have another domain local group as a member.
 Universal to global. This conversion is allowed only if the group that you want to
change does not have another universal group as a member.
 Universal to domain local. There are no restrictions for this operation.
For more information, see Change group scope.
Groups on client computers and stand-alone

servers
Some group features, such as universal groups, group nesting, and the distinction
between security groups and distribution groups, are available only on Active Directory
domain controllers and member servers. Group accounts on
Windows 2000 Professional, Windows XP Professional, Windows 2000 Server, and stand-
alone servers running Windows Server 2003 work the same way as in Windows NT 4.0:
 Only local groups can be created locally on the computer.
 A local group that is created on one of these computers can be assigned

permissions only on that one computer.
For more information, see Default local groups.
Group types
 06/06/2011
Group types
Groups are used to collect user accounts, computer accounts, and other group accounts
into manageable units. Working with groups instead of with individual users helps
simplify network maintenance and administration.
There are two types of groups in Active Directory: distribution groups and security
groups. You can use distribution groups to create e-mail distribution lists and security
groups to assign permissions to shared resources.
Distributions groups
Distribution groups can be used only with e-mail applications (such as Exchange) to
send e-mail to collections of users. Distribution groups are not security-enabled, which
means that they cannot be listed in discretionary access control lists (DACLs). If you
need a group for controlling access to shared resources, create a security group.
Security groups
Used with care, security groups provide an efficient way to assign access to resources on
your network. Using security groups, you can:
 Assign user rights to security groups in Active Directory
User rights are assigned to security groups to determine what members of that
group can do within the scope of a domain (or forest). User rights are
automatically assigned to some security groups at the time Active Directory is
installed to help administrators define a person's administrative role in the domain.
For example, a user who is added to the Backup Operators group in Active
Directory has the ability to backup and restore files and directories located on each
domain controller in the domain.
This is possible because by default, the user rights Back up files and directories and
Restore files and directories are automatically assigned to the Backup Operators
group. Therefore, members of this group inherit the user rights assigned to that
group. For more information about user rights, see User rights. For more
information about the user rights assigned to security groups, see Default groups.
You can assign user rights to security groups, using Group Policy, to help delegate
specific tasks. You should always use discretion when assigning delegated tasks
because an untrained user assigned too many rights on a security group can
potentially cause significant harm to your network. For more information, see
Delegating administration. For more information about assigning user rights to
groups, see Assign user rights to a group in Active Directory.
 Assign permissions to security groups on resources
Permissions should not be confused with user rights. Permissions are assigned to
the security group on the shared resource. Permissions determine who can access
the resource and the level of access, such as Full Control. Some permissions set on
domain objects are automatically assigned to allow various levels of access to
default security groups such as the Account Operators group or the Domain
Admins group. For more information about permissions, see Access control in
Active Directory.
Security groups are listed in DACLs that define permissions on resources and
objects. When assigning permissions for resources (file shares, printers, and so on),
administrators should assign those permissions to a security group rather than to
individual users. The permissions are assigned once to the group, instead of
several times to each individual user. Each account added to a group receives the
rights assigned to that group in Active Directory and the permissions defined for
that group at the resource.
Like distribution groups, security groups can also be used as an e-mail entity. Sending
an e-mail message to the group sends the message to all the members of the group.
Converting between security and distribution

groups
A group can be converted from a security group to a distribution group, and vice versa,
at any time, but only if the domain functional level is set to Windows 2000 native or
higher. No groups can be converted while the domain functional level is set to
Windows 2000 mixed.
For specific procedural information, see Convert a group to another group type. For
information about domain functionality, see Domain and forest functionality.
Note
 Although a contact can be added to a security group as well as to a distribution group,

contacts cannot be assigned rights and permissions. Contacts in a group can be sent e-
mail.
Default groups
 06/06/2011
In this article
1. Default groups
2. Groups in the Builtin container
3. Groups in the Users container
4. See Also
Default groups
Default groups, such as the Domain Admins group, are security groups that are created
automatically when you create an Active Directory domain. You can use these
predefined groups to help control access to shared resources and delegate specific
domain-wide administrative roles. For information about default groups stored on local
computers, see Default local groups.
Many default groups are automatically assigned a set of user rights that authorize
members of the group to perform specific actions in a domain, such as logging on to a
local system or backing up files and folders. For example, a member of the Backup
Operators group has the right to perform backup operations for all domain controllers
in the domain.
When you add a user to a group, the user receives all the user rights assigned to the
group and all the permissions assigned to the group on any shared resources. For more
information about user rights and permissions, see Group types.

You can manage groups by using the Active Directory Users and Computers snap-in in
Microsoft Management Console (MMC). Default groups are located in the Builtin
container and the Users container.
The Builtin container default groups contain groups that are defined with domain local
scope. You can move groups in and out of this container, but you cannot move the
default groups in this container to another location or to another domain.
The Users container default groups contain groups that are defined with global scope
and groups that are defined with domain local scope. You can add the groups in this
container to other groups and you can move the default groups in this container to
other organizational units (OUs) or containers, but you cannot move the group to
another domain.
As a security best practice, it is recommended that members of default groups with
broad administrative access use the Run as command to perform administrative tasks.
For more information, see Using Run as. For information about security best practices,
see Active Directory Best practices. For information about additional security measures
that can be used to protect Active Directory, see Securing Active Directory.
Note
 To learn what group you need to be a member of to perform a particular procedure,
many procedural topics under How To in Help and Support Center provide a note that
identifies this information.
Groups in the Builtin container

The following table provides descriptions of the default groups located in the Builtin
container and lists the assigned user rights for each group. For complete descriptions of
the user rights listed in the table, see User Rights Assignment. For information about
editing these rights, see Edit security settings on a Group Policy object.
Group Description Default user rights
Members of this group can create,
modify, and delete accounts for
users, groups, and computers
located in the Users or Computers
containers and organizational
units in the domain, except the
Domain Controllers organizational
unit. Members of this group do
not have permission to modify the

Account Allow log on locally; Shut down
Administrators or the Domain
Operators the system.
Admins groups, nor do they have
permission to modify the
accounts for members of those
groups. Members of this group
can log on locally to domain
controllers in the domain and shut
them down. Because this group
has significant power in the
domain, add users with caution.

Access this computer from the
network; Adjust memory quotas
for a process; Back up files and
directories; Bypass traverse
checking; Change the system
time; Create a pagefile; Debug

Members of this group have full
programs; Enable computer and
control of all domain controllers in
user accounts to be trusted for
the domain. By default, the
delegation; Force a shutdown
Domain Admins and Enterprise
from a remote system; Increase
Admins groups are members of
Administrators scheduling priority; Load and
the Administrators group. The
unload device drivers; Allow log
Administrator account is also a
on locally; Manage auditing and
default member. Because this
security log; Modify firmware
group has full control in the
environment values; Profile
domain, add users with caution.
single process; Profile system
performance; Remove computer
from docking station; Restore
files and directories; Shut down
the system; Take ownership of
files or other objects.
Members of this group can back Back up files and directories;

Backup Operators
up and restore all files on domain Allow log on locally; Restore files
controllers in the domain, and directories; Shut down the
regardless of their own individual system.
permissions on those files. Backup
Operators can also log on to
domain controllers and shut them
down. This group has no default
members. Because this group has
significant power on domain
controllers, add users with
caution.
By default, the Domain Guests
group is a member of this group.
Guests The Guest account (which is No default user rights.
disabled by default) is also a
default member of this group.
Members of this group can create
one-way, incoming forest trusts to

Incoming Forest
the forest root domain. For
Trust Builders
example, members of this group
(only appears in No default user rights.
residing in Forest A can create a
the forest root
one-way, incoming forest trust
domain)
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. For more information
about creating forest trusts, see
Create a forest trust.
Members of this group can make
changes to TCP/IP settings and

Network
renew and release TCP/IP
Configuration No default user rights.
addresses on domain controllers
Operators
in the domain. This group has no
default members.
Members of this group can
monitor performance counters on
domain controllers in the domain,

Performance
locally and from remote clients No default user rights.
Monitor Users
without being a member of the
Administrators or Performance
Log Users groups.

manage performance counters,
logs and alerts on domain

Performance Log
controllers in the domain, locally No default user rights.
Users
and from remote clients without
being a member of the
Administrators group.
Members of this group have read
access on all users and groups in
the domain. This group is
provided for backward
compatibility for computers

Pre-
running Windows NT 4.0 and Access this computer from the
Windows 2000
earlier. By default, the special network; Bypass traverse
Compatible
identity Everyone is a member of checking.
Access
this group. For more information
about special identities, see
Special identities. Add users to
this group only if they are running
Windows NT 4.0 or earlier.

Allow log on locally; Shut down
Print Operators manage, create, share, and delete
the system.
printers connected to domain
controllers in the domain. They
can also manage Active Directory
printer objects in the domain.
Members of this group can log on
locally to domain controllers in
the domain and shut them down.
members. Because members of
this group can load and unload
device drivers on all domain
controllers in the domain, add
users with caution.
Remote Desktop remotely log on to domain

No default user rights.
Users controllers in the domain. This
group has no default members.
This group supports directory
replication functions and is used
by the File Replication service on
Replicator domain controllers in the domain. No default user rights.
members. Do not add users to this
group.
On domain controllers, members
of this group can log on
interactively, create and delete

Back up files and directories;
shared resources, start and stop
Change the system time; Force
some services, back up and
shutdown from a remote system;
Server Operators restore files, format the hard disk,
Allow log on locally; Restore files
and shut down the computer. This
and directories; Shut down the
group has no default members.
system.
Because this group has significant
power on domain controllers, add
users with caution.
perform most common tasks, such
as running applications, using
local and network printers, and
locking the server. By default, the
Users Domain Users group, No default user rights.
Authenticated Users, and
Interactive are members of this
group. Therefore, any user
account created in the domain
becomes a member of this group.
Groups in the Users container

The following table provides a description of the default groups located in the Users
container and lists the assigned user rights for each group. For complete descriptions of
the user rights listed in the table, see User Rights Assignment. For information about
editing these rights, see Edit security settings on a Group Policy object.
Members of this group are
permitted to publish certificates for

Cert Publishers No default user rights.
users and computers. This group
has no default members.
Members of this group have

DnsAdmins
administrative access to the DNS
(installed with No default user rights.
Server service. This group has no
DNS)
default members.
Members of this group are DNS
DnsUpdateProxy clients that can perform dynamic
(installed with updates on behalf of other clients, No default user rights.
DNS) such as DHCP servers. This group
has no default members.
Members of this group have full Access this computer from the
control of the domain. By default, network; Adjust memory
this group is a member of the quotas for a process; Back up

Domain Admins
Administrators group on all domain files and directories; Bypass
controllers, all domain workstations, traverse checking; Change the
and all domain member servers at system time; Create a pagefile;

the time they are joined to the Debug programs; Enable
domain. By default, the computer and user accounts
Administrator account is a member to be trusted for delegation;
of this group. Because the group Force a shutdown from a
has full control in the domain, add remote system; Increase
users with caution. scheduling priority; Load and
unload device drivers; Allow
log on locally; Manage
auditing and security log;
Modify firmware environment
values; Profile single process;
Profile system performance;
Remove computer from
docking station; Restore files
and directories; Shut down
This group contains all workstations
and servers joined to the domain. By

Domain
default, any computer account No default user rights.
Computers
created becomes a member of this
group automatically.
Domain This group contains all domain

Controllers controllers in the domain.
This group contains all domain

Domain Guests No default user rights.
guests.
This group contains all domain
users. By default, any user account
created in the domain becomes a
member of this group automatically.
This group can be used to represent
all users in the domain. For example,
Domain Users if you want all domain users to have No default user rights.
access to a printer, you can assign
permissions for the printer to this
group (or add the Domain Users
group to a local group, on the print
server, that has permissions for the
printer).
Members of this group have full Access this computer from the
Enterprise Admins control of all domains in the forest. network; Adjust memory
(only appears in By default, this group is a member quotas for a process; Back up
the forest root of the Administrators group on all files and directories; Bypass
domain) domain controllers in the forest. By traverse checking; Change the
default, the Administrator account is system time; Create a pagefile;

a member of this group. Because Debug programs; Enable
this group has full control of the computer and user accounts
forest, add users with caution. to be trusted for delegation;
Force shutdown from a
remote system; Increase
scheduling priority; Load and
unload device drivers; Allow
log on locally; Manage
auditing and security log;
Modify firmware environment
values; Profile single process;
Profile system performance;
Remove computer from
docking station; Restore files
and directories; Shut down
Members of this group can modify
Group Policy in the domain. By
Group Policy default, the Administrator account is

Creator Owners a member of this group. Because
this group has significant power in
the domain, add users with caution.

The IIS_WPG group is the Internet
Information Services (IIS) 6.0 worker
process group. Within the
functioning of IIS 6.0 are worker
processes that serve specific
IIS_WPG (installed namespaces. For example,

with IIS) www.microsoft.com is a namespace
served by one worker process,
which can run under an identity
added to the IIS_WPG group, such
as MicrosoftAccount. This group has
no default members.
Servers in this group are permitted

RAS and IAS
access to the remote access No default user rights.
Servers
properties of users.
Members of this group can modify
Schema Admins the Active Directory schema. By
(only appears in default, the Administrator account is

N
the forest root a member of this group. Because
domain) this group has significant power in
the forest, add users with caution.

Schema
 06/06/2011
Schema
The Active Directory schema contains the definitions for all objects in the directory.
Every new directory object you create is validated against the appropriate object
definition in the schema before being written to the directory. The schema is made up
of object classes and attributes. The base (or default) schema contains a rich set of
object classes and attributes to meet the needs of most organizations, and is modeled
after the International Standards Organization (ISO) X.500 standard for directory
services. Because it is extensible, you can modify and add classes and attributes to the
base schema. However, you should carefully consider each change you make, because
extending the schema affects the entire network. For more information, see Extending
the schema.
How directory objects are defined

In the schema, an object class represents a category of directory objects, such as users,
printers, or application programs, that share a set of common characteristics. The
definition for each object class contains a list of the schema attributes that can be used
to describe instances of the class. For example, the User class has attributes such as
givenName, surname, and streetAddress. When you create a new user in the directory
the user becomes an instance of the User class, and the information you enter about the
user becomes instances of the attributes. For more information, see Schema classes and
attributes.
How the schema is stored

Each forest can contain only one schema, which is stored in the schema directory
partition. The schema directory partition, along with the configuration directory
partition, is replicated to all domain controllers in a forest. However, a single domain
controller, the schema master, controls the structure and content of the schema. For
more information about the schema master, see Operations master roles.
Schema cache
To improve performance on schema operations (such as new object validation), each
domain controller holds a copy of the schema in memory (in addition to the copy it
holds on disk). This cached version is automatically updated (after a small time interval)
each time you update the schema. Or, you can reload the updated schema to cache
manually for immediate effect. For more information, see Reload the schema.
Securing the schema

Like every object in Active Directory, schema objects are protected from unauthorized
use by access control lists (ACLs). By default, only members of the Schema Admins
group have write access to the schema. So, to extend the schema you must be a
member of the Schema Admins group. The only default member of the Schema Admins
group is the administrator account in the root domain of the forest. You should restrict
membership in the Schema Admins group because extending the schema improperly
can have serious consequences to your network. For more information, see Access
control in Active Directory and Default groups.
Schema classes and attributes

 06/06/2011
Schema classes and attributes

Every directory object you create is an instance of an object class contained in the
schema. Each object class contains a list of associated attributes that determine the
information the object can contain. Classes and attributes are defined independently, so
that a single attribute can be associated with multiple classes. All schema classes and
attributes are defined by the classSchema and attributeSchema objects, respectively.
Classes
ClassSchema objects are used to define classes in the schema. A classSchema object
provides the template for building directory objects of that class. Examples of
classSchema include User and Server. A classSchema object contains, among other
things, the following information:
 Class type (structural, abstract, or auxiliary)
 Common name and Lightweight Directory Access Protocol (LDAP) display name
 Lists of the "must contain" and "may contain" attributes for instances of the object
 Relative distinguished name attribute
 A list of possible parent classes
Class types
Three different types of classes exist in the schema:
Class type Purpose
Structural Used to instantiate objects (users, servers and so on) in the directory.
Abstract Provides templates for deriving structural classes
Auxiliary Contains predefined lists of attributes that can be included in structural and abstract classes.
Note
 With the Windows Server 2003 family, the inetOrgPerson class is now a part of base
schema. This class can be used as a security principal in the same manner as the user class.
Attributes
AttributeSchema objects are used to define attributes in the schema. An
attributeSchema object determines the allowable contents and syntax for instances of
that attribute in the directory. Examples of attributeSchema include User-Principal-Name
and Telex-Number. An attributeSchema object contains, among other things, the
following information:
 Common name and LDAP display name
 Syntax rules
 Data constraints (single versus multivalued, minimum, and maximum values)
 Whether and how the attribute is indexed
Single and multivalued attributes

Attributes can be single-valued or multivalued. An instance of a single-valued attribute
can can only contain a single value. An instance of a multivalued attribute can contain
multiple values of uniform syntax. A multivalued attribute stores no information about
ordering of the attributes it contains. Each value of a multivalue attribute must be
unique.
Indexed attributes
Both multivalued and single valued attributes can be indexed to help improve the
performance of queries on that attribute. (Indexing does not apply to classes.) Attributes
are marked for indexing based on their schema definition. Indexing an attribute also
allows users to use wildcards (*) as prefixes and suffixes when specifying a search string.
When you mark an attribute as indexed, all instances of the attribute are added to the
index, not just the instances that are members of a particular class. Indexing attributes,
particularly multivalued attributes, can negatively affect replication and object creation
time, as well as directory database size. So, it is recommended that you only index
commonly used attributes. For more information, see Index an attribute in
Schema object names

 06/06/2011
Schema object names

When extending the schema, you need to know how to reference schema objects. Both
class and attribute schema objects can be referenced in several ways:
 Lightweight Directory Access Protocol (LDAP) display name

 common name
 object identifier
LDAP display name

The Active Directory Schema snap-in and other administrative tools display the LDAP
display name of objects. Programmers and system administrators use LDAP display
names to reference objects programmatically. The LDAP display name typically consists
of two or more words combined. When the name consists of multiple words,
subsequent words in the name are identified using capitalization. Example LDAP display
names are mailAddress and machinePasswordChangeInterval. The LDAP display name is
guaranteed to be unique for each object.
Common name
The common name is a more readable version of the LDAP display name. The common
names of the two attributes used in the previous example are SMTP-Mail-Address and
Machine-Password-Change-Interval. Common names are guaranteed to be unique
within a container.
Object identifier
An object identifier (also known as OID) is issued by an issuing authority such as the
International Organization for Standardization (ISO) or the American National Standards
Institute (ANSI). For example, the object identifier for the SMTP-Mail-Address attribute is
1.2.840.113556.1.4.786. Every object identifier must be unique. For more information
about ISO, see the International Organization for Standardization Web site.
When extending your schema, you can register new object identifiers through Microsoft.
For more information, see the Microsoft Web site.
Schema object naming rules

To help standardize schema naming conventions, Microsoft strongly suggests that
schema extensions adhere to naming rules for both the LDAP Display Name and the
Common Name. To qualify as "Certified for Windows," an application that extends the
schema must adhere to these naming rules. For more information, see the Active
Directory chapter of the certification program documentation at the Microsoft Web site.
See also the Active Directory Programmer's Guide at the Microsoft Web site.
Message queuing aliases

A message queuing alias is an object in Active Directory that can be used to reference
queues which might not be listed in Active Directory. For example, a queuing alias can
be used to reference a private queue within the context of a distribution list. You can
create a queuing alias by using Active Directory Users and Computers. Using queuing
aliases provides the following benefits:
 When a queuing alias object is deleted, the alias is automatically removed from all
distribution lists that reference the alias.
 A queue referenced by a queuing alias can be changed without changing the alias.
 Queuing aliases can be used to reference a queue not listed in the directory
service, including private queues or queues from another organization.
 Queuing aliases can be used to send http messages by referencing the destination
queue using a direct format name.
A queuing alias object has a single attribute, a format name that references a queue.
Queuing aliases can contain public, private, and direct format names. The format name
for the queue cannot exceed 255 characters. For more information, see Using Message
Queuing.
Deactivating a class or attribute

 06/06/2011
Deactivating a class or attribute

Domain controllers running Windows Server 2003 do not permit the deletion of classes
or attributes, but they can be deactivated if they are no longer needed or if there was an
error in the original definition. A deactivated class or attribute is considered defunct. A
defunct class or attribute is unavailable for use; however, it is easily reactivated.
If your forest has been raised to the Windows Server 2003 functional level, you can
reuse the object identifier (governsId and attributeId values), the ldapDisplayName, and
the schemaIdGUID that were associated with the defunct class or attribute. This allows
you to change the object identifier associated with a particular class or attribute. The
only exception to this is that an attribute used as a rdnAttId of a class continues to own
its attributeId, ldapDisplayName, and schemaIdGuid values even after being deactivated
(for example, those values cannot be reused).
If your forest has been raised to the Windows Server 2003 functional level, you can
deactivate a class or attribute and then redefine it. For example, the Unicode String
syntax of an attribute called SalesManager could be changed to Distinguished Name.
Since Active Directory does not permit you to change the syntax of an attribute after it
has been defined in the schema, you can deactivate the SalesManager attribute and
create a new SalesManager attribute that reuses the same object identifier and LDAP
display name as the old attribute, but with the desired attribute syntax. You must
rename the deactivated attribute before it can be redefined.
For more information about forest functionality, see Domain and forest functionality.
Notes
 Classes and attributes added to the base schema can be deactivated without
raising the forest functional level. However, they can be redefined only in forests
raised to the Windows Server 2003 functional level or higher.
 Default schema attributes or classes in the base schema cannot be deactivated if

bit 4 of the systemFlags attribute is set to 1. Only attributes or classes where bit 4
of the systemFlags attribute is equal to zero can be deactivated.
Object identifiers must be unique. Mistyping a number when entering an object

identifier can cause a conflict between the invalid object identifier and a legitimate
object identifier that is registered by an application. When installing an application that
adds an attribute or class, the application may need to use the mistyped object identifier
for one of its legitimate schema extensions. You can correct object identifier conflicts in
forests that are set to the Windows Server 2003 functional level. To correct the conflict,
deactivate the attribute or class with the incorrect object identifier. The application
installation program will then be able to create the new attribute or class using the
correct object identifier.
Before deactivating a class, consider the following:

 You can deactivate a class only if that class is not specified as a subClassOf,
auxiliaryClass, systemAuxiliaryClass, possSuperiors, or systemPossSuperiors of any
existing active class.
 You cannot use a defunct class in definitions of new classes, and you cannot add it
to existing class definitions.
 You cannot create objects that are instances of the defunct class or modify existing
instances of the class. However, the instances of the defunct class become
available again for modification when the defunct class is reactivated.
Before deactivating an attribute, consider the following:
 You can deactivate an attribute only if the attribute is not specified as a

systemMustContain, mustContain, systemMayContain, mayContain, or rdnAttId of
any existing active class.
 You cannot use a defunct attribute in definitions of new classes, and you cannot
add it to existing class definitions.
 You cannot read, modify, or delete instances of the defunct attribute present in
existing objects. However, the instances of the defunct attribute become available
when the defunct attribute is reactivated.
 To purge the directory of instances of an attribute you must delete the instances
before deactivating the attribute.
Classes and attributes can be deactivated programmatically (recommended) or by using

the Active Directory Schema snap-in. To deactivate a class or attribute using the Active
Directory Schema snap-in, see Deactivate a class or attribute. For information about
programmatically deactivating classes and attributes, see the Active Directory
Programmer's Guide at the Microsoft Web site.
Reactivating a class
A defunct class can be reactivated. However, a defunct class cannot be reactivated
unless the attributes referenced in its mustContain, systemMustContain, mayContain,
and systemMayContain properties are active and the classes referenced in its
subClassOf, auxiliaryClass, systemAuxiliaryClass, possSuperiors, and
systemPossibleSuperiors properties are also active.
Further, a defunct class cannot be reactivated if the values of the following attributes
collide with an already active attribute or class: ldapDisplayName, attributeId, governsId,
or schemaIdGuid.
To reactive a defunct class, see Reactivate a class or attribute.
Reactivating an attribute
An defunct attribute can be reactivated. However, a defunct attribute cannot be
reactivated if the values of the following attributes collide with an already active
attribute or class: ldapDisplayName, attributeId, governsId, schemaIdGuid, or mapiId.
To reactive a defunct attribute, see Reactivate a class or attribute.
Extending the schema

 06/06/2011
Extending the schema

When the set of classes and attributes in the base Active Directory schema do not meet
your needs, you can extend the schema by modifying or adding classes and attributes.
You should only extend the schema when absolutely necessary. The easiest way to
extend the schema is through the Schema Microsoft Management Console (MMC)
snap-in. You should always develop and test your schema extensions in a test lab before
moving them to your production network.
Before extending the schema

Before extending the schema, review these key points:
Check the base schema first Verify that no existing class or attribute in the base schema meets your application or data
the complete set of classes and attributes in the base schema, see the Microsoft Web site.
Review schema For detailed information about extending the schema, see the Active Directory Programme
documentation at the Microsoft Web site and "Active Directory Schema" at the Microsoft Windows Resou
Web site.
Schema modifications are When you extend the schema, the changes apply to every domain controller in the entire fo
global
Schema classes related to the You cannot modify default system classes (those classes required for Windows to run) with
system cannot be modified schema. However, directory-enabled applications that modify the schema may add new cla
you can modify.
Schema extensions are not Attributes or classes cannot be removed after creation. At best, they can be modified or dea
reversible For more information, see Deactivating a class or attribute.
Obtain valid object Every class and attribute in the schema must have a unique and valid object identifier (also
identifiers OID). Do not create arbitrary object identifiers or recycle old object identifiers. For inform
about obtaining valid object identifiers, see Schema object names.
Document your changes If you do decide to extend the schema, be sure to document your changes.
How to extend the schema

You can modify the schema through graphical user interface (GUI) tools, command-line
tools, and through scripting. The easiest way to modify the schema is by using the
Active Directory Schema snap-in in Microsoft Management Console (MMC), which is a
GUI tool for schema management. For information about installing the Active Directory
Schema snap-in, see Install the Active Directory Schema snap-in. Modifying the schema
through scripting requires programming knowledge and familiarity with the Active
Directory Service Interfaces (ADSI). For more information, see the Active Directory
Programmer's Guide and Extending the Schema at the Microsoft MSDN Web site.
For more information about schema administration tools, see Administration tools for
the Active Directory schema.
For more information about extending the schema, see Modify an existing schema class
or attribute definition and Add a new schema class or attribute definition. For
information about deactivation and reactivation, see Deactivating a class or attribute,
Deactivate a class or attribute and Reactivate a class or attribute.
Using a test forest

A very simple way to avoid damaging or costly schema mistakes in your production
forest is to first test your schema extensions on a test forest. By using a test
environment, you can identify any potential problems in your plan before they affect
your users and your production environment.
After making schema changes in a test forest, you can reinstall the default schema by
demoting each domain controller in the test forest to which the schema changes have
replicated. Then, use the Active Directory Installation Wizard to reinstall Active Directory
on the servers. This procedure is practical only in a test environment.
Sites overview
 06/06/2011
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.
For more information about domains, see Domains.
Replication overview
 06/06/2011
Replication overview
Except for very small networks, directory data must reside in more than one place on the
network to be equally useful to all users. Through replication, the Active Directory®
directory service maintains replicas of directory data on multiple domain controllers,
ensuring directory availability and performance for all users. Active Directory uses a
multimaster replication model, allowing you to make directory changes at any domain
controller, not just at a designated primary domain controller. Active Directory relies on
the concept of sites to help keep replication efficient, and on the Knowledge
Consistency Checker (KCC) to automatically determine the best replication topology for
the network.
Organizing data for replication

Data is stored on each domain controller in the directory store, which is divided logically
into specific directory partitions. Each partition stores a different type of directory data,
either domain data, forest schema data, forest configuration data, or application data.
All domain controllers within a forest hold a replica of the schema and configuration
partitions for that forest, and all domain controllers within a particular domain hold a
replica of the domain partition for their domain. Application directory partitions hold
directory data specific to a particular application and can be stored by domain
controllers belonging to different domains. Changes to each directory partition are
replicated to all other domain controllers that hold a copy of that partition. For more
information, see Directory data store.
Replication also ensures the availability of the global catalog throughout the entire
forest. The global catalog is a searchable directory store containing data about every
object in all domains. The global catalog is stored by domain controllers for which the
global catalog has been enabled. For more information, see Global catalog replication.
Improving replication efficiency with sites

To help make replication more efficient, Active Directory relies on sites. Sites, defined as
groups of well-connected computers, determine how directory data is replicated. Active
Directory replicates directory information within a site more frequently than among
sites. This way, the best connected domain controllers, those most likely to need
particular directory information, receive replicated updates first. The domain controllers
in other sites also receive the changes, but less frequently, reducing network bandwidth
consumption. For more information, see How replication works and Sites overview.
Determining the replication topology

The Knowledge Consistency Checker (KCC), a process running on each domain
controller, automatically identifies the most efficient replication topology for your
network, based on information you provide about your network in Active Directory Sites
and Services. The KCC regularly recalculate the replication topology to adjust for any
network changes that have occurred. The KCC of one domain controller within each site
(the intersite topology generator) determines the intersite replication topology. For
more information about the KCC, see Active Directory Replication Technologies.
Replication enhancements in the Windows
Server 2003 family
The Microsoft® Windows Server 2003 family includes enhancements to make
replication both more efficient, as well as more scalable across a larger number of
domains and sites. These include refinements in memory usage, enhancements to the
Windows 2000 spanning tree algorithm, a completely new spanning tree algorithm for
Windows Server 2003 forests, and a new load balancing tool.
In a forest set to the Windows 2000 functional level, the replication enhancements
provide gains in replication efficiency and scalability, even when sites and domains
contain domain controllers running Windows 2000. If a site contains at least one domain
controller running Windows Server 2003, then a domain controller running Windows
Server 2003 assumes the intersite topology generator role for the site, allowing the
enhancements to take effect.
In a forest set to the Windows Server 2003 functional level, the new Windows
Server 2003 spanning tree algorithm goes into effect for larger gains in both efficiency
and scalability. For example, using the original spanning tree algorithm from
Windows 2000, one domain can contain up to 300 sites. With the new Windows
Server 2003 algorithm, one domain can contain up to at least 3,000 sites. In the new
algorithm, the intersite topology generator in each site uses a randomized selection
process to determine the bridgehead servers for the site. This selection process more
evenly distributes the bridgehead replication workload among domain controllers in a
site, resulting in much better efficiency (particularly in hub sites with a number of
domain controllers). By default, the randomized selection process takes place only when
new connection objects are added to the site. However, a new tool, called adlb.exe, can
be run to rebalance the load each time changes occur in the topology or in the number
of domain controllers in the site. In addition, adlb can stagger schedules so that the
outbound replication load for each server is spread out evenly across time. For more
information about adlb and to download the tool, see the "Windows Server 2003 Active
Directory Branch Office Planning and Deployment Guide."
How replication works

 06/06/2011
How replication works

To keep directory data on all domain controllers consistent and up to date, Active
Directory replicates directory changes on a regular basis. Replication occurs over
standard network protocols, uses change tracking information to prevent unnecessary
replication, and uses linked value replication to improve efficiency.
Transferring replication data

Active Directory uses remote procedure call (RPC) over Internet Protocol (IP) to transfer
replication data between domain controllers. RPC over IP is used for both intersite and
intrasite replication. To keep data secure while in transit, RPC over IP replication uses
both authentication (using the Kerberos V5 authentication protocol) and data
encryption.
When a direct or reliable IP connection is not available, replication between sites can be
configured to use the Simple Mail Transfer Protocol (SMTP). However, SMTP replication
functionality is limited, and requires an enterprise certification authority (CA). SMTP can
only be used to replicate the configuration, schema and application directory partitions,
and does not support the replication of domain directory partitions. For more
information, see "Active Directory Replication" at the Microsoft Windows Resource Kits
Web site.
Preventing unnecessary replication

Once a domain controller has processed a directory change from another domain
controller successfully, it should not try to replicate those changes back to the domain
controller that sent the change. In addition, a domain controller should avoid sending
updates to another domain controller if the target domain controller has already
received that same update from a different replication partner. To prevent such
unnecessary replication, Active Directory uses change tracking information stored in the
directory. For information about change tracking, see "Active Directory Replication" at
the Microsoft Windows Resource Kits Web site.
Resolving conflicting changes

It is possible for two different users to make changes to the exact same object property
and to have these changes applied at two different domain controllers in the same
domain before replication of either change occurs. In such a case, both changes are
replicated as new changes, creating a conflict. To resolve this conflict, domain
controllers that receive these conflicting changes examine the attribute data contained
within the changes, each of which holds a version and a timestamp. Domain controllers
will accept the change with the higher version and discard the other change. If the
versions are identical, domain controllers will accept the change with the more recent
timestamp.
Improving replication efficiency

Introduced in the Windows Server 2003 family, linked value replication allows individual
values of a multivalued attribute to be replicated separately. In Windows 2000, when a
change was made to a member of a group (one example of a multivalued attribute with
linked values) the entire group had to be replicated. With linked value replication, only
the group member that has changed is replicated, and not the entire group. To enable
linked value replication, you must raise the forest functional level to Windows
Server 2003 . For more information about forest functional levels, see Domain and forest
functionality. For more information about multivalued attributes, see Schema.
For more information about how replication works, see "Active Directory Replication" at
Replication within a site

 06/06/2011
Replication within a site

Active Directory handles replication within a site, or intrasite replication, differently than
replication between sites because bandwidth within a site is more readily available. The
Active Directory Knowledge Consistency Checker (KCC) builds the intrasite replication
topology using a bidirectional ring design. Intrasite replication is optimized for speed,
and directory updates within a site occur automatically on the basis of change
notification. Unlike replication data travelling between sites, directory updates replicated
within a site are not compressed.
For information about intersite replication, see Replication between sites and How
replication works.
Building the intrasite replication topology

The Knowledge Consistency Checker (KCC) on each domain controller automatically
builds the most efficient replication topology for intrasite replication, using a
bidirectional ring design. This bidirectional ring topology attempts to create at least two
connections to each domain controller (for fault tolerance) and no more than three hops
between any two domain controllers (to reduce replication latency). To prevent
connections of more than three hops, the topology can include shortcut connections
across the ring. The KCC updates the replication topology regularly.
Note
 The KCC actually creates a separate replication topology for each directory partition
(schema, configuration, domain, application). Within a single site, these topologies are
usually identical for all partitions hosted by the same set of the domain controllers.
Determining when intrasite replication occurs

Directory updates made within a site are likely to have the most direct impact on local
clients, so intrasite replication is optimized for speed. Replication within a site occurs
automatically on the basis of change notification. Intrasite replication begins when you
make a directory update on a domain controller. By default, the source domain
controller waits 15 seconds and then sends an update notification to its closest
replication partner. If the source domain controller has more than one replication
partner, subsequent notifications go out by default at 3 second intervals to each partner.
After receiving notification of a change, a partner domain controller sends a directory
update request to the source domain controller. The source domain controller responds
to the request with a replication operation. The 3 second notification interval prevents
the source domain controller from being overwhelmed with simultaneous update
requests from its replication partners.
For some directory updates in a site, the 15 second waiting time does not apply and
replication occurs immediately. Known as urgent replication, this immediate replication
applies to critical directory updates, including the assigning of account lockouts and
changes in the account lockout policy, the domain password policy, or the password on
a domain controller account.
For more information about intrasite replication, see "Active Directory Replication" at
When to establish a single or

separate sites
 06/07/2011
When to establish a single or separate sites

You can optimize the replication efficiency and reduce the administrative overhead of
your network by establishing sites appropriately. The most effective number of sites
depends on the physical design of your network. When you first create a new forest, a
single, default Active Directory site (called Default-Site-First-Name) is created that
represents your entire network. A forest or domain consisting of a single site can be very
efficient for a single location network connected completely by high-speed bandwidth.
If your forest or domain contains multiple geographic locations that communicate over
low-speed wide area network (WAN) connections, establishing multiple sites gives you
more detailed control of replication behavior, reduces authentication latency, and
reduces network traffic on the WAN.
For information about sites, see Sites overview.
For information about designing a site topology, see "Designing the Site Topology" at
Why bandwidth is important

Within a site, bandwidth affects how efficiently replication can work. The frequency with
which intrasite replication occurs requires high-speed bandwidth to function most
effectively. So before you a create new site, you should make sure that high-speed
bandwidth connects all computers within the site candidate. Any area where domain
controllers are connected by 10 megabits per second (Mbps) or more of bandwidth is a
good site candidate.
When to establish a single site

If you have a single LAN consisting of a single subnet, or if your network contains
multiple subnets connected by a high-speed backbone, establishing a single site
replication topology can provide the following benefits:
 Simplified replication management
 Prompt directory updates between all domain controllers
A single site topology allows all replication on your network to occur as intrasite
replication, which requires no manual replication configuration. A single site design also
allows all domain controllers to remain very current with respect to directory changes,
because directory updates are replicated almost immediately. For more information, see
Replication within a site. For information about creating sites, see Create a site.
When to establish multiple sites

When your network consists of multiple geographic locations connected by a WAN,
establishing separate sites for each location provides the following benefits:
 Efficient use of WAN bandwidth for replication
 Detailed control of replication behavior
 Reduction in authentication latency
Physically separate network locations typically communicate over WAN connections,

which are most often characterized by low-speed bandwidth. By creating a separate site
for each physical location on your network, you ensure that domain controllers
communicating over WAN connections use intersite replication, which is specifically
designed for efficiency on low bandwidth connections. For more information, see
Replication between sites.
With multiple sites, you have more detailed control of replication behavior through
several configurable intersite replication settings. These settings include the relative cost
of different replication paths, the domain controllers associated with each site, the
subnets associated with each site, the frequency of directory update transfers, and the
availability of connections for use by replication. For more information, see Managing
replication.
A network client logging on to a domain must contact a domain controller as part of the
authentication process, first looking within its own site. If the site includes two or more
physically separate network locations, the client may authenticate against a domain
controller across a WAN connection. Authentication across a WAN introduces a delay in
the authentication process. By placing physically separate network locations into
separate Active Directory sites, you can ensure that clients first attempt to authenticate
against a domain controller in their own site.
Managing replication
 06/06/2011
Managing replication
Active Directory relies on site configuration information to manage and optimize the
process of replication. Active Directory provides automatic configuration of these
settings in some cases. In addition, you can configure site-related information for your
network using Active Directory Sites and Services. Configurable information includes
settings for site links, site link bridges, and bridgehead servers.
Configuring site links

You can use site link settings to control replication between sites. Configurable settings
include the relative cost of each site link, the frequency of replication on each site link,
and the schedule availability of each site link for replication. For information about site
links, see Replication between sites.
Site link cost

The cost of a site link determines the relative preference of the Active Directory
Knowledge Consistency Checker (KCC) for using a site link in the replication topology.
The higher the cost of the site link, the lower will be the KCC's preference for using the
site link. For example, if you have two site links, site link A and site link B, and you set
the cost of site link A to 150 and the cost of site link B to 200, the KCC will prefer to use
site link A in the replication topology. By default, the cost of a newly created site link is
100. For information about setting site link cost, see Configure site link cost. For
information about the KCC, see Replication overview.
Replication frequency
The replication frequency of a site link determines how often replication occurs over that
site link. By default, the replication frequency for a site link is 180 minutes, meaning that
replication occurs over that site link every 180 minutes, or three hours. Using Active
Directory Sites and Services, you can set the replication frequency from 15 minutes to
10,080 minutes (one week). A site link must be available for any replication to occur. If a
site link is not available when the number of minutes between replication updates has
passed, no replication will occur. For more information, see Configure site link
replication frequency.
Site link availability

The availability schedule for a site link determines during which hours or days of the
week a site link can be used for replication. By default, a site link is always available for
replication, 24 hours a day and 7 days a week. You can change this schedule, for
example, to exclude business hours during which your network is busy handling other
types of traffic. Or, you can exclude particular days on which you do not want replication
to occur. Scheduling information is ignored by site links that use the Simple Mail
Transfer Protocol (SMTP) for replication. For more information, see Configure site link
replication availability.
Configuring site link bridges

By default, all site links are bridged, or transitive. This allows any two sites that are not
connected by an explicit site link to communicate directly, through a chain of
intermediary site links and sites. One advantage to bridging all site links is that your
network is easier to maintain because you do not need to create a site link to describe
every possible path between pairs of sites.
Generally, you can leave automatic site link bridging enabled. However, you might want
to disable automatic site link bridging and create site link bridges manually just for
specific site links, in the following cases:
 Your network is not fully routed (not every domain controller can directly
communicate with every other domain controller).
 You have a network routing or security policy in place that prevents every domain
controller from being able to directly communicate with every other domain
controller.
 Your Active Directory design includes a large number of sites. For more
information, see the Active Directory Branch Office Planning Guide at the Microsoft
Web site.
For more information about site link bridges and their affects on replication, see "Active
Directory Replication" at the Microsoft Windows Resource Kits Web site.
For information about disabling automatic site link bridging, see Enable or disable site
link bridges.
For information about creating a site link bridge manually, see Create a site link bridge.
Configuring preferred bridgehead servers

When the KCC constructs the intersite replication topology, it automatically assigns one
or more bridgehead servers for each site to ensure that directory changes only need to
be replicated across a site link one time. It is recommended that you allow the KCC to
make the bridgehead server assignments. You can make the bridgehead server
assignments manually through Active Directory Sites and Services. However, doing so
can potentially disrupt replication if one of your manually assigned bridgehead servers
becomes unavailable. For more information, see "Active Directory Replication" at the
Microsoft Windows Resource Kits Web site.
The role of the global catalog

 06/06/2011
The role of the global catalog

A global catalog is a domain controller that stores a copy of all Active Directory objects
in a forest. The global catalog stores a full copy of all objects in the directory for its host
domain and a partial copy of all objects for all other domains in the forest, as shown in
the following figure.
The partial copies of all domain objects included in the global catalog are those most
commonly used in user search operations. These attributes are marked for inclusion in
the global catalog as part of their schema definition. Storing the most commonly
searched upon attributes of all domain objects in the global catalog provides users with
efficient searches without affecting network performance with unnecessary referrals to
domain controllers.
You can manually add or remove other object attributes to the global catalog by using
the Active Directory Schema snap-in. For more information, see Customizing the global
catalog.
A global catalog is created automatically on the initial domain controller in the forest.
You can add global catalog functionality to other domain controllers or change the
default location of the global catalog to another domain controller. For more
information, see Enable or disable a global catalog.
A global catalog performs the following directory roles:
 Finds objects
A global catalog enables user searches for directory information throughout all
domains in a forest, regardless of where the data is stored. Searches within a forest
are performed with maximum speed and minimum network traffic.
When you search for people or printers from the Start menu or choose the Entire
Directory option within a query, you are searching a global catalog. Once you enter
your search request, it is routed to the default global catalog port 3268 and sent to
a global catalog for resolution. For more information, see Finding directory
information and "Finding information in Active Directory" at the Microsoft
Windows Resource Kits Web site.
 Supplies user principal name authentication
A global catalog resolves user principal names (UPNs) when the authenticating
domain controller does not have knowledge of the account. For example, if a
user’s account is located in example1.microsoft.com and the user decides to log on
with a user principal name of user1@example1.microsoft.com from a computer
located in example2.microsoft.com, the domain controller in
example2.microsoft.com will be unable to find the user’s account, and will then
contact a global catalog to complete the logon process. For more information, see
Active Directory naming.
 Supplies universal group membership information in a multiple domain

environment
Unlike global group memberships, which are stored in each domain, universal
group memberships are only stored in a global catalog. For example, when a user
who belongs to a universal group logs on to a domain that is set to the
Windows 2000 native domain functional level or higher, the global catalog
provides universal group membership information for the user’s account at the
time the user logs on to the domain.
If a global catalog is not available when a user logs on to a domain set to the
functional level of Windows 2000 native or higher, the computer will use cached
credentials to log on the user if the user has logged on to the domain previously. If
the user has not logged on to the domain previously, the user can only log on to
the local computer. However, if a user logs on as the Administrator in the domain
(Builtin Administrator account), the user can always log on to the domain, even
when a global catalog is not available.
For more information about universal groups, see Group scope. For more
information about universal groups and replication, see Global catalog replication
and Global catalogs and sites.
Note
o When there is only one domain in a forest, it is not necessary for users to obtain
universal group memberships from a global catalog when logging on. This is because
Active Directory can detect that there are no other domains in the forest and will
prevent a query to the global catalog for this information.
 Validates object references within a forest
A global catalog is used by domain controllers to validate references to objects of

other domains in the forest. When a domain controller holds a directory object
with an attribute containing a reference to an object in another domain, this
reference is validated using a global catalog.
Global catalogs and sites

 06/06/2011
Global catalogs and sites

To optimize network performance in a multiple site environment, consider adding
global catalogs for select sites. In a single site environment, a single global catalog is
usually sufficient to cover common Active Directory queries. The following table will help
you determine whether your multiple site environment will benefit using additional
global catalogs.
Use a global catalog when Advantage Disadvant
A commonly used application in the site utilizes port 3268 to resolve global catalog Performance Additional
queries. improvement traffic due
replication
A slow or unreliable WAN connection is used to connect to other sites. Use the same Fault tolerance Additional
failure and load distribution rules that you used for individual domain controllers to traffic due
determine whether additional global catalog servers are necessary in each site. replication
Users in the site belong to a Windows 2000 domain running in native mode. In this Fast user logons Additional
case, all users must obtain universal group membership information from a global traffic due
catalog server. If a global catalog is not located within the same site all logon requests replication
must be routed over your WAN connection to a global catalog located in another site.
If a domain controller running Windows Server 2003 in the site has universal group
membership caching enabled, then all users will obtain a current cached listing of their
universal group memberships.
Note
 Network traffic related to global catalog queries generally use more network resources
than normal directory replication traffic.
Universal group membership caching

Due to available network bandwidth and server hardware limitations, it may not be
practical to have a global catalog in smaller branch office locations. For these sites, you
can deploy domain controllers running Windows Server 2003, which can store universal
group membership information locally.
Information is stored locally once this option is enabled and a user attempts to log on
for the first time. The domain controller obtains the universal group membership for
that user from a global catalog. Once the universal group membership information is
obtained, it is cached on the domain controller for that site indefinitely and is
periodically refreshed. The next time that user attempts to log on, the authenticating
domain controller running Windows Server 2003 will obtain the universal group
membership information from its local cache without the need to contact a global
catalog.
By default, the universal group membership information contained in the cache of each
domain controller will be refreshed every 8 hours. To refresh the cache, domain
controllers running Windows Server 2003 will send a universal group membership
confirmation request to a designated global catalog. Up to 500 universal group
memberships can be updated at once. Universal group membership caching can be
enabled using Active Directory Sites and Services. Universal group membership caching
is site specific and requires that all domain controllers running Windows Server 2003 be
located in that site to participate. For more information about how to enable this option,
see Cache universal group memberships.
The following list summarizes potential benefits for caching universal group
memberships in branch office locations:
 Faster logon times since authenticating domain controllers no longer need to

access a global catalog to obtain universal group membership information.
 No need to upgrade hardware of existing domain controllers to handle the extra

system requirements necessary for hosting a global catalog.
 Minimized network bandwidth usage since a domain controller will not have to
handle replication for all of the objects located in the forest.
Note
 You might want to continue using a global catalog in branch office locations if an
application in a site is sending global catalog queries to port 3268. Universal group
membership caching does not intercept calls made to port 3268.
DNS integration
 06/06/2011
DNS integration
Active Directory is integrated with DNS in the following ways:
 Active Directory and Domain Name System (DNS) have the same hierarchical
structure.
Although separate and implemented differently for different purposes, an

organization's namespace for DNS and Active Directory have an identical structure.
For example, microsoft.com is a DNS domain and an Active Directory domain. For
more information, see Namespace planning for DNS.
 DNS zones can be stored in Active Directory.
If you are using the Windows Server 2003 DNS Server service, primary zone files
can be stored in Active Directory for replication to other Active Directory domain
controllers. For more information, see Active Directory integration.
 Active Directory uses DNS as a locator service, resolving Active Directory domain,
site, and service names to an IP address.
To log on to an Active Directory domain, an Active Directory client queries their

configured DNS server for the IP address of the LDAP service running on a domain
controller for a specified domain. For more information about how Active Directory
clients rely on DNS, see Locating a domain controller.
Note
 You can use Dcdiag.exe and Netdiag.exe to troubleshoot client computers that cannot
locate a domain controller. These tools can help determine both server and client DNS
misconfigurations. For more information, see article Q265706, "DCDiag/NetDiag Facilitate
Join and DC Creation" in the Microsoft Knowledge Base. For a brief description of support
tools, see Active Directory support tools.
While Active Directory is integrated with DNS and shares the same namespace structure,
it is important to distinguish the difference between them:
 DNS is a name resolution service.
DNS clients send DNS name queries to their configured DNS server. The DNS
server receives the name query and either resolves the name query through locally
stored files or consults another DNS server for resolution. DNS does not require
Active Directory to function.
 Active Directory is a directory service
Active Directory provides an information repository and services to make

information available to users and applications. Active Directory clients send
queries to domain controllers using the Lightweight Directory Access Protocol
(LDAP). In order to locate a domain controller, an Active Directory client queries
DNS. Active Directory requires DNS to function.
For a checklist on deploying DNS for Active Directory, see Checklist: Deploying DNS for
Active Directory.
For information about configuring DNS servers for Active Directory, see Configure a
DNS server for use with Active Directory.
Group Policy integration

 06/06/2011
Group Policy integration

Group Policy can be used to define default settings that will be automatically applied to
user and computer accounts in Active Directory. Policy settings can be used to manage
desktop appearance, assign scripts, redirect folders from local computers to network
locations, determine security options and control what software can be installed on
particular computers and what software is available to particular groups of users.
Here are a few examples of how Group Policy settings can be used in Active Directory:
 Set the minimum password length and the maximum length of time that a
password will remain valid. This can be configured for an entire domain.
 Administrators can automatically install an application on every computer in a
particular domain or on all computers assigned to a particular group in a particular
site. For example, you could automatically install Microsoft Outlook on every
computer in the domain and automatically install Microsoft Excel only on those
computers belonging to the Accounting group in a particular site.
 Logon, logoff, startup, and shutdown scripts can be assigned based on the
locations of the computer and user accounts in Active Directory.
 If members of a particular group often use different computers, administrators can

install the necessary applications on each of those computers.
 Any user's My Documents folder can be redirected to a network location. Users can
then gain access to their documents from any computer on the network.
Policy settings are stored in Group Policy objects. Group Policy settings from more than
one Group Policy object can be applied to a particular site, domain, or organizational
unit. For example, if a site contains three domains, one Group Policy object could
control computer configurations for the entire site. A separate policy for each domain
could determine specific security settings for the computers in each domain. If each
domain contains an Accounting and a Marketing organizational unit, additional Group
Policy objects could determine what software is installed on the computers used by the
Accounting and Marketing groups throughout the entire site.
This ability to automatically configure and secure computers throughout your

organization by selectively applied Group Policy objects is a very powerful
administrative tool. For more information about controlling software installation with
Group Policy and how to create a Group Policy object, see Group Policy (pre-GPMC).
You can use security groups to filter how Group Policy settings are applied to collections
of users and computers belonging to a particular site, domain, or organizational unit.
For more information about security groups, see Group types. For general information
about Group Policy, see Group Policy overview.

Active Directory Structure

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Active Directory Structure

Загружено:

Авторское право:

Доступные форматы

Active Directory Structure and Storage

single directory and represents a security boundary. Forests contain domains.

are stored in the directory.

retrieval of data on each domain controller.

Active Directory Data Structure and Storage Architecture

replication topology can be established and network bandwidth is not wasted by

logical structure architecture.

Logical Structure Architecture

principal Active Directory operations, such as authentication, updating, or searching, is

when a network user with an Active Directory user account logs on to an

To log on to a network that consists of an Active Directory forest, a client workstation

workstation to locate a domain controller.

Active Directory Schema

controllers use the same object definition.

Active Directory Data Store

directory services to directory clients. These components include the following:

o Lightweight Directory Access Protocol (LDAP)

o Replication (REPL) and domain controller management interface

o Messaging API (MAPI)

 Three service components:

o Directory System Agent (DSA)

o The database layer

o Extensible Storage Engine (ESE)

 The directory database where the data is actually stored

Data Store Architecture

Active Directory Structure and Storage Components

others are defined by the system and cannot be modified.

object definitions include two primary components: classSchema objects and

as a single file on the hard disk of each domain controller.

Active Directory Domains and Forests

The logical structure of Active Directory is a hierarchical structure of Active Directory

Active Directory logical structure are described in the following table.

Domain and Forest Components

A forest is the highest level of the logical structure hierarchy. An

Active Directory forest represents a single self-contained directory. A

forest is a security boundary, which means that administrators in a forest

smaller portions so that the information can be more easily stored on

various domain controllers and so that administrators have a greater

degree of control over replication. Data that is stored in the directory is

replicated throughout the forest from one domain controller to another.

replicated only to domain controllers in that particular domain. A good

domain design makes it possible to implement an efficient replication

topology. This is important because it enables administrators to manage

replicated and where that replication traffic takes place.

OUs provide a means for administrators to group resources, such as user

accounts or computer accounts, so that the resources can be managed as

computers or to control the access of many users to a single resource.

OUs also make it easier to delegate control over resources to various

DNS Support for Active Directory

in DNS, and Active Directory DNS objects.

clients locate nearby domain controllers.

Active Directory DNS Support Components

Locator, which is implemented in the Net Logon service,

enables a client to locate a domain controller. Locator

Locator contains Internet Protocol (IP)/DNS–compatible and

Windows NT 4.0–compatible locators, which provide

interoperability in a mixed Active Directory environment.

Every Active Directory domain has a DNS domain name (for

server1.cohovineyard.com). Architecturally, domains and

computers are represented both as objects in Active Directory

and as nodes in DNS.

When DNS data is stored in Active Directory, each DNS zone

is an Active Directory container object (class dnsZone). The

a dnsRecord multivalued attribute that contains a value for