Vous êtes sur la page 1sur 133

Microsoft Student Technical Services

Microsoft India GTSC

INTRODUCTION
TO
MICROSOFT ACTIVE DIRECTORY
DOMAIN SERVICES (AD DS)
OPEN ELECTIVE – 45 HOURS
Module 1: Introduction to Microsoft Active Directory
What is a Directory?

What is Microsoft Active Directory?

What is LDAP?

Roles of Active Directory Server

Features in AD DS

Common Terminologies and AD Concepts

- Forest
- Domain
- Domain Controller
- Global Catalog
- Forest Root Domain
- Child Domain
- Domain Tree
- Active Directory and DNS
- Active Directory Schema
- Active Directory Objects
- Distinguished Name
- Relative Distinguished Name
- Organizational Units
- Administrative Hierarchy
- Group Policy
- Authentication and Authorization
- Access Control
- Delegation of Administration
- Inheritance
- More about Domain Controller Servers
- Multimaster Operations
- More About Global Catalog Servers
- Global Catalog Attributes
- Designating a Global Catalog
- Global Catalog and Domain Logon Support
- Universal Group Membership
- User Principal Name and Global Catalog Logon Support
- Search Requests and Global Catalog
- Name Resolution in Active Directory
- Operation Master Roles
- Understanding Sites, Subnets and Site Links
Active Directory Structure and Storage Technologies

- Active Directory Structure and Storage Architecture


- Active Directory Domains and Forests
- DNS Support for Active Directory
- Active Directory Schema
- Active Directory Data Store
- AD Structure and Storage Components
- Domain and Forest Components
- Active Directory DNS Support Components
- Active Directory Schema Components
- Data Store Components

References

Module 2: Active Directory Domains and Forests – Deep Dive.


The Logical Structure of Active Directory

- Benefits of the Logical Structure


- Components of the Logical Structure

The Physical Structure of Active Directory

- What are Domains


- Domains as containers within a forest
- Organizational Units and Objects
- Domains as units of policy
- Domains as units of replication
- Domain Controllers
- Sites
- Domain-wide Operations Masters
- Domains as Authentication and Authorization Boundaries
- Domains as Units of Trust
- What Domains are Not
- What are Forests
- Forests as Collections of Domain Controllers that Trust each other
- Forest Root Domain
- Tree Root Domain
- Forests as Units of Replication
- Forest-wide directory Partitions
- Forest-wide Operation Master Roles
- Sites
- Global Catalogs
- Forests as Security Boundaries
- Forests as Units of Delegation

Network Ports Used by Domains and Forests

- Port Assignments for Raising Active Directory Functional Levels


- Ports Assignments for Data Store
- Port Assignments for Service Publication and SPNs
- Port Assignments for Raising Active Directory Searches
- Port Assignments for Global Catalogs
- Port Assignments for Replication
- Port Assignments for Operations Master
- Port Assignments for Interactive Logon
- Port Assignments for Kerberors V5 Protocol
- Port Assignment for DC Locator
- Ports Required for Trusts

References

Module 3: Install Active Directory Domain Services in Windows 2008 R2


Requirements for installing AD DS

Steps for installing AD DS

Steps for uninstalling AD DS

Understanding Active Directory Domain Services Functional Levels

- Domain Functional Levels


- Forest Functional Levels
- Guidelines for raising domain and forest functional levels

References

Lab / Assessments:

- Install an AD DS DC, and explore the concepts learnt so far

Module 4: Active Directory Administration


Introduction to various AD Snap-ins and their functions

Active Directory Users and Computers

- Managing Users
- Managing Groups
- Managing Computer Accounts
- Managing Domains
- Managing Organizational Untis

Active Directory Domains and Trusts


- Raise Domain Functional Levels
- Raise Forest Functional Levels
- Managing Domain Trusts
- Managing Forest Trusts

Active Directory Sites and Services

- Create a Site
- Create a Subnet
- Create a Site Link
- Add/Remove site from a Site Link
- Configure Intersite Replication Schedule (Availability / Frequency)
- Add/Remove Global Catalog

ADSI Edit

Schema Manager

Group Policy Management Console

References

Labs:

- Create Users, Groups, Computer Accounts and OUs and explore concepts learnt so far
- Explore the Physical components of AD

Module 5: Backup/Restore of Active Directory


Backing Up Active Directory Domain Services

- Windows Server Backup Tools


- Windows Server Backup Types
- Contents of Windows Server Backup Types
- Criteria for using backup types
- Backup guidelines
- Scheduling regular backups
- Immediate backup
- Backup frequency
- Backup frequency criteria

Recovering Active Directory Domain Services

- Causes of disruption
- Key to protect against disruptions
- Preventing unwanted deletions
- Recovery solutions
- Nonauthoritative restore
- Authoritative restore
- Restoring group memberships
- Methods of authoritative restore
- Recovery options with no available backup
- Solutions for hardware failure or file corruption
- Reinstalling and restoring criteria
- Restoring AD DS after reinstalling the operating system

References

Labs / Assessments:

- Backup
- Restore
Module 1: Introduction to Microsoft Active Directory
What is a Directory?
A directory, in the most generic sense, is a comprehensive listing of objects. A phone book is a type
of directory that stores information about people, businesses, and government organizations. Phone
books typically record names, addresses, and phone numbers.

What is a Directory Service?

The directory service is a database with multiple data partitions, as well as the processes to
maintain, manage, and secure the database. Essentially a Network Directory Service

- Provides information about the user objects, computers and services in the network.
- Stores this information in a secure database and provides tools to manage and search the
directory.
- Allows to manage the user accounts and resources, apply policies consistently as needed by
an organization.

What is Microsoft Active Directory?


Active Directory is Microsoft’s implementation of a Directory Service. Active Directory Domain
Services (AD DS) defines the data structure and services that provide organization, management,
and security of accounts and resources in a Microsoft network.

AD DS is similar to a phone book in several ways, and it is far more flexible. AD DS will store
information about organizations, sites, computers, users, shares, and just about any other network
object that you can imagine. Not all objects are as similar to each other as those stored in the phone
book, so AD DS includes the ability to record different types of information about different objects.

Domain controllers host and replicate the directory service database inside the forest. The directory
service also provides services for managing and authenticating resources in the forest.

What is Lightweight Directory Access Protocol (LDAP)?


AD DS reflects Microsoft's trend toward relying on standard protocols. The Lightweight Directory
Access Protocol (LDAP) is a product of the IETF (Internet Engineering Task Force). It defines how
clients and servers exchange information about a directory. LDAP version 2 and version 3 are used in
AD DS.

What is the role of an AD DS Server?


- AD DS provides a distributed database that stores and manages information about network
resources and application-specific data from directory-enabled applications.
- Administrators can use AD DS to organize elements of a network, such as users, computers,
and other devices, into a hierarchical containment structure.
- The hierarchical containment structure includes the AD DS forest, domains in the forest, and
organizational units (OUs) in each domain.
- A server that is running AD DS is called a domain controller.
Organizing network elements into a hierarchical containment structure provides the following
benefits:

- The forest acts as a security boundary for an organization and defines the scope of authority
for administrators. By default, a forest contains a single domain, which is known as the
forest root domain.
- Additional domains can be created in the forest to provide partitioning of AD DS data, which
enables organizations to replicate data only where it is needed. This makes it possible for AD
DS to scale globally over a network that has limited available bandwidth. An AD DS domain
also supports a number of other core functions that are related to administration, including
network-wide user identity, authentication, and trust relationships.
- OUs simplify the delegation of authority to facilitate the management of large numbers of
objects. Through delegation, owners can transfer full or limited authority over objects to
other users or groups.
- Delegation is important because it helps to distribute the management of large numbers of
objects to a number of people who are trusted to perform management tasks.

Features in AD DS
Security is integrated with AD DS through logon authentication and access control to resources in
the directory. With a single network logon, administrators can manage directory data and
organization throughout their network. Authorized network users can also use a single network
logon to access resources anywhere in the network. Policy-based administration eases the
management of even the most complex network.

Additional AD DS features include the following:

- A set of rules, the schema, that defines the classes of objects and attributes that are
contained in the directory, the constraints and limits on instances of these objects, and the
format of their names.
- A global catalog that contains information about every object in the directory. Users and
administrators can use the global catalog to find directory information, regardless of which
domain in the directory actually contains the data.
- A query and index mechanism, so that objects and their properties can be published and
found by network users or applications.
- A replication service that distributes directory data across a network. All writable domain
controllers in a domain participate in replication and contain a complete copy of all directory
information for their domain. Any change to directory data is replicated to all domain
controllers in the domain.
- Operations master roles (also known as flexible single master operations or FSMO). Domain
controllers that hold operations master roles are designated to perform specific tasks to
ensure consistency and eliminate conflicting entries in the directory.
Common Terminologies and Active Directory Concepts
Let us now start understanding some terminologies involved in the world of Active Directory Domain
Services.

Forest

An Active Directory forest contains all the domains, sites, and trusts that are part of Active Directory
Domain Services (AD DS). The forest acts as a security boundary for an organization, and it defines
the scope of authority for administration. By default, a forest contains a single domain, which is
called the forest root domain.

Domain

A domain is a distinct unit of administration and resource grouping in Active Directory Domain
Services (AD DS).

Domain Controller

Domain controllers are servers that host Active Directory Domain Services (AD DS) resources. These
servers host essential services in AD DS, including the following:

- Kerberos Key Distribution Center (kdc)


- NetLogon (Netlogon)
- Windows Time (W32time)
- Intersite Messaging (IsmServ)
- File Replication (ntfrs): required if the forest functional level is lower than Windows Server
2008 or if an upgraded forest is at the Windows Server 2008 functional level and Distributed
File System Replication (DFSR) is not yet configured
- Distributed File System (Dfs): if the forest functional level is Windows Server 2008 and DFSR
is in use

In addition, domain controllers host the SYSVOL share. Domain controllers must register Domain
Controller Locator (DC Locator) records with Domain Name System (DNS) so that domain member
computers can locate resources on the domain.

Global Catalog

The global catalog is a distributed data repository that facilitates searches and logons in an Active
Directory forest. The Active Directory replication system builds global catalog data automatically.

One or more domain controllers in an Active Directory forest host the global catalog. The domain
controllers that host the global catalog are called global catalog servers.

Users and applications can use the global catalog to locate objects in any domain in the forest by
searching for an attribute of the object. For example, an administrator can use the global catalog to
search for a user's last name to locate that user's account in the forest. A user can also use the global
catalog to search the forest for a list of printers that are organized by location.

The global catalog facilitates logons by ensuring that membership in universal groups from all
domains is represented in the user's access credentials (also known as the access token).

Forest Root Domain

The first domain that is installed in an Active Directory Forest is referred to as the root domain.
Child Domain

Child Domains are subsequent domains installed within an AD forest, with a contiguous name space
to an existing domain in the AD. Eg: if root.com is the root domain of the forest, child.root.com is the
child domain in the forest.

Figure 1-1: Example of a Domain Hierarchy

Domain Tree

Domain Trees are groups of domains in the same contiguous name space. One forest can have
multiple trees, and one tree has one set of parent and child domains.

Figure 1-2: Example of a Forest having two Domain Trees


Putting it all together, here is how the Domains, Trees look inside a forest.

Forest – Tree.com

(Forest Root
Domain)

Tree.com

Tree1

Tree2

Tree1.com

Tree2.com

Child1.Tree1.com

Child1.Tree2.com

Child2.Child1.Tree1.com

Child2.Child1.Tree2.com

Figure 1-3: A Simple Active Directory Forest.


Active Directory and DNS

DNS is the de facto naming system for IP-based networks and the naming service that is used to
locate computers on the Internet. Active Directory uses DNS to locate computers and domain
controllers (that is, to locate Active Directory). A workstation or member server finds a domain
controller by querying DNS.

Active Directory Schema

In Active Directory the schema contains definitions for the universe of objects that can be stored in
the directory, and it enforces the rules that govern both the structure and the content of the
directory. The schema consists of a set of classes, attributes, and syntaxes that represent an instance
of one or more classes in the schema.

- A class is a category of objects that share a set of common characteristics. It is a formal


description of a discrete, identifiable type of object that can be stored in the directory. Each
object in the directory is an instance of one or more classes in the schema.
- An attribute describes the characteristics of some aspect of an object. Attributes define the
types of information that an object can hold.
- For each class, the schema specifies the mandatory attributes and optional attributes that
constitute the set of shared characteristics of the class.
- The values assigned to attributes define specific characteristics.
- A syntax is the data type of a particular attribute. Syntaxes determine what data type an
attribute can have. Active Directory uses a set of standard syntaxes. The predefined syntaxes
do not actually appear in the directory, and you cannot add new syntaxes.
- An everyday example of an object is a vehicle, which can belong to the class of trucks, the
class of motorcycles, or the class of cars, and so forth. A car can be described by its make,
model, and color. These are some of the attributes of the car. In the example of the car, the
possible values for the color of the car might be red, blue, or gray. The syntax for color might
be the nomenclature (such as 2B1R2Y) that denotes specific combinations of primary colors
that comprise what one sees as the colors of automotive paints.

The schema specifies the relationships between classes of objects. Each object stored in the
directory is an instance of one or more classes in the schema. User,Computer, and printQueue are
examples of classes in Active Directory. For example, if the schema contains a class called User, the
user accounts, Sue and Mary, are two objects in the directory that are instances of the class User.
The object Mary might contain an optional attribute defined for this class called phoneNumber. This
attribute for the object Mary of the class User might have the value 555-0100.

For example, the attribute phoneNumber can be defined to take values of the syntax String
(numeric), which means that the value can contain only the digits 0 through 9.

The schema itself is represented in Active Directory by a set of objects known as "schema objects."
For each class in the schema, there is a schema object that defines the class. This object is called a
classSchema object. For each attribute in the schema, there is also a schema object that defines the
attribute. This object is called an attributeSchema object. Therefore, every class is actually an
instance of the classSchema class, and every attribute is an instance of the attributeSchema class.
Storing the schema in the directory has many advantages. One example is that when user
applications locate the schema in the directory, they can read the schema to discover what types of
objects and properties are available.
Administrators and applications can extend the schema by adding new attributes and classes or by
modifying existing ones. Schema definitions are required by applications that need to create or
modify objects in Active Directory. Applications that are "directory-enabled" are programmed to
recognize the attributes and syntaxes that are required to interact with the directory.

Active Directory Objects

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

When you create an object in Active Directory, you provide values for the attributes of the object in
its particular class, and you do so according to the rules of the directory schema. For example, when
you create a user object, you provide alphanumeric values for the user's first and last names, the
logon identifier, and perhaps other values, such as telephone number and address. You cannot
create the user object successfully without providing acceptable values for the user name and logon
name because these attributes are mandatory, according to the directory schema.

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

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

Distinguished Name

Objects are located within Active Directory domains according to a hierarchical path, which includes
the labels of the Active Directory domain name and each level of container objects. The full path to
the object is defined by the distinguished name (also known as a "DN"). The name of the object
itself, separate from the path to the object, is defined by the relative distinguished name.

The distinguished name is unambiguous (identifies one object only) and unique (no other object in
the directory has this name). By using the full path to an object, including the object name and all
parent objects to the root of the domain, the distinguished name uniquely and unambiguously
identifies an object within a domain hierarchy. It contains sufficient information for an LDAP client to
retrieve the object's information from the directory.

For example, a user named James Smith works in the marketing department of a company as a
promotions coordinator. Therefore, his user account is created in an organizational unit that stores
the accounts for marketing department employees who are engaged in promotional activities. James
Smith's user identifier is JSmith, and he works in the North American branch of the company. The
root domain of the company is reskit.com, and the local domain is noam.reskit.com. The diagram in
Figure 1-4, illustrates the components that make up the distinguished name of the user object
JSmith in the noam.reskit.com domain.

Figure 1-4: Distinguished Name Example

Relative Distinguished Name

The relative distinguished name (also known as the "RDN") of an object is the part of the name that
is an attribute of the object itself — the part of the object name that identifies this object as unique
from its siblings at its current level in the naming hierarchy. In Figure 1.10, in the preceding section,
the relative distinguished name of the object is JSmith. The relative distinguished name of the parent
object is Users. The maximum length allowed for a relative distinguished name is 255 characters, but
attributes have specific limits imposed by the directory schema. For example, in the case of the
common name, which is the attribute type often used for naming the relative distinguished name
(cn), the maximum number of characters allowed is 64.

Active Directory relative distinguished names are unique within a specific parent — that is, Active
Directory does not permit two objects with the same relative distinguished name under the same
parent container. However, two objects can have identical relative distinguished names but still be
unique in the directory because within their respective parent containers, their distinguished names
are not the same. (For example, the object cn=JSmith,dc=noam,dc=reskit,dc=com is recognized by
LDAP as being different from cn=JSmith,dc=reskit,dc=com.)

Organizational Units

Active Directory allows administrators to create a hierarchy within a domain that meets the needs of
their organization. The object class of choice for building these hierarchies is the class
organizationalUnit , a general-purpose container that can be used to group most other object classes
together for administrative purposes. An organizational unit in Active Directory is analogous to a
directory in the file system; it is a container that can hold other objects.

Administrative Hierarchy

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

Group Policy can be applied to organizational units to define the abilities of groups of computers and
users that are contained within the organizational units. Levels of control range from complete
desktop lockdown to a relatively autonomous user experience. Group Policy can affect functionality,
such as what applications are available to a group of users, what features within an application are
accessible on a particular computer, where documents are saved, and access and user permissions.
Group Policy also affects where, when, and how application and operating system updates or special
scripts are applied.

Group Policy settings are stored as Group Policy objects in Active Directory. A Group Policy object
can be associated with one or more Active Directory containers, such as a site, domain, or
organizational unit.

Authentication and Authorization

Authentication of user accounts determines that a user who logs on to anActive Directory domain is
who the user claims to be and that the user does indeed have an account either in the domain or in
a domain that is trusted. After the user is authenticated, however, Active Directory must provide
security (authorization) to determine what objects the authenticated user can view or change and
what kinds of changes are allowed. This type of security is achieved through access control.

Access Control

All Active Directory objects are protected by an ACL. ACLs determine who can see the object and
what actions each user can perform on the object. The existence of an object is never revealed to a
user who is not allowed to read it.

An ACL is a list of access control entries (ACEs) that are stored with the object that the ACL protects.
ACLs on Active Directory objects contain ACEs that apply to the object as a whole and ACEs that
apply to the individual properties of the object. This structure allows an administrator to control not
only which users can see an object but also what properties the users can see. For example, all users
might be granted read access to the e-mail and telephone number properties for all other users, but
the security properties of users might be denied to all but members of a special security
administrators group. Individual users might be granted write access to personal properties such as
the telephone and mailing addresses on their own user objects. Use the Delegate Control command
in the context menu of an organizational unit to set the access limits for appropriate groups.

Delegation of Administration

Delegation is one of the most important security features of Active Directory. Delegation allows a
higher administrative authority to grant specific administrative user rights for containers and
subtrees to individuals and groups. Delegation eliminates the need for domain administrators to
have sweeping authority over large segments of the user population.

ACEs can grant specific administrative rights on the objects in a container to a user or group. Rights
are granted for specific operations on specific object classes through ACEs in the container's ACL.
Inheritance

You use inheritance to propagate a particular ACE from the container where it was applied to all
objects within the container. Inheritance can be combined with delegation to grant administrative
rights to a whole subtree of the directory in a single operation.

More about Domain Controller Servers

A domain controller is a computer that is running Windows 2008R2 Server and hosts Active
Directory. Domain controllers run the KDC service, which is responsible for authenticating domain
user logons. A domain controller stores directory partitions. Directory partitions (also known as
"naming contexts") correspond to the logically distributed segments of Active Directory that are
replicated as discrete units. These segments correspond to the following directory partitions:

A domain, of which there can be many in a particular forest (directory).


The directory schema, of which there is one in a particular forest (directory).
The Configuration container, of which there is one in a particular forest (directory).

In addition to the domain directory partition that it stores, every domain controller stores a replica
of the schema directory partition and the configuration directory partition.

Multimaster Operations

A domain can deploy many domain controllers, and all domain controllers can accept Active
Directory changes. Earlier versions of Windows NT used multiple domain controllers, only one of
which was allowed to update the directory database. This single-master scheme required all changes
to be replicated from the primary domain controller to the backup domain controllers.

In Active Directory, every domain controller can receive changes, and the changes are replicated to
all other domain controllers. The day-to-day operations that are associated with managing users,
groups, and computers are typically multimaster operations — that is, changes to these objects can
be made on any domain controller. There are some operations, however, that are not performed as
multimaster operations because they must occur at only one place and time. For these operations,
there are specially designated domain controllers that manage the operations singly.

More about Global Catalog Servers

Every domain controller in a forest stores three full writable directory partitions: a domain directory
partition, a schema directory partition, and a configuration directory partition. A Global Catalog is a
domain controller that stores these writable directory partitions, as well as a partial, read-only copy
of all other domain directory partitions in the forest. The additional directory partitions are "partial"
because, although they collectively contain every object in the directory, only a limited set of specific
attributes are included for each object. The Global Catalog is built automatically by the Active
Directory replication system.

All of the directory partitions on a Global Catalog server, whether full or partial partitions, are stored
in a single directory database (Ntds.dit) on that server. There is no separate storage area for Global
Catalog attributes; they are treated as additional information in the domain controller directory
database.
When a new domain is added to the forest, the information about the new domain is stored in the
configuration directory partition, which reaches the Global Catalog server (and all domain
controllers) through replication of forest-wide information. When a new Global Catalog server is
designated, this information is also stored in the configuration directory partition and replicated to
all domain controllers in the forest.

Global Catalog Attributes

In its role as a domain controller, a Global Catalog server stores one domain directory partition that
has writable objects with a full complement of writable attributes. The objects in all other domain
directory partitions in the forest are stored on a Global Catalog server as read-only objects with a
partial set of attributes. An attribute is marked as being replicated to the Global Catalog as part of its
schema definition. In the Active Directory Schema console in MMC, you can use the Replicate this
attribute to the Global Catalog check box to designate an attributeSchema object as a member of
the attribute set that is replicated to the Global Catalog servers. If this check box is selected, the
value in the attribute isMemberOfPartialAttributeSet on the attributeSchema object is set to TRUE,
and the attribute is replicated to the Global Catalog as part of normal Active Directory replication.
The replication topology for the Global Catalog is generated automatically by the Knowledge
Consistency Checker (also known as the "KCC"), a built-in process that implements a replication
topology that is guaranteed to deliver the contents of every directory partition to every Global
Catalog server. The attributes replicated into the Global Catalog include a base set defined by
Microsoft. Administrators can use the Active Directory Schema console to specify additional
attributes to meet the needs of their installation.

Designating a Global Catalog

The first domain controller in a forest is automatically designated as a Global Catalog. Thereafter, a
domain controller can be designated as a Global Catalog in the NTDS Settings Properties dialog box
in Active Directory Sites and Services. The NTDS Settings object is a child of the server object, which
is a child of the site object in the Sites container. When you select the Global Catalog Server check
box, the domain controller is added to the Global Catalog replication topology and populated by
means of the normal replication process. When you change an attribute that is flagged as belonging
in the Global Catalog in any domain, it is replicated to all Global Catalog servers.

The NTDS Settings object has the multivalue attribute hasMasterNCs , which identifies the directory
partitions that the domain controller stores. ("NC" stands for "naming context," which is a synonym
for "directory partition.") For every domain controller, there are exactly three "master" (full and
writable) directory partitions: the domain directory partition, the schema directory partition, and the
configuration directory partition. The NTDS Settings object also has the multivalue attribute
hasPartialReplicationNCs. If the domain controller is a Global Catalog server, this attribute has a
value for each domain directory partition in the forest, and it receives attribute changes through
replication with each respective domain directory partition in the forest.

Because the NTDS Settings object is stored in the configuration directory partition, which is
replicated to all domain controllers in the forest, all domain controllers have the information about
which servers are Global Catalog servers.
Global Catalog and Domain Logon Support

In a native-mode domain, a Global Catalog server is a requirement for logging on to the domain. For
this reason, it is advisable to have at least one Global Catalog server in a site. If a Global Catalog is
not available in a site and there is another Global Catalog server in a remote site, the server in the
remote site can be used for the logon process. If no Global Catalog is available in any site, the logon
process proceeds with cached logon information.

NOTE: A member of the Domain Admins group can complete the logon process (not cached) even
when a Global Catalog server is not available.

Universal Group Membership

The reason that a Global Catalog must be available for the domain logon process is that the
membership for universal groups is not stored on all domain controllers. Because the membership of
all universal groups is replicated to Global Catalog servers, the complete universal group
membership of a user can be determined by querying a Global Catalog server.

NOTE: Universal groups are available only when a domain is in native mode.

During the logon process, a security token that contains the groups to which the user belongs is
associated with the user. Because universal group membership is stored only on Global Catalog
servers, only these servers can identify a user as having membership in a specific universal group. If a
universal group is present as an access control entry in an access control list on a specific directory
object, the access token associated with the user during the logon session must contain that group
in order for the Allow or Deny access permission to be applied to the user. Otherwise, a user could
be granted access (on the basis of another group membership) to an object that is specifically denied
that user as a member of the universal group. Similarly, this user would not be able to gain access to
resources to which he or she has legitimate access as a member of the universal group.

NOTE: Deny access permission is processed before Allow access permission. Therefore, if you are
denied access to an object by virtue of membership in one group and allowed access by virtue of
membership in another group, the Deny access takes precedence over the Allow access.

User Principal Name and Global Catalog Logon Support

User principal names are user names that can be used when a user is logging on to a Windows 2000
domain. A user also can provide a SAM account name (<DomainName \ UserName>). In the
Windows 2000 logon screen, you can type your user name and select the domain name from the list,
or you can use the user principal name. If you use the user principal name, when you type the "at"
sign (@), the domain list is unavailable; Windows 2000 takes the domain name from the user
principal name suffix.

The user principal name format (<UserName>@<DNSDomainName>) is resolved by the Global


Catalog server. If a company has more than one forest and uses trust relationships between the
domains in the different forests, a user principal name cannot be used to log on to a domain that is
outside the forest because the user principal name is resolved in the Global Catalog of the forest.

Search Requests and the Global Catalog

Because the Global Catalog stores every object in the forest, it can be used to locate objects in any
domain without a referral to a different server. When a search request is sent to port#160;389 (the
default LDAP port), the search is conducted on a single directory partition. If the object is not found
in that directory partition (and is not in the schema or configuration directory partitions), the
request is referred to a domain controller in a different domain that is assumed to contain the
requested object, on the basis of the distinguished name that is presented in the search request.

When a search request is sent to port 3268 (the default Global Catalog port), the search includes all
directory partitions in the forest — that is, the search is processed by a Global Catalog server. If the
request specifies attributes that are part of the Global Catalog attribute set, the Global Catalog can
return results for objects in any domain without generating a referral to a domain controller in a
different domain.

Name Resolution in Active Directory

Finding information in Active Directory, the Microsoft® Windows® directory service involves first
locating an Active Directory server (domain controller) for logging on to a domain and then finding
the information that you need in Active Directory. Both processes use name resolution. When you
are locating a domain controller, the Domain Name System (DNS) resolves (by DNS name resolution)
a domain name or computer name to an Internet Protocol (IP) address. During the search for
information in Active Directory, Windows 2000 resolves (by Lightweight Directory Access Protocol
[LDAP] name resolution) a distinguished name to a domain controller that holds the entry for that
name.

Operation Master Roles

Active Directory supports multimaster replication of the directory data store between all domain
controllers (DC) in the domain, so all domain controllers in a domain are essentially peers. However,
some changes are impractical to perform in using multimaster replication, so, for each of these types
of changes, one domain controller, called the operations master, accepts requests for such changes.

In every forest, there are at least five operations master roles that are assigned to one or more
domain controllers. Forest-wide operations master roles must appear only once in every forest.
Domain-wide operations master roles must appear once in every domain in the forest.

Note: The operations master roles are sometimes called flexible single master operations (FSMO)
roles.

Forest-wide operations master roles

Every forest must have the following roles:

Schema master

Domain naming master

These roles must be unique in the forest. This means that throughout the entire forest there can be
only one schema master and one domain naming master.

Schema master

The schema master domain controller controls all updates and modifications to the schema. To
update the schema of a forest, you must have access to the schema master. There can be only one
schema master in the entire forest.
Domain naming master

The domain controller holding the domain naming master role controls the addition or removal of
domains in the forest. There can be only one domain naming master in the entire forest.

Note

Any domain controller running Windows Server 2003 can hold the role of the domain
naming master. A domain controller running Windows 2000 Server that holds the role of
domain naming master must also be enabled as a global catalog server.

Domain-wide operations master roles

Every domain in the forest must have the following roles:

Relative ID (RID) master

Primary domain controller (PDC) emulator master

Infrastructure master

These roles must be unique in each domain. This means that each domain in the forest can have only
one RID master, PDC emulator master, and infrastructure master.

RID master

The RID master allocates sequences of relative IDs (RIDs) to each of the various domain controllers in
its domain. At any time, there can be only one domain controller acting as the RID master in each
domain in the forest.

Whenever a domain controller creates a user, group, or computer object, it assigns the object a
unique security ID (SID). The SID consists of a domain SID, which is the same for all SIDs created in
the domain, and a RID, which is unique for each SID created in the domain.

To move an object between domains (using Movetree.exe), you must initiate the move on the
domain controller acting as the RID master of the domain that currently contains the object.

PDC emulator master

The PDC emulator master processes password changes from client computers and replicates these
updates to all domain controllers throughout the domain. At any time, there can be only one domain
controller acting as the PDC emulator master in each domain in the forest.

The PDC emulator role is used in the following ways:

To provide consistent password experience for users across sites (can be turned off with
AvoidPdcOnWan registry parameter) - The PDC emulator is used as a reference DC to
double-check incorrect passwords and it also receives new password changes. When the
PDC is reachable, users can use a new password immediately and consistently across the
environment.

As a preferred point of administration for services (examples are Group Policy and
Distributed File System, DFS)

As a point of contact for applications hard-coded to the PDC (often written for Windows NT
4.0 and older domains) - The legacy API often used for this is NetGetDcName. It is strongly
suggested to change applications to use the new API to locate DCs. DsGetDcName by default
does not target the PDC, and has more options that allows you to pick the type of DC
needed to perform the operation.

As a default time server for all other DCs in the domain - The time server configuration of a
PDC requires manual consideration and should be reviewed when you change the owner of
the PDC role.

The domain controller configured with the PDC emulator role supports two authentication
protocols:

The Kerberos V5 protocol

The NTLM protocol

Infrastructure master

At any time, there can be only one domain controller acting as the infrastructure master in each
domain. The infrastructure master is responsible for updating references from objects in its domain
to objects in other domains. The infrastructure master compares its data with that of a global
catalog. Global catalogs receive regular updates for objects in all domains through replication, so the
global catalog data will always be up to date. If the infrastructure master finds data that is out of
date, it requests the updated data from a global catalog. The infrastructure master then replicates
that updated data to the other domain controllers in the domain.

Important

Unless there is only one domain controller in the domain, the infrastructure master role
should not be assigned to the domain controller that is hosting the global catalog. If the
infrastructure master and global catalog are on the same domain controller, the
infrastructure master will not function. The infrastructure master will never find data that is
out of date, so it will never replicate any changes to the other domain controllers in the
domain.

In the case where all of the domain controllers in a domain are also hosting the global
catalog, all of the domain controllers will have the current data and it does not matter which
domain controller holds the infrastructure master role.

The infrastructure master is also responsible for updating the group-to-user references whenever
the members of groups are renamed or changed. When you rename or move a member of a group
(and that member resides in a different domain from the group), the group may temporarily appear
not to contain that member. The infrastructure master of the group's domain is responsible for
updating the group so it knows the new name or location of the member. This prevents the loss of
group memberships associated with a user account when the user account is renamed or moved.
The infrastructure master distributes the update via multimaster replication.

There is no compromise to security during the time between the member rename and the group
update. Only an administrator looking at that particular group membership would notice the
temporary inconsistency.
Understanding Sites, Subnets, and Site Links

An understanding of sites, subnets, and site links helps you effectively manage sites and their
implementation in Active Directory Domain Services (AD DS).

Sites overview

Sites in AD DS represent the physical structure, or topology, of your network. AD DS uses network
topology information, which is stored in the directory as site, subnet, and site link objects, to build
the most efficient replication topology. The replication topology itself consists of the set of
connection objects that enable inbound replication from a source domain controller to the
destination domain controller that stores the connection object. The Knowledge Consistency
Checker (KCC) creates these connection objects automatically on each domain controller.

Note

You do not have to manage connection objects. In fact, changes that you make to connection objects
that the KCC creates automatically are ignored.

You can use the Active Directory Sites and Services snap-in to manage the site, subnet, and site link
objects that combine to influence the replication topology.

Note

You can also use Active Directory Sites and Services to manage sites in an Active Directory
Lightweight Directory Services (AD LDS) configuration set.

It is important to distinguish between sites and domains. Sites represent the physical structure of
your network, while domains represent the logical structure of your organization. Site objects and
their contents are replicated to all domain controllers in the forest, irrespective of domain or site.

Using sites

Domain controllers and other servers that use sites publish server objects in AD DS to take
advantage of the good network connectivity that sites provide. You place domain controllers into
sites according to where the domain data is needed. For example, if no users from a domain are
physically located in a site, there is no reason to place a domain controller for that domain in the
site.

Sites help facilitate several activities, including:

Replication . AD DS balances the need for up-to-date directory information with the need
for bandwidth optimization by replicating information within a site whenever data is
updated and between sites according to a configurable schedule.

Authentication . Site information helps make authentication faster and more efficient.
When a client logs on to a domain, it first requests a domain controller in its local site for
authentication. By establishing sites, you can ensure that clients use domain controllers that
are nearest to them for authentication, which reduces authentication latency and traffic on
wide area network (WAN) connections.

Service location . Other services, such as Active Directory Certificate Services (AD CS),
Exchange Server, and Message Queuing, use AD DS to store objects that can use site and
subnet information that make it possible for clients to locate the nearest service providers
more easily.

Associating sites and subnets

A subnet object in AD DS groups neighboring computers in much the same way that postal codes
group neighboring postal addresses. By associating a site with one or more subnets, you assign a set
of IP addresses to the site.

Note

The term "subnet" in AD DS does not have the strict networking definition of the set of all addresses
behind a single router. The only requirement for an AD DS subnet is that the address prefix conforms
to the IP version 4 (IPv4) or IP version 6 (IPv6) format.

When you add the Active Directory Domain Services server role to create the first domain controller
in a forest, a default site (Default-First-Site-Name) is created in AD DS. As long as this site is the only
site in the directory, all domain controllers that you add to the forest are assigned to this site.
However, if your forest will have multiple sites, you must create subnets that assign IP addresses to
Default-First-Site-Name as well as to all additional sites.

Assigning computers to sites

Server objects are created in AD DS by applications or services, and they are placed into a site based
on their IP address. When you add the Active Directory Domain Services server role to a server, a
server object is created in the AD DS site that contains the subnet to which the server's IP address
maps. If the domain controller's IP address does not map to any site in the forest, the domain
controller's server object is created in the site of the domain controller that provides the replication
source for AD DS.

Note

Server objects are not created in Default-First-Site-Name by default unless there are no other sites in
the forest.

For a client, site assignment is determined dynamically by its IP address and subnet mask during
logon.

Locating domain controllers by site

Domain controllers register service (SRV) resource records in Domain Name System (DNS) that
identify their site names. Domain controllers also register host (A) resource records in DNS that
identify their IP addresses. When a client requests a domain controller, it provides its site name to
DNS. DNS uses the site name to locate a domain controller in that site (or in the next closest site to
the client). DNS then provides the IP address of the domain controller to the client for the purpose
of connecting to the domain controller. For this reason, it is important to ensure that the IP address
that you assign to a domain controller maps to a subnet that is associated with the site of the
respective server object. Otherwise, when a client requests a domain controller, the IP address that
is returned might be the IP address of a domain controller in a distant site. When a client connects to
a distant site, the result can be slow performance and unnecessary traffic on expensive WAN links.
Connecting sites with site links

Networks usually consist of a set of local area networks (LANs) that are connected by WANs. In
AD DS, site link objects represent the WAN connections between sites. Whereas replication within a
site is triggered automatically when a directory update occurs, replication between sites (over
slower, more expensive WAN links) is scheduled to occur every 3 hours. You can change the default
schedule to occur during the periods that you specify, and at the intervals that you specify, so that
you can control WAN link traffic.

Active Directory Structure and Storage Technologies


Administrators use Active Directory to store and organize objects on a network (such as users,
computers, devices, and so on) into a secure hierarchical containment structure that is known as the
logical structure. Although the logical structure of Active Directory is a hierarchical organization of all
users, computers, and other physical resources, the forest and domain form the basis of the logical
structure. Forests, which are the security boundaries of the logical structure, can be structured to
provide data and service autonomy and isolation in an organization in ways that can both reflect site
and group identities and remove dependencies on the physical topology.

Domains can be structured in a forest to provide data and service autonomy (but not isolation) and
to optimize replication with a given region. This separation of logical and physical structures
improves manageability and reduces administrative costs because the logical structure is not
affected by changes in the physical structure. The logical structure also makes it possible to control
access to data. This means that you can use the logical structure to compartmentalize data so that
you can control access to it by controlling access to the various compartments.

The data that is stored in Active Directory can come from many diverse sources. With so many
different data sources and so many different types of data, Active Directory must employ some type
of standardized storage mechanism so that it can maintain the integrity of the data that it stores. In
Active Directory, objects are used to store information in the directory, and all objects are defined in
the schema. The object definitions contain information, such as data type and syntax, that the
directory uses to ensure that the stored data is valid. No data can be stored in the directory unless
the objects that are used to store the data are first defined in the schema. The default schema
contains all the object definitions that Active Directory needs to function; however, you can also add
object definitions to the schema.

While the directory is exposed to you through a logical structure that consists of elements such as
domains and forests, the directory itself is implemented through a physical structure that consists of
a database that is stored on all domain controllers in a forest. The Active Directory data store
handles all access to the database. The data store consists of both services and physical files. These
services and physical files make the directory available, and they manage the processes of reading
and writing the data inside the database that exists on the hard disk of each domain controller.

Active Directory Structure and Storage Architecture

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
Forest means that administrators in a 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
Domain controller to another. Some data that is relevant to the entire forest is replicated to all
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 one unit. This makes it
OU 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 contains Internet Protocol (IP)/DNS–
Locator
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 example,
cohovineyard.com), and every domain joined computer has a DNS name
Active Directory domain
(for example, server1.cohovineyard.com). Architecturally, domains and
names in DNS
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 dnsZone object
Active Directory DNS contains a DNS node object (class dnsNode) for every unique name in that
objects zone. The dnsNode object has a dnsRecord multivalued attribute that
contains a value for every resource record that is associated with that DNS
name.
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

Component Description

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
classSchema
password. It 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
attributeSchema logon name attribute and a password attribute. Each of these attributes also has
objects its own 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

Component Description

Interfaces
The data store interfaces provide a way for directory clients and other directory
(LDAP, REPL,
servers to communicate with the data store.
MAPI, SAM)

The DSA (which runs as Ntdsa.dll on each domain controller) provides the
interfaces through which directory clients and other directory servers gain access
DSA (Ntdsa.dll) 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
Database layer from applications are never made 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 individual records in
ESE (Esent.dll) 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 addition,
Database files the data store also uses log files, to which it temporarily writes uncommitted
transactions.

References:

http://technet.microsoft.com/en-us/library/cc731053(WS.10).aspx – Active Directory Domain


Services Overview

http://technet.microsoft.com/en-us/library/cc773108(v=WS.10).aspx – Operations Master Roles

http://technet.microsoft.com/en-us/library/cc759186(v=WS.10).aspx - Active Directory Structure


and Storage Technologies

http://technet.microsoft.com/en-us/library/cc754697.aspx - Understanding Sites, Subnets and Site


Links
Module 2: Active Directory Domains and Forests – Deep Dive.
Like we have already discussed in the earlier module, the Active Directory directory service is a
distributed database that stores and manages information about network resources, as well as
application-specific data from directory-enabled applications. Active Directory allows administrators
to organize objects of a network (such as users, computers, and devices) into a hierarchical
collection of containers known as the logical structure. The top-level logical container in this
hierarchy is the forest. Within a forest are domain containers, and within domains are organizational
units.

Note

In Windows 2000 Server and Windows Server 2003, the directory service is named Active Directory.
In Windows Server 2008 and Windows Server 2008 R2, the directory service is named Active
Directory Domain Services (AD DS). The rest of this topic refers to Active Directory, but the
information is also applicable to Active Directory Domain Services.

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

Implementing an authentication and authorization strategy for sharing resources across a


network

Providing a mechanism for centralizing management of multiple domains and forests

Providing an information repository and services to make information available to users and
applications

Organizing objects of a network (such as users, computers, devices, resources, and


application specific data from directory-enabled applications) into a non-physical
hierarchical structure

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

The Logical Structure of Active Directory


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

Benefits of the Logical Structure

The logical structure provides a number of benefits for deploying, managing, and securing network
services and resources. These benefits include:
Increased network security. The logical structure can provide security measures such as
autonomy for individual groups or complete isolation of specific resources.

Simplified network management. The hierarchical nature of the logical structure simplifies
configuration, control, and administration of the network, including managing user and
group accounts and all network resources.

Simplified resource sharing. The logical structure of domains and forests and the
relationships established between them can simplify the sharing of resources across an
organization.

Low total cost of ownership. The reduced administration costs for network management and
the reduced load on network resources that can be achieved with the Active Directory
logical structure can significantly lower the total cost of ownership.

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

Components of the Logical Structure

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

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

Components of the Active Directory Logical Structure

Component Description

Organizational units are container objects. You use these container objects to
arrange other objects in a manner that supports your administrative purposes. By
arranging objects in organizational units, you make it easier to locate and manage
them. You can also delegate the authority to manage an organizational unit.
Organizational units can be nested in other organizational units.
Organizational
Units You can arrange objects that have similar administrative and security requirements
into organizational units. Organizational units provide multiple levels of
administrative authority, so that you can apply Group Policy settings and delegate
administrative control. This delegation simplifies the task of managing these objects
and enables you to structure Active Directory to fit your organization’s
requirements.
Domains are container objects. Domains are a collection of administratively defined
objects that share a common directory database, security policies, and trust
Domains relationships with other domains. In this way, each domain is an administrative
boundary for objects. A single domain can span multiple physical locations or sites
and can contain millions of objects.

Domain trees are collections of domains that are grouped together in hierarchical
structures. When you add a domain to a tree, it becomes a child of the tree root
domain. The domain to which a child domain is attached is called the parent
domain.
Domain Trees
A child domain might in turn have its own child domain. The name of a child domain
is combined with the name of its parent domain to form its own unique Domain
Name System (DNS) name such as Corp.nwtraders.msft. In this manner, a tree has a
contiguous namespace.

A forest is a complete instance of Active Directory. Each forest acts as a top-level


container in that it houses all domain containers for that particular Active Directory
instance. A forest can contain one or more domain container objects, all of which
share a common logical structure, global catalog, directory schema, and directory
Forests configuration, as well as automatic two-way transitive trust relationships. The first
domain in the forest is called the forest root domain. The name of that domain
refers to the forest, such as Nwtraders.msft. By default, information in Active
Directory is shared only within the forest. In this way, the forest is a security
boundary for the information that is contained in that instance of Active Directory.

Sites are leaf and container objects. The sites container is the topmost object in the
hierarchy of objects that are used to manage and implement Active Directory
replication. The sites container stores the hierarchy of objects that are used by the
Knowledge Consistency Checker (KCC) to effect the replication topology. Some of
Site Objects
the objects located in the sites container include NTDS Site Settings objects, subnet
objects, connection objects, server objects, and site objects (one site object for each
site in the forest). The hierarchy is displayed as the contents of the Sites container,
which is a child of the Configuration container.

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

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

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

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

The Physical Structure of Active Directory


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

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

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

Note

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

What Are Domains?

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

A domain is a partition in an Active Directory forest. Partitioning data enables organizations to


replicate data only to where it is needed. In this way, the directory can scale globally over a network
that has limited available bandwidth. Domains can also be defined as:

Containers within a forest

Units of Policy
Units of Replication

Authentication and Authorization Boundaries

Units of Trust

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

Domains as Containers Within a Forest

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

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

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

Domain Containment Structure Within a Forest

Organizational Units and Objects

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

Organizational Units

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

An organizational unit is the smallest scope or unit to which Group Policy settings can be assigned or
to which administrative authority can be delegated. A hierarchy of organizational units can be
extended as necessary to model the hierarchy of an organization within a domain. The
administrative model of the organizational unit can be scaled to any size.

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

Objects

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

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

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

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

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

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

You cannot define different account policies for different organizational units in the same domain.
Policy settings are stored as Group Policy objects (GPOs) in Active Directory. A GPO establishes how
domain resources can be accessed, configured, and used. The policies associated with a GPO are
applied only within the domain and not across domains. A GPO can be associated with one or more
Active Directory containers, such as a site, domain, or organizational unit.
Account policies and Public Key policies have domain-wide scope and are set at the domain GPO
level. All other policies can be specified at the level of the organizational unit. Some policies that can
be applied only at the domain container level include:

Password policy. Determines the rules, such as password length, that must be met when a
user sets a password.

Account lockout policy. Defines rules for intruder detection and account deactivation.

Kerberosticket policy. Determines the lifetime of a Kerberos ticket. A Kerberos ticket is


obtained during the logon process and is used for network authentication. A particular ticket
is only valid for the lifetime specified in the policy.

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

Domains as Units of Replication

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

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

All domain controllers in the forest are also updated with changes to forest-wide data. Domain-wide
replication relies on three components of the Active Directory physical structure to be in place for
optimal performance, these include:

Domain Controllers

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

Domain controllers also have two non-domain directory partitions that store forest-wide data, which
includes the directory schema and configuration data. Optionally, domain controllers, application
partitions can be configured to be located on designated domain controllers anywhere in a forest.
Unlike the schema and configuration partitions, application partitions are not located on every
domain controller in a forest.
Partitioning Active Directory data into three physical partitions on each domain controller helps to
control replication so that data is replicated only to where it is needed. In this way, Active Directory
can scale globally over a network that has limited available bandwidth.

Sites

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

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

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

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

Domain-Wide Operations Masters

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

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

Domains as Authentication and Authorization Boundaries

By default, a domain provides authentication and authorization services for all its accounts in order
to facilitate logons and single sign-on access control to shared resources within the boundaries of
the domain. The process of authentication ensures that users are who they claim to be. Once
identified, the user can be authorized access to a specific set of network resources based on
permissions.Authorization takes place through the mechanism of access control, using access control
lists (ACLs) that define permissions on file systems, network file and print shares, and entries in
Active Directory.
Authorization is determined not only by the identity of the user but also the membership of the user
in one or more security groups. In fact, the preferred method of controlling domain-wide resources
is to grant access to groups rather than to individuals, adjusting the level of authorization for a group
according to the needs of its members. This method of controlling access makes it easier to keep
ACLs up-to-date on domains that have thousands of users and objects. Group membership can be
managed centrally by anyone with the appropriate administrative credentials. You can change the
level of authorization a particular user has to many resources simply by adding or removing the user
from a group. The following figure shows when authentication and authorization for a user in a given
domain occur.

Authentication and Authorization of a User Within the Same Domain

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

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

Domains as Units of Trust

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

Note

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

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

Domains as Units of Trust and the Authentication Paths they Provide


In accordance with DNS naming standards, Active Directory domains within a single forest are
created in an inverted tree structure, with the forest root domain at the top. This tree structure
requires that trusts exist between domains to facilitate security of communications. Adding a
domain tree to a forest requires specification of the forest root domain, which results in the
establishment of a trust relationship between the root domain of the new tree and the forest root
domain.

What Domains Are Not

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

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

What Are Forests?

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

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

Forests can also be defined as:

Collections of Domain Containers that Trust Each Other

Units of Replication

Security Boundaries

Units of Delegation

Forests as Collections of Domain Containers that Trust Each Other

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

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

Domain Containers, Root Domains and DNS Namespaces Within a Forest


Forest Root Domain

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

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

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

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

Tree Root Domain

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

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

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

Forests as Units of Replication

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

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

Forest-Wide Replication Scope


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

Forest-Wide Directory Partitions

Partition Description

The schema partition contains the forest-wide schema. Each forest has one schema so
that the definition of each object class is consistent. The schema is the formal
definition of all object and attribute data that can be stored in the directory. Active
Schema Directory domain controllers include a default schema that defines many object types,
such as user and computer accounts, groups, domains, organization units, and
security policies. Administrators and programmers can extend the schema by defining
new object types and attributes or by adding new attributes for existing objects.
Schema objects are protected by access control lists, ensuring that only authorized
users can alter the schema. The schema partition is replicated to each domain
controller in the forest.

The configuration partition describes the topology of the forest as well as other
forest, domain and domain controller settings. This configuration data includes a list
Configuration of all domains, trees, and forests and the locations of the domain controllers and
global catalogs. The configuration partition is replicated to each domain controller in
the forest.

Applications and services can use application directory partitions to store application-
specific data. Data stored in the application directory partition is intended to satisfy
cases where information needs to be replicated but not necessarily on a global scale.
Application directory partitions can contain any type of object, except security
principals. Application directory partitions are usually created by the applications that
will use them to store and replicate data. One of the benefits of an application
directory partition is that, for redundancy, availability, or fault tolerance, the data in it
Application can be replicated to different domain controllers in a forest. The data can be
replicated to a specific domain controller or any set of domain controllers anywhere
in the forest. This differs from a domain directory partition in which data is replicated
to all domain controllers in that domain.

Only domain controllers running Windows Server 2003 or higher can host a replica of
an application directory partition. Application directory partitions are created,
configured, and managed by the administrator.

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

Forest-Wide Operations Master Roles

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

In an Active Directory forest with only one domain and one domain controller, that domain
controller has all the operations master roles.

Sites

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

Global Catalogs

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

A global catalog serves the following roles:

Enables user searches for directory information about objects throughout all domains in the
forest

Resolves user principal names (UPNs) during authentication, when the authenticating
domain controller does not have information about the account

Supplies universal group membership information in a multiple domain environment

Validates references to objects in other domains in the forest

Forests as Security Boundaries

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

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

Forests as Units of Delegation

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

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

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

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

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

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

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

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

Two Forest Trusts Between Three Windows Server 2003 Forests


Network Ports Used by Domains and Forests
The following tables list the network ports that are associated with domains and forests.

Port Assignments for Raising Active Directory Functional Levels

Service Name UDP TCP

LDAP 389 389

LDAP SSL N/A 636

Port Assignments for Data Store

Service Name UDP TCP

LDAP 389 389

LDAP SSL N/A 636

RPC Endpoint Mapper 135 135

Global Catalog LDAP N/A 3268

Global Catalog LDAP SSL N/A 3269

Port Assignments for Service Publication and SPNs

Service Name UDP TCP

LDAP 389 389

LDAP SSL N/A 636

RPC Endpoint Mapper 135 135

Global Catalog LDAP N/A 3268

Global Catalog LDAP SSL N/A 3269

Kerberos 88 88
Port Assignments for Raising Active Directory Searches

Service Name UDP TCP

LDAP 389 389

LDAP SSL N/A 636

Global Catalog LDAP N/A 3268

Global Catalog LDAP SSL N/A 3269

Port Assignments for Global Catalogs

Service Name UDP TCP

LDAP N/A 3268

LDAP N/A 3269 (global catalog Secure Sockets Layer [SSL])

LDAP 389 389

LDAP N/A 686 (SSL)

RPC/REPL 135 135 (endpoint mapper)

Kerberos 88 88

DNS 53 53

SMB over IP 445 445

Port Assignments for Replication

Service Name UDP TCP

LDAP 389 389

LDAP N/A 686 (SSL)

RPC/REPL N/A 135 (endpoint mapper)

LDAP N/A 3268


Kerberos 88 88

DNS 53 53

SMB over IP 445 445

Port Assignments for Operations Masters

Service Name UDP TCP

LDAP 389 389

LDAP N/A 686 (SSL)

RPC/REPL N/A 135 (endpoint mapper)

Netlogon N/A 137

Kerberos 88 88

DNS 53 53

SMB over IP 445 445

Port Assignments for Interactive Logon

Service Name UDP TCP

Kerberos 88 88

Local Security Authority (LSA) RPC Dynmaic RPC Dynamic RPC

NTLM Dynamic Dynamic

Port Assignments for Kerberos V5 Protocol

Service Name UDP TCP

DNS 53 53

Kerberos 88 88
Port Assignment for DC Locator

Service Name UDP TCP

LDAP 389 389

The following table shows the list of ports that might need to be opened before you establish trusts.

Ports Required for Trusts

Task Outbound Ports Inbound Ports From–To

LDAP (389 UDP and


TCP)

Microsoft SMB (445 Internal domain


TCP) domain controllers–
Set up trusts on both sides
Kerberos (88 UDP) N/A External domain
from the internal forest
domain controllers (all
Endpoint resolution ports)
— portmapper (135
TCP) Net Logon fixed
port

LDAP (389 UDP)

Trust validation from the Microsoft SMB (445 Internal domain


internal forest domain TCP) domain controllers–
controller to the external forest N/A External domain
Endpoint resolution
domain controller (outgoing domain controllers (all
— portmapper (135
trust only) ports)
TCP) Net Logon fixed
port

LDAP (389 UDP and


TCP) External server–
Internal domain PDCs
Windows NT
Use Object picker on the (Kerberos)
Server 4.0 directory
external forest to add objects service fixed port External domain
N/A
that are in an internal forest to domain controllers–
groups and DACLs Net Logon fixed port
Internal domain
Kerberos (88 UDP) domain controllers
(Net Logon)
Endpoint resolution
portmapper (135
TCP)

LDAP (389 UDP and


External domain
TCP)
domain controllers–
Set up trust on the external
N/A Microsoft SMB (445 Internal domain
forest from the external forest
TCP) domain controllers (all
ports)
Kerberos (88 UDP)

Use Kerberos authentication Internal client–External


(internal forest client to Kerberos (88 UDP) N/A domain domain
external forest) controllers (all ports)

External domain
Endpoint resolution
Use NTLM authentication domain controllers–
– portmapper (135
(internal forest client to N/A Internal domain
TCP) Net Logon fixed
external forest) domain controllers (all
port
ports)

LDAP (389 UDP and


TCP)

Microsoft SMB (445


TCP)

Kerberos (88 UDP)


Join a domain from a computer Internal client–External
in the internal network to an Endpoint resolution N/A domain domain
external domain — portmapper (135 controllers (all ports)
TCP) Net Logon fixed
port

Windows NT
Server 4.0 directory
service fixed port

References:

http://technet.microsoft.com/en-us/library/cc759073(v=ws.10).aspx

http://technet.microsoft.com/en-us/library/cc783351(v=ws.10).aspx#w2k3tr_logic_how_rqma

Module 3: Install Active Directory Domain Services in Windows 2008 R2


Active Directory® Domain Services (AD DS) is a server role of the Windows Server® 2008 and
Windows Server 2008 R2 operating systems. AD DS provides a distributed directory service that you
can use for centralized, secure management of your network.

Requirements for Installing AD DS

For Windows Server 2008 hardware requirements, see Installing Windows Server 2008 at
http://go.microsoft.com/fwlink/?LinkId=111104.

The following software and hardware requirements apply to a full installation or a Server Core
installation of the Windows Server 2008 or Windows Server 2008 R2 operating system.

Install Windows Server 2008 or Windows Server 2008 R2.

Verify that a Domain Name System (DNS) infrastructure is in place. Before you add
Active Directory Domain Services (AD DS) to create a domain or forest, be sure that a DNS
infrastructure is in place on your network. When you install AD DS, you can include DNS
server installation, if it is needed. When you create a new domain, a DNS delegation is
created automatically during the installation process.

If a DNS infrastructure is not in place when you install an additional domain controller in a
domain, then the option to install DNS server on that domain controller will not be available.

Configure appropriate TCP/IP and DNS server addresses.

Verify that Adprep.exe operations are complete. Before you can add AD DS to a server that
is running Windows Server 2008 or Windows Server 2008 R2 in an existing Active Directory
environment, you must prepare the environment by running Adprep.exe.

Note

In Windows Server 2008, Adprep.exe is available in the /sources/adprep folder of the


installation DVD. In Windows Server 2008 R2, Adprep.exe is located in the /support/adprep
folder.

The drives that store the database, log files, and SYSVOL folder for Active Directory Domain
Services (AD DS) must be placed on a local fixed volume. SYSVOL must be placed on a
volume that is formatted with the NTFS file system. For security purposes, the
Active Directory database and log files should be placed on a volume that is formatted with
NTFS.

Traditionally, the Active Directory database and log files are placed on disk drives that are
physically local to the domain controller computer.

Steps for Installing AD DS


Installing a New Forest by Using the Graphical User Interface (GUI)

Windows provides two wizards that guide you through the AD DS installation process. The first
wizard is the Add Roles Wizard, which you can access in Server Manager. The second wizard is the
Active Directory Domain Services Installation Wizard, which you can access in the following ways:

When you complete the Add Roles Wizard, click the link to launch the Active Directory
Domain Services Installation Wizard.

Click Start, click Run, type dcpromo.exe, and then click OK.

Administrative credentials

To perform this procedure, you must be logged on as the local Administrator for the computer.
Depending on the operating system installation options that were selected for the computer, the
local Administrator password might be blank or it might not be required. In this case, run the
following command at a command prompt before you start to install AD DS:

net user Administrator <password>/passwordreq:yes

Replace <password> with a strong password.

To install a new forest by using the Windows interface

1. Open Server Manager. Click Start, point to Administrative Tools, and then click Server
Manager.

2. In Roles Summary, click Add Roles.

3. If necessary, review the information on the Before You Begin page and then click Next.

4. On the Select Server Roles page, click the Active Directory Domain Services check box, and
then click Next.

Note

On a server that runs Windows Server 2008 R2, you might have to click Add Required
Features to install .NET Framework 3.5.1 features before you can click Next.

5. If necessary, review the information on the Active Directory Domain Services page, and
then click Next.

6. On the Confirm Installation Selections page, click Install.

7. On the Installation Results page, click Close this wizard and launch the Active Directory
Domain Services Installation Wizard (dcpromo.exe).

8. On the Welcome to the Active Directory Domain Services Installation Wizard page, click
Next.

You can select the Use advanced mode installation check box to get additional installation options.

9. On the Operating System Compatibility page, review the warning about the default security
settings for Windows Server 2008 and Windows Server 2008 R2 domain controllers, and
then click Next.
10. On the Choose a Deployment Configuration page, click Create a new domain in a new
forest, and then click Next.

11. On the Name the Forest Root Domain page, type the full Domain Name System (DNS) name
for the forest root domain, and then click Next.

Although Dcpromo.exe in Windows Server 2008 and Windows Server 2003 allows you to create a
single-label DNS domain name, you should not use a single-label DNS name for a domain for several
reasons. In Windows Server 2008 R2, Dcpromo.exe does not allow you to create a single-label DNS
name for a domain.

12. If you selected Use advanced mode installation on the Welcome page, the Domain NetBIOS
Name page appears. On this page, type the NetBIOS name of the domain if necessary or
accept the default name, and then click Next.

13. On the Set Forest Functional Level page, select the forest functional level that
accommodates the domain controllers that you plan to install anywhere in the forest, and
then click Next.

14. On the Set Domain Functional Level page, select the domain functional level that
accommodates the domain controllers that you plan to install anywhere in the domain, and
then click Next.

Note

The Set Domain Functional Level page does not appear if you select the Windows
Server 2008 forest functional level on a server that runs Windows Server 2008 or if you
select the Windows Server 2008 R2 forest functional level on a server that runs Windows
Server 2008 R2.

15. On the Additional Domain Controller Options page, DNS server is selected by default so
that your forest DNS infrastructure can be created during AD DS installation. If you plan to
use Active Directory–integrated DNS, click Next. If you have an existing DNS infrastructure
and you do not want this domain controller to be a DNS server, clear the DNS server check
box, and then click Next.

If you do not have static IPv4 and IPv6 addresses assigned to your network adapters, a warning
message might appear advising you to set static addresses for both of these protocols before you
can continue. If you have assigned a static IPv4 address to your network adapter and your
organization does not use IPv6, you can ignore this message and click, Yes, the computer will use a
dynamically assigned IP address (not recommended).

Important

We recommend that you not disable the IPv6 protocol.

If the wizard cannot create a delegation for the DNS server, it displays a message to indicate that you
can create the delegation manually. To continue, click Yes.

16. On the Location for Database, Log Files, and SYSVOL page, type or browse to the volume
and folder locations for the database file, the directory service log files, and the SYSVOL files,
and then click Next.
Windows Server Backup backs up the directory service by volume. For backup and recovery
efficiency, store these files on separate volumes that do not contain applications or other
nondirectory files.

17. On the Directory Services Restore Mode Administrator Password page, type and confirm
the restore mode password, and then click Next. This password must be used to start AD DS
in Directory Service Restore Mode for tasks that must be performed offline.

18. On the Summary page, review your selections. Click Back to change any selections, if
necessary.

To save the selected settings to an answer file that you can use to automate subsequent AD DS
operations, click Export settings. Type the name for your answer file, and then click Save.

When you are sure that your selections are accurate, click Next to install AD DS.

19. You can either select the Reboot on completion check box to have the server restart
automatically or you can restart the server to complete the AD DS installation when you are
prompted to do so.

Uninstalling AD

1. Click Start, click Run, type dcpromo, and then press ENTER.

2. On the Welcome to the Active Directory Domain Services Installation Wizard page, click
Next.

3. On the Delete the Domain page, select the option to delete the domain and forest. Before
you continue, read the instructions for managing the removal of cryptographic keys and the
decryption of Encrypting File System (EFS)–encrypted files, and perform these actions, if
necessary. When you are sure that you have completed all security tasks, click Next.

4. If the domain controller has application directory partitions, on the Application Directory
Partitions page, view the application directory partitions in the list, and then remove or
retain application directory partitions, as follows:

o If you do not want to retain any application directory partitions that are stored on
the domain controller, click Next.

o If you want to retain any application directory partition that an application has
created on the domain controller, use the application that created the partition to
remove it, and then click Update List to update the list.

5. On the Confirm Deletion page, select the option to delete all application directory partitions
on the domain controller, and then click Next.

6. On the Remove DNS Delegation page, verify that the Delete the DNS delegations pointing
to this server check box is selected, and then click Next.

7. If necessary, enter administrative credentials for the server that hosts the DNS zones that
contain the DNS delegation for this server, and then click OK.

8. On the Administrator Password page, type and confirm a secure password for the local
Administrator account, and then click Next.
9. On the Summary page, review your selections, and then click Next to remove AD DS.

10. When you are prompted, restart the server to complete the removal of AD DS.

11. Open Server Manager. Click Start, point to Administrative Tools, and then click Server
Manager.

12. In Roles Summary, click Remove Roles.

13. If necessary, review the information on the Before You Begin page and then click Next.

14. On the Remove Server Roles page, clear the Active Directory Domain Services check box,
and then click Next.

15. On the Confirm Removal Selections page, click Remove.

16. On the Removal Results page, click Close, and then click Yes to restart the server.

Understanding Active Directory Domain Services Functional Levels


Functional levels determine the available Active Directory Domain Services (AD DS) domain or forest
capabilities. They also determine which Windows Server operating systems you can run on domain
controllers in the domain or forest. However, functional levels do not affect which operating systems
you can run on workstations and member servers that are joined to the domain or forest.

When you deploy AD DS, set the domain and forest functional levels to the highest value that your
environment can support. This way, you can use as many AD DS features as possible. For example, if
you are sure that you will never add domain controllers that run Windows Server 2003 to the
domain or forest, select the Windows Server 2008 functional level during the deployment process.
However, if you might retain or add domain controllers that run Windows Server 2003, select the
Windows Server 2003 functional level.

When you deploy a new forest, you are prompted to set the forest functional level and then set the
domain functional level. You cannot set the domain functional level to a value that is lower than the
forest functional level. For example, if you set the forest functional level to Windows Server 2008,
you can set the domain functional level only to Windows Server 2008. In this case, the
Windows 2000 native and Windows Server 2003 domain functional level values are not available. In
addition, all domains that you subsequently add to that forest have the Windows Server 2008
domain functional level by default.

You can set the domain functional level to a value that is higher than the forest functional level. For
example, if the forest functional level is Windows Server 2003, you can set the domain functional
level to Windows Server 2003or higher.

The following sections describe the features that are available at the different functional levels.
Features that are available at domain functional levels

The following table shows the features that are available at each domain functional level.

Domain Supported domain


functional Available features controller operating
level systems

All of the default AD DS features and the following


directory features are available:

Universal groups for both distribution and


security groups.

Group nesting

Group conversion, which allows conversion


between security and distribution groups

Security identifier (SID) history Windows


Server 2008 R2
Note
Windows
Windows 2000 Server 2008
In Windows Server 2008 R2, the Personal Virtual
native
Desktop feature was introduced. It requires the Windows
Windows 2000 native domain functional level. Server 2003
To deploy personal virtual desktops, your schema for Windows 2000
the Active Directory forest must be at least Windows
Server 2008. To use the added functionality provided
by the Personal Virtual Desktop tab in the User
Account Properties dialog box in Active Directory
Users and Computers, you must run Active Directory
Users and Computers from a computer running
Windows Server 2008 R2 or a computer running
Windows 7 that has Remote Server Administration
Tools (RSAT) installed.

All the default AD DS features, all the features that are Windows Server
available at the Windows 2000 native domain 2012 R2
functional level, and the following features are
Windows Server
available:
2012
Windows The domain management tool, Netdom.exe,
Server 2003 Windows
which makes it possible for you to rename
Server 2008 R2
domain controllers
Windows
Logon time stamp updates
Server 2008
ThelastLogonTimestamp attribute is updated Windows
with the last logon time of the user or Server 2003
computer. This attribute is replicated within
the domain.

The ability to set the userPassword attribute as


the effective password on inetOrgPerson and
user objects

The ability to redirect Users and Computers


containers

By default, two well-known containers are


provided for housing computer and user
accounts, namely, cn=Computers,<domain
root> and cn=Users,<domain root>. This
feature allows the definition of a new, well-
known location for these accounts.

The ability for Authorization Manager to store


its authorization policies in AD DS

Constrained delegation

Constrained delegation makes it possible for


applications to take advantage of the secure
delegation of user credentials by means of
Kerberos-based authentication.

You can restrict delegation to specific


destination services only.

Selective authentication

Selective authentication makes it is possible for


you to specify the users and groups from a
trusted forest who are allowed to authenticate
to resource servers in a trusting forest.

All of the default AD DS features, all of the features


from the Windows Server 2003 domain functional Windows Server
level, and the following features are available: 2012 R2

Distributed File System (DFS) replication Windows Server


Windows support for the Windows Server 2003 System 2012
Server 2008 Volume (SYSVOL)
Windows
Server 2008 R2
DFS replication support provides more robust
and detailed replication of SYSVOL contents. Windows
Server 2008
Note
Beginning with Windows Server 2012 R2, File
Replication Service (FRS) is deprecated. A new
domain that is created on a domain controller
that runs at least Windows Server 2012 R2
must be set to the Windows Server 2008
domain functional level or higher.

Domain-based DFS namespaces running in


Windows Server 2008 Mode, which includes
support for access-based enumeration and
increased scalability. Domain-based
namespaces in Windows Server 2008 mode
also require the forest to use the Windows
Server 2003 forest functional level.

Advanced Encryption Standard (AES 128 and


AES 256) support for the Kerberos protocol. In
order for TGTs to be issued using AES, the
domain functional level must be Windows
Server 2008 or higher and the domain
password needs to be changed.

Last Interactive Logon Information

Last Interactive Logon Information displays the


following information:

o The total number of failed logon


attempts at a domain-joined
Windows Server 2008 server or a
Windows Vista workstation

o The total number of failed logon


attempts after a successful logon to a
Windows Server 2008 server or a
Windows Vista workstation

o The time of the last failed logon


attempt at a Windows Server 2008 or a
Windows Vista workstation

o The time of the last successful logon


attempt at a Windows Server 2008
server or a Windows Vista workstation

Fine-grained password policies


Fine-grained password policies make it possible
for you to specify password and account
lockout policies for users and global security
groups in a domain.

Personal Virtual Desktops

To use the added functionality provided by the


Personal Virtual Desktop tab in the User
Account Properties dialog box in
Active Directory Users and Computers, your
AD DS schema must be extended for Windows
Server 2008 R2 (schema object version = 47).

All default Active Directory features, all features from


the Windows Server 2008 domain functional level, plus
the following features:

Authentication mechanism assurance, which


packages information about the type of logon
method (smart card or user name/password)
that is used to authenticate domain users
inside each user’s Kerberos token. When this
Windows Server
feature is enabled in a network environment
2012 R2
that has deployed a federated identity
Windows management infrastructure, such as Windows Server
Server 2008 R2 Active Directory Federation Services (AD FS), 2012
the information in the token can then be
Windows
extracted whenever a user attempts to access
Server 2008 R2
any claims-aware application that has been
developed to determine authorization based
on a user’s logon method.

Automatic SPN management for services


running on a particular computer under the
context of a Managed Service Account when
the name or DNS host name of the machine
account changes.

The KDC support for claims, compound


authentication, and Kerberos armoring KDC Windows Server
Windows administrative template policy has two settings 2012 R2
Server 2012 (Always provide claims and Fail unarmored Windows Server
authentication requests) that require Windows Server 2012
2012 domain functional level.

DC-side protections for Protected Users.


Windows Windows Server
Protected Users authenticating to a Windows
Server 2012 R2 2012 R2
Server 2012 R2 domain can no longer:
o Authenticate with NTLM
authentication

o Use DES or RC4 cipher suites in


Kerberos pre-authentication

o Be delegated with unconstrained or


constrained delegation

o Renew user tickets (TGTs) beyond the


initial 4 hour lifetime

Authentication Policies

New forest-based Active Directory policies


which can be applied to accounts in Windows
Server 2012 R2 domains to control which hosts
an account can sign-on from and apply access
control conditions for authentication to
services running as an account.

Authentication Policy Silos

New forest-based Active Directory object,


which can create a relationship between user,
managed service and computer, accounts to be
used to classify accounts for authentication
policies or for authentication isolation.

Features that are available at forest functional levels

The following table shows the features that are available at each forest functional level.

Forest Supported domain


Available features
functional level controllers

Windows
Server 2008 R2

Windows
Windows 2000 All of the default AD DS features are available. Server 2008

Windows
Server 2003

Windows 2000

Windows All of the default AD DS features, and the following Windows Server
Server 2003 features, are available: 2012 R2

Forest trust Windows Server


2012
Domain rename
Windows
Linked-value replication
Server 2008 R2

Linked-value replication makes it possible for Windows


you to change group membership to store and Server 2008
replicate values for individual members
Windows
instead of replicating the entire membership
Server 2003
as a single unit. Storing and replicating the
values of individual members uses less
network bandwidth and fewer processor
cycles during replication, and prevents you
from losing updates when you add or remove
multiple members concurrently at different
domain controllers.

The ability to deploy a read-only domain


controller (RODC)

Improved Knowledge Consistency Checker


(KCC) algorithms and scalability

Theintersite topology generator (ISTG) uses


improved algorithms that scale to support
forests with a greater number of sites than
AD DS can support at the Windows 2000 forest
functional level. The improved ISTG election
algorithm is a less-intrusive mechanism for
choosing the ISTG at the Windows 2000 forest
functional level.

The ability to create instances of the dynamic


auxiliary class named dynamicObject in a
domain directory partition

The ability to convert an inetOrgPerson object


instance into a User object instance, and to
complete the conversion in the opposite
direction

The ability to create instances of new group


types to support role-based authorization.

These types are called application basic groups


and LDAP query groups.

Deactivation and redefinition of attributes and


classes in the schema. The following attributes
can be reused: ldapDisplayName,
schemaIdGuid, OID, and mapiID.

Domain-based DFS namespaces running in


Windows Server 2008 Mode, which includes
support for access-based enumeration and
increased scalability.

Windows Server
2012 R2
All of the features that are available at the
Windows Server 2003 forest functional level, but no Windows Server
Windows additional features are available. All domains that are 2012
Server 2008 subsequently added to the forest, however, operate at Windows
the Windows Server 2008 domain functional level by Server 2008 R2
default.
Windows
Server 2008

All of the features that are available at the


Windows Server 2003 forest functional level, plus the
following features:

Active Directory Recycle Bin, which provides


the ability to restore deleted objects in their Windows Server
entirety while AD DS is running. 2012 R2

Windows All domains that are subsequently added to the forest Windows Server
Server 2008 R2 will operate at the Windows Server 2008 R2 domain 2012
functional level by default.
Windows
If you plan to include only domain controllers that run Server 2008 R2
Windows Server 2008 R2 in the entire forest, you
might choose this forest functional level for
administrative convenience. If you do, you will never
have to raise the domain functional level for each
domain that you create in the forest.

All of the features that are available at the


Windows Server 2008 R2 forest functional level, but no Windows Server
Windows additional features. 2012 R2
Server 2012 All domains that are subsequently added to the forest Windows Server
will operate at the Windows Server 2012 domain 2012
functional level by default.

All of the features that are available at the


Windows Windows Server
Windows Server 2012 forest functional level, but no
Server 2012 R2 2012 R2
additional features.
All domains that are subsequently added to the forest
will operate at the Windows Server 2012 R2 domain
functional level by default.

Guidelines for raising domain and forest functional levels

The following guidelines apply to raising the domain or forest functional levels:

You must be a member of the Domain Admins group to raise the domain functional level.

You must be a member of the Enterprise Admins group to raise the forest functional level.

You can raise the domain functional level on the primary domain controller (PDC) emulator
operations master only. The AD DS administrative tools that you use to raise the domain
functional level (the Active Directory Domains and Trusts snap-in and the Active Directory
Users and Computers snap-in) automatically target the PDC emulator when you raise the
domain functional level.

You can raise the forest functional level on the schema operations master only.
Active Directory Domains and Trusts automatically targets the schema operations master
when you raise the forest functional level.

You can raise the functional level of a domain only if all domain controllers in the domain
run the version or versions of Windows Server that the new functional level supports.

You can raise the functional level of a forest only if all domain controllers in the forest run
the version or versions of Windows Server that the new functional level supports.

You cannot set the domain functional level to a value that is lower than the forest functional
level, but you can set it to a value that is equal to or higher than the forest functional level.

With versions of Windows Server that are earlier than Windows Server 2008 R2, you cannot
roll back or lower a functional level under any circumstances. If you have to revert to a lower
functional level with a version of Windows Server that is earlier than Windows
Server 2008 R2, you must rebuild the domain or forest or restore it from a backup copy.

After you set the domain functional level, you cannot roll back or lower the domain
functional level except in the cases listed in the following table. The domain functional level
can be lowered only by using Windows PowerShell.

Current domain Current forest


Rollback options
functional level functional level

Windows Server 2012 Windows Server 2012 None unless you first lower forest functional
R2 R2 level

Windows Server 2012 Windows Server 2012 Windows Server 2012


R2

Windows Server 2012 Windows Server 2008 Windows Server 2012 or Windows Server
R2 R2 2008 R2

Windows Server 2012 Windows Server 2012, Windows Server 2008


Windows Server 2008
R2 R2, or Windows Server 2008

None unless you first lower forest functional


Windows Server 2012 Windows Server 2012
level

Windows Server 2008


Windows Server 2012 Windows Server 2008 R2
R2

Windows Server 2008 R2 or Windows Server


Windows Server 2012 Windows Server 2008
2008

Windows Server 2008 Windows Server 2008 None unless you first lower forest functional
R2 R2 level

Windows Server 2008


Windows Server 2008 Windows Server 2008
R2

Windows Server 2008 Windows Server 2008


None
or lower or lower

After you set the forest functional level, you cannot roll back or lower the forest functional
level except in the cases listed in the following table. The forest functional level can be
lowered only by using Windows PowerShell.

Current forest Recycle Bin


Rollback options
functional level enabled?

Windows Server 2012


Yes Windows Server 2012 or Windows Server 2008 R2
R2

Windows Server 2012 Windows Server 2012, Windows Server 2008, or


No
R2 Windows Server 2008 R2

Windows Server 2012 Yes Windows Server 2008 R2

Windows Server 2012 No Windows Server 2008 R2 or Windows Server 2008

Windows Server 2008


Yes None
R2

Windows Server 2008


No Windows Server 2008
R2
References:
http://technet.microsoft.com/en-us/library/cc771433(v=ws.10).aspx - Scenarios for Installing AD DS

http://technet.microsoft.com/en-us/library/cc771188(v=ws.10).aspx - Requirements for installing


AD DS

http://technet.microsoft.com/en-us/library/cc772464(v=ws.10).aspx - Insalling a New Forest

http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-
levels(v=ws.10).aspx - Understanding Active Directory Domain Services Functional Levels

Labs for Modules 1, 2 and 3:


Install and Configure an Active Directory Domain Services, for a single domain Forest setup.

For Further Reading and Exploring in the labs:

Install the AD using the Command Line


Install the AD using an answer file
Explore the following:
Installing a New Child Domain
Installing a New Domain Tree
Installing a New Additional Domain Controller
What is a RODC Domain Controller, Install one.

Module 4: Active Directory Administration


Introduction to various AD Snap-ins and their functions
When you install Active Directory Domain Services (AD DS) on a computer to create a domain
controller, the administrative tools that you use to manage AD DS on the domain controller are
installed automatically. If you want to manage domain controllers remotely from a computer that is
not a domain controller, you can install Remote Server Administration Tools (RSAT) on a member
server that is running Windows Server 2008 or Windows Server 2008 R2.

To install Active Directory Domain Services Tools on a member server

1. Open Server Manager. To open Server Manager, on the Start menu, click Administrative
Tools, and then click Server Manager.

2. In the console tree, right-click Features, and then click Add Features.

3. In Features, expand Remote Service Administration Tools and Role Administration Tools:

1. On a Windows Server 2008 member server, expand Active Directory Domain


Services Tools, and then click Active Directory Domain Controllers Tools.

2. On a Windows Server 2008 R2 member server, expand AD DS and AD LDS Tools,


expand AD DS Tools, and then click AD DS Snap-Ins and Command-Line Tools.
4. Click Next, review the installation information, and then click Install.

5. If you are prompted to restart the computer, restart it before you continue with the next
step. Click Yes to restart the server, or click No to restart the server later.

6. After the server restarts, on the Installation Results page of the Resume Configuration
Wizard, click Close. The Active Directory Domain Services Administration Tools are available
on the Administrative Tools menu.

When Administration Tools installation is complete, snap-ins and tools to manage corresponding
roles, role services, and features are available on your computer.

Let us now focus on a few tools and snap-ins that are used to administer the Active Directory
installation.

Following are the snap-ins that are commonly used to administer Active Directory Domain Services

- Active Directory Users and Computers


- Active Directory Domains and Trusts
- Active Directory Sites and Services
- ADSI Edit
- Schema Manager
- Group Policy Management Console

Active Directory Users and Computers


Active Directory® Users and Computers is a Microsoft Management Console (MMC) snap-in that you
can use to administer and publish information in the directory. The snap-in can be used to perform
the following tasks:

- Manage Users
- Manage Groups
- Manage Computers
- Manage Domains
- Manage Organizational Units
Managing Users using Active Directory Users and Computers Snap-in
You can use Active Directory Users and Computers to create new user accounts or manage existing
user accounts.

Active Directory user accounts represent physical entities, such as people. You can also use user
accounts as dedicated service accounts for some applications.

User accounts are also referred to as security principals. Security principals are directory objects that
are automatically assigned security identifiers (SIDs), which can be used to access domain resources.
A user account primarily:

Authenticates the identity of a user.


A user account enables a user to log on to computers and domains with an identity that the
domain can authenticate. Each user who logs on to the network should have his or her own
unique user account and password. To maximize security, avoid having multiple users
sharing one account.

Authorizes or denies access to domain resources.


After a user is authenticated, the user is authorized or denied access to domain resources
based on the explicit permissions that are assigned to that user on the resource.

User accounts

The Users container in the Active Directory Users and Computers snap-in 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 following table describes each default user account on
domain controllers.

Default user account Description

The Administrator account has full control of the domain. It can assign user
rights and access control permissions to domain users as necessary. Use this
account only for tasks that require administrative credentials. We
recommend that you set up this account with a strong password.

The Administrator account is a default member of the following


Active Directory groups: Administrators, Domain Admins, Enterprise Admins,
Group Policy Creator Owners, and Schema Admins. The Administrator
account can never be deleted or removed from the Administrators group, but
Administrator it can be renamed or disabled. Because the Administrator account is known
to exist on many versions of Windows, renaming or disabling this account will
make it more difficult for malicious users to try to gain access to it.

The Administrator account is the first account that is created when you set up
a new domain with the Active Directory Domain Services Installation Wizard.

Important

When the Administrator account is disabled, it can still be used to gain


access to a domain controller with Safe Mode.

People who do not have an actual account in the domain can use the Guest
account. A user whose account is disabled (but not deleted) can also use the
Guest account. The Guest account does not require a password.

Guest You can set rights and permissions for the Guest account just like any user
account. By default, the Guest account is a member of the built-in Guests
group and the Domain Guests global group, which allows a user to log on to a
domain. The Guest account is disabled by default, and we recommend that it
stay disabled.

The primary account for establishing a Remote Assistance session. This


HelpAssistant
account is created automatically when you request a Remote Assistance
(installed with a
session. It has limited access to the computer. The HelpAssistant account is
Remote Assistance
managed by the Remote Desktop Help Session Manager service. This account
session)
is automatically deleted if no Remote Assistance requests are pending.

Securing user accounts

If built-in account rights and permissions are not modified or disabled by a network administrator,
they can be used by a malicious user (or service) to illegally log on to a domain using the
Administrator account or Guest account. A good security practice for protecting these accounts is to
rename or disable them. Because it retains its 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 advantages of user authentication and authorization, use Active Directory
Users and Computers to create an individual user account for each user who will participate in your
network. You can then add each user account (including the Administrator account and Guest
account) to a group to control the rights and permissions that are assigned to the account. When
you have accounts and groups that are appropriate for your network, you ensure that you can
identify users that log on to your network and that they have access only to 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 password guessing and
dictionary attacks on passwords. An account lockout policy decreases the possibility of an attacker
compromising your domain through repeated logon attempts. An account lockout policy determines
how many failed logon attempts a user account can have before it is disabled.

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
options in the following table to configure password settings and security-specific information for
user accounts.

Account option Description

User must change Forces a user to change his or her password the next time that the user logs
password at next on to the network. Enable this option when you want to ensure that the
logon user will be the only person that knows the password.

Prevents a user from changing his or her password. Enable this option when
User cannot change
you want to maintain control over a user account, such as a Guest account
password
or temporary account.

Password never Prevents a user password from expiring. We recommend that service
expires accounts have this option enabled and use strong passwords.

Store passwords using Allows a user to log on to a Windows network from Apple computers. If a
reversible encryption user is not logging on from an Apple computer, do not enable this option.

Prevents a user from logging on with the selected account. Many


Account is disabled administrators use disabled accounts as templates for common user
accounts.

Smart card is required Requires that a user possess a smart card to log on to the network
for interactive logon interactively. The user must also have a smart card reader attached to their
computer and a valid personal identification number (PIN) for the smart
card. When this option is enabled, the password for the user account is
automatically set to a random and complex value.

Allows a service running under this account to perform operations on behalf


of other user accounts on the network. A service running under a user
account (otherwise known as a service account) that is trusted for
delegation can impersonate a client to gain access to resources on the
computer where the service is running or to resources on other computers.
In a forest that is set to the Windows Server 2008 R2 functional level or
above, this option is on the Delegation tab. It is available only for accounts
that have been assigned service principal names (SPNs), as set with the
Account is trusted for setspn command. (Open a command window, and then type setspn .) This is
delegation a security-sensitive capability; assign it cautiously.

This option is available only on domain controllers running Windows


Server 2008 R2 or above where the domain functionality is set to
Windows® 2000 mixed or Windows 2000 native. On domain controllers
running Windows Server 2008 or above where the domain functional level is
set to Windows Server 2008 or above forest functional Level, use the
Delegation tab in the user properties dialog box to configure delegation
settings. The Delegation tab appears only for accounts that have an
assigned SPN.

Account is sensitive
You can use this option if the account, for example a Guest or temporary
and cannot be
account, cannot be assigned for delegation by another account.
delegated

Provides support for the Data Encryption Standard (DES). DES supports
multiple levels of encryption, including Microsoft Point-to-Point Encryption
Use DES encryption
(MPPE) Standard (40-bit), MPPE Standard (56-bit), MPPE Strong (128-bit),
types for this account
Internet Protocol security (IPsec) DES (40-bit), IPsec 56-bit DES, and IPsec
Triple DES (3DES

Provides support for alternative implementations of the Kerberos protocol.


Do not require
However, use caution when you enable this option, because Kerberos
Kerberos
preauthentication provides additional security and requires time
preauthentication
synchronization between the client and the server.

To create a new user account using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

To open Active Directory Users and Computers in Windows Server® 2012, click Start , type dsa.msc .

2. In the console tree, right-click the folder in which you want to add a user account.

Where?
o Active Directory Users and Computers\ domain node \ folder

3. Point to New , and then click User .

For interoperability with other directory services, you can click InetOrgPerson instead.

4. In First name , type the user's first name.

5. In Initials , type the user's initials.

6. In Last name , type the user's last name.

7. Modify Full name to add initials or reverse the order of first and last names.

8. In User logon name , type the user logon name, click the user principal name (UPN) suffix in
the drop-down list, and then click Next .

9. In Password and Confirm password , type the user's password, and then select the
appropriate password options.

To reset a user password using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

To open Active Directory Users and Computers in Windows Server® 2012, click Start , type dsa.msc .

2. In the console tree, click Users .

Where?

o Active Directory Users and Computers\ domain node \Users

Or, click the folder that contains the user account.

3. In the details pane, right-click the user whose password you want to reset, and then click
Reset Password .

4. Type and then confirm the password.

5. If you want to require the user to change this password at the next logon process, select the
User must change password at next logon check box.

To copy a user account

1. To open Active Directory Users and Computers, click Start, click Control Panel, double-click
Administrative Tools, and then double-click Active Directory Users and Computers.
2. In the console tree, click Users.
a. Where?
i. Active Directory Users and Computers\ domain node \Users
3. In the details pane, right-click the user account that you want to copy, and then click Copy .
4. In First name, type the user's first name.
5. In Last name, type the user's last name.
6. Modify Full name to add initials or reverse the order of the first and last names.
7. In User logon name, type the user logon name, click the user principal name (UPN) suffix in
the drop-down list, and then click Next.
8. In Password and Confirm password, type the user's password, and then select the
appropriate password options.
9. If the user account from which the new user account was copied was disabled, click Account
is disabled to enable the new account.

To move a user account using the Windows interface

10. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .
11. In the console tree, click Users .
a. Where?
i. Active Directory Users and Computers\domain node\Users
12. Or, click the folder that contains the user account.
13. In the details pane, right-click the user that you want to move, and then click Move .
14. In the Move dialog box, click the folder to which you want to move the user account.

To delete a user account using the Windows interface

1. To open Active Directory Users and Computers, click Start, click Control Panel, double-click
Administrative Tools, and then double-click Active Directory Users and Computers.
2. In the console tree, click Users.
a. Where?
i. Active Directory Users and Computers\ domain node \Users
3. Or, click the folder that contains the user account.
4. In the details pane, right-click the user account, and then click Delete.

Explore Yourself:

- Setting Logon Hours for a user account


- Disabling or Enabling a user account
- Change a User’s primary group
Managing Groups using Active Directory Users and Computers Snap-in
You can use Active Directory Users and Computers to create new user accounts or manage existing
Active Directory 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.

Groups in Active Directory Domain Services (AD DS) are directory objects that reside in a domain and
in organizational unit (OU) container objects. AD DS provides a set of default groups at installation. It
also provides an option to create groups.

You can use groups in AD DS to:

Simplify administration by assigning permissions on a shared resource to a group, rather


than to individual users. Assigning permissions to a group assigns the same access to the
resource to all members of that group.

Delegate administration by assigning user rights once to a group through Group Policy. You
can then add members to the group that you want to have the same rights as the group.

Create e-mail distribution lists.

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. The group type determines whether you can
use a group to assign permissions from a shared resource (for security groups) or use a group for e-
mail distribution lists only (for distribution groups).

There are also groups for which you cannot modify or view the memberships. These groups are
referred to as special identities. They represent different users at different times, depending on the
circumstances. For example, the Everyone group is a special identity that represents all current
network users, including guests and users from other domains.
The following sections provide additional information about group accounts in AD DS.

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

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 the following:

All the user rights that are assigned to the group

All the permissions that are assigned to the group on any shared resources

Default groups are located in the Builtin container and the Users container. The default groups in the
Builtin container have a group scope of Builtin Local. Their group scope and group type cannot be
changed. The Users container contains groups that are defined with global scope and groups that
are defined with domain local scope. You can move groups that are located in these containers to
other groups or OUs within the domain, but you cannot move them to other domains.

Understanding group scope

Groups are characterized by a scope that identifies the extent to which the group is applied in the
domain tree or forest. There are three group scopes: domain local, global, and universal.

Understanding domain local groups

Members of domain local groups can include other groups and accounts from Windows Server 2003,
Windows 2000, Windows NT, Windows Server 2008, and Windows Server 2008 R2, and Windows
Server® 2012 domains. Members of these groups can be assigned permissions only within a domain.

Groups with domain local scope help you define and manage access to resources within a single
domain. These groups can have the following as their members:

Groups with global scope

Groups with universal scope

Accounts

Other groups with domain local scope

A mixture of any of the above

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
again have to 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 add this group to the group that has 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.

Understanding global groups

Members of global groups can include other groups and accounts only from the domain in which the
group is defined. Members of these groups can be assigned permissions in any domain in the forest.

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.

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 there is a group with global scope called GLAccounting in the UnitedStates domain,
there should also be a group called GLAccounting in the Europe domain (unless the accounting
function does not exist in the Europe domain).

Important

We strongly recommend 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.

Understanding universal groups

Members of universal groups can include other groups and accounts from any domain in the domain
tree or forest. Members of these groups can be assigned permissions in any domain in the domain
tree or forest.

Use groups with universal scope to consolidate groups that span domains. To do this, add the
accounts to groups with global scope and nest these groups within groups having 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. You can then use the UAccounting group anywhere in the enterprise. Any
changes in the membership of the individual GLAccounting groups will not cause replication of the
UAccounting group.

Do not change the membership of a group with universal scope frequently. Any changes to the
membership of this type of group cause the entire membership of the group to be replicated to
every global catalog in the forest.

Understanding group types


There are two types of groups in AD DS: 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.

You can use distribution groups only with e-mail applications (such as Microsoft
Exchange Server 2007) 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.

When they are used with care, security groups provide an efficient way to assign access to resources
on your network. By using security groups, you can:

Assign user rights to security groups in AD DS.

User rights are assigned to a security group 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 that AD DS 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 back up and restore files and
directories on each domain controller in the domain.

Assign permissions to security groups on resources.

Permissions are different from user rights. Permissions determine who can access a shared
resource, and they determine the level of access, such as Full Control. You can use security
groups to manage access and permissions to a shared resource. Some permissions that are
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.

Like distribution groups, security groups can also be used as e-mail entities. Sending an e-mail
message to the group sends the message to all the members of the group.

Special identities

In addition to the groups in the Users container and Builtin container, servers running Windows
Server 2012, Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003 include
several special identities. For convenience, these identities are generally referred to as groups. These
special groups do not have specific memberships that can be modified. However, they can represent
different users at different times, depending on the circumstances. The following groups represent
special identities:

Anonymous Logon

This group represents users and services that access a computer and its resources through
the network without using an account name, password, or domain name. On computers
running Windows NT and earlier, the Anonymous Logon group is a default member of the
Everyone group. On computers running Windows Server 2012, Windows Server 2008 R2,
Windows Server 2008 or Windows Server 2003, the Anonymous Logon group is not a
member of the Everyone group by default.

Everyone
This group represents all current network users, including guests and users from other
domains. Whenever a user logs on to the network, the user is added automatically to the
Everyone group.

Network

This group represents users who are currently accessing a given resource over the network,
as opposed to users who access a resource by logging on locally at the computer where the
resource is located. Whenever a user accesses a given resource over the network, the user is
added automatically to the Network group.

Interactive

This group represents all users who are currently logged on to a particular computer and
who are accessing a given resource that is located on that computer, as opposed to users
who access the resource over the network. Whenever a user accesses a given resource on
the computer to which they are currently logged on, the user is added automatically to the
Interactive group.

Although the special identities can be assigned rights and permissions to resources, the
memberships cannot be modified or viewed. Group scopes do not apply to special identities. Users
are assigned automatically to these special identities whenever they log on or access a particular
resource.

Understanding where groups can be created

In AD DS, groups are created in domains. You use Active Directory Users and Computers to create
groups. With the necessary permissions, you can create groups in the root domain of the forest, in
any other domain in the forest, or in an OU.

Besides the domain in which it is created, a group is also characterized by its scope. The scope of a
group determines the following:

The domain from which members can be added

The domain in which the rights and permissions that are assigned to the group are valid

Choose the particular domain or OU where you create a group based on the administration that is
required for the group. For example, if your directory has multiple OUs, each of which has a different
administrator, you may want to create groups with global scope within those OUs so that the
administrators can manage group membership for users in their respective OUs. If groups are
required for access control outside the OU, you can nest the groups in the OU into groups with
universal scope (or other groups with global scope) that you can use elsewhere in the forest.

If the domain functional level is set to Windows 2000 native or higher, the domain contains a
hierarchy of OUs, and administration is delegated to administrators at each OU, it may be more
efficient to nest groups with global scope. For example, if OU1 contains OU2 and OU3, a group with
global scope in OU1 can have as its members groups with global scope in OU2 and OU3. In OU1, the
administrator can add or remove group members from OU1, and the administrators of OU2 and OU3
can add or remove group members for accounts from their own OUs without having administrative
rights for the group with global scope in OU1.
Note

You can move groups within a domain. However, only groups with universal scope can be moved
from one domain to another. The rights and permissions that are assigned to a group with universal
scope are lost when the group is moved to another domain, and new assignments must be made.

Create a New Group

To create a new group account using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, right-click the folder under which you want to create a new group.

Where?

o Active Directory Users and Computers\ domain node \ folder

3. Point to New , and then click Group .

4. Type the name of the new group.

By default, the name that you type is also entered as the pre–Windows 2000 name of the new
group.

5. In Group scope , click one of the options.

6. In Group type , click one of the options.

Add a Member to a Group

To add a member to a group using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, click the folder that contains the group to which you want to add a
member.

Where?

o Active Directory Users and Computers\ domain node \ folder that contains the group

3. In the details pane, right-click the group, and then click Properties .

4. On the Members tab, click Add .

5. In Enter the object names to select , type the name of the user, group, or computer that you
want to add to the group, and then click OK .

Convert a Group to Another Type

To convert a group to another group type using the Windows interface


1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, click the folder that contains the group that you want to convert to
another group type.

Where?

o Active Directory Users and Computers\ domain node \ folder that contains the group

3. In the details pane, right-click the group, and then click Properties .

4. On the General tab, under Grouptype , click the group type.

Change Group Scope

To change group scope using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, click the folder that contains the group for which you want to change the
group scope.

Where?

o Active Directory Users and Computers\ domain node \ folder that contains the group

3. In the details pane, right-click the group, and then click Properties .

4. On the General tab, under Group scope , select the group scope.

Delete a Group

To delete a group account using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, click the folder that contains the group that you want to delete.

Where?

o Active Directory Users and Computers\ domain node \ folder that contains the group

3. In the details pane, right-click the group, and then click Delete .

Find Groups in Which a User is a Member

To find groups in which a user is a member using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .
2. In the console tree, click Users .

Where?

o Active Directory Users and Computers\ domain node \Users

Or, click the folder that contains the user account whose group membership you want to view.

3. In the details pane, right-click a user account, and then click Properties .

4. Click the Member Of tab.

Explore Yourself:

- Assign User Rights to a Group in AD DS

Managing Computers using Active Directory Users and Computers Snap-in


Every computer running Windows NT, Windows 2000, Windows XP, Windows Vista, or Windows 7 or
server running Windows Server 2003, Windows Server 2008, Windows Server® 2012 or Windows
Server 2008 R2 that joins a domain has a computer account. Like user accounts, computer accounts
provide a means for authenticating and auditing access to the network and to domain resources.
Each computer account must be unique.

You can add, disable, reset, and delete user and computer accounts with the Active Directory Users
and Computers snap-in. You can also create a computer account when you join a computer to a
domain.

When the domain functional level is set to Windows Server 2008, Windows Server 2008 R2, or
Windows Server 2012a lastLogonTimestamp attribute is used to track the last logon time of a user
or computer account. This attribute is replicated within the domain, and it can provide you with
important information regarding the history of a user or computer.

Understanding computer names

Each computer account that is created in Active Directory Domain Services (AD DS) has a relative
distinguished name, a pre–Windows 2000 computer name (Security Accounts Manager (SAM)
account name), a primary Domain Name System (DNS) suffix, a DNS host name, and a service
principal name (SPN). The administrator enters the computer name when he or she creates the
computer account. This computer name is used as the Lightweight Directory Access Protocol (LDAP)
relative distinguished name.

AD DS 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. This 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).

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 build a restricted list of allowed suffixes by creating the msDS-
AllowedDNSSuffixes attribute in the domain object container. The domain administrator creates
and manages this attribute with Active Directory Service Interfaces (ADSI) or LDAP.

The SPN is a multivalue attribute. It is usually built from the DNS name of the host. The SPN is used
in the process of mutual authentication between the client and the server hosting a particular
service. The client finds a computer account based on the SPN of the service to which it is trying to
connect. Members of the Domain Admins group can modify the SPN.

Create a New Computer Account

To create a new computer account using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, right-click Computers .

Where?

o Active Directory Users and Computers\ domain node \Computers

Or, right-click the folder in which you want to add the computer.

3. Point to New , and then click Computer .

4. Type the computer name.

Add a Computer Account to a Group

To add a computer account to a group using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, click Computers .

Where?

o Active Directory Users and Computers\ domain node \Computers

Or, click the folder in which the computer is located.

3. In the details pane, right-click the computer, and then click Properties .

4. On the Member Of tab, click Add .

5. In Enter the object names to select , type the name of a group that you want this computer
to be a member of, and then click OK .
Delete a Computer Account

To delete a computer account using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, click Computers .

Where?

o Active Directory Users and Computers\ domain node \Computers

Or, click the folder in which the computer is located.

3. In the details pane, right-click the computer, and then click Delete .

Move a Computer Account

To move a computer account

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, click Computers .

Where?

o Active Directory Users and Computers\ domain node \Computers

Or, click the folder that contains the computer that you want to move.

3. In the details pane, right-click the computer, and then click Move .

4. In the Move dialog box, click the domain node.

5. Click the folder to which you want to move the computer, and then click OK .

Reset a Computer Account

To reset a computer account using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, click Computers .

Where?

o Active Directory Users and Computers\ domain node \Computers


Or, click the folder that contains the computer that you want to reset.

3. In the details pane, right-click the computer, and then click Reset Account .

Disable or Enable a Computer Account

To disable or enable a computer account using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, click Computers .

Where?

o Active Directory Users and Computers\ domain node \Computers

Or, click the folder that contains the computer account that you want to enable or disable.

3. In the details pane, right-click the desired computer account, and then do one of the
following:

o To disable the account, click Disable Account .

o To enable the account, click Enable Account .

Managing Domains using Active Directory Users and Computers Snap-in


What we have done so far by managing users, groups and computers is management of the local
domain.

Manage a Different Domain

To manage a different domain

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, right-click Active Directory Users and Computers , and then click Change
Domain .

3. Type the domain name.

Or, click Browse , and then select a domain from the list.

Manage the Domain Using a Different Domain Controller

To manage the domain using a different domain controller

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, right-click Active Directory Users and Computers , and then click Change
Domain Controller .

3. Click a domain controller in the list.


Or, click the <Type a Domain Controller name or an IP Address here> field, and then type the name
of a domain controller.

Managing Organizational Units using Active Directory Users and Computers Snap-in
Understanding Organizational Units

A particularly useful type of directory object that is contained within domains is the organizational
unit (OU). OUs are Active Directory containers into which you can place users, groups, computers,
and other OUs. An OU cannot contain objects from other domains.

An OU is the smallest scope or unit to which you can assign Group Policy settings or delegate
administrative authority. Using OUs, you can create containers within a domain that represent the
hierarchical, logical structures in your organization. You can then manage the configuration and use
of accounts and resources based on your organizational model.

OUs can contain other OUs. You can extend a hierarchy of OUs as necessary to model your
organization's hierarchy within a domain. Using OUs helps you minimize the number of domains that
are required for your network.

You can use OUs to create an administrative model that you can scale to any size. A user can have
administrative authority for all OUs in a domain or for a single OU. An administrator of an OU does
not have to have administrative authority for any other OUs in the domain.

Create a New Organizational Unit

To create a new organizational unit using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, right-click the domain name.

3. Point to New , and then click Organizational Unit .


4. Type the name of the organizational unit (OU).

Delete an Organizational Unit

To delete an organizational unit using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, right-click the organizational unit (OU) that you want to delete.

Where?

o Active Directory Users and Computers\ domain node \ organizational unit

3. Click Delete .

Move an Organizational Unit

To move an organizational unit using the Windows interface

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, right-click the organizational unit (OU) that you want to move.

Where?

o Active Directory Users and Computers\ domain node \ organizational unit

3. Click Move , and then click the folder to which you want to move the OU.

Delegate Control of an Organizational Unit

To delegate control of an organizational unit

1. To open Active Directory Users and Computers, click Start , click Control Panel , double-click
Administrative Tools , and then double-click Active Directory Users and Computers .

2. In the console tree, right-click the organizational unit (OU) for which you want to delegate
control.

Where?

o Active Directory Users and Computers\ domain node \ organizational unit

3. Click Delegate Control to start the Delegation of Control Wizard, and then follow the
instructions in the wizard.
Active Directory Domains and Trusts Snap-in

Active Directory® Domains and Trusts is the Microsoft Management Console (MMC) snap-in that you
can use to administer domain trusts, domain and forest functional levels, and user principal name
(UPN) suffixes.

The snap-in can be used to perform the below administrative actions in an AD DS

- Managing Domains and Trusts


- Managing Trusts
- Managing Forest Trusts
Raise the Domain Functional Level

To raise the domain functional level

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .

2. In the console tree, right-click the domain for which you want to raise functional level, and
then click Raise Domain Functional Level .

3. In Select an available domain functional level , select the value and then click Raise .

Raise the Forest Functional Level

To raise the forest functional level

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .

2. In the console tree, right-click Active Directory Domains and Trusts , and then click Raise
Forest Functional Level .

3. In Select an available forest functional level , select the value and then click Raise

Add User Principal Name Suffixes

To add UPN suffixes

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .

2. In the console tree, right-click Active Directory Domains and Trusts , and then click
Properties .

3. On the UPN Suffixes tab, type an alternative UPN suffix for the forest, and then click Add .

4. Repeat step 3 to add additional alternative UPN suffixes.

Managing Trusts using Active Directory Domains and Trusts Snap-in


Understanding Trusts

Trusts

A trust is a relationship, which you establish between domains that makes it possible for users in one
domain to be authenticated by a domain controller in the other domain.

All Active Directory trusts between domains within a forest are transitive, two-way trusts. Therefore,
both domains in a trust relationship are trusted. As shown in the following illustration, this means
that if Domain A trusts Domain B and Domain B trusts Domain C, users from Domain C can access
resources in Domain A (when they are assigned the proper permissions). Only members of the
Domain Admins group can manage trust relationships.

Trust protocols

A domain controller authenticates users and applications using one of two protocols: the Kerberos
version 5 (V5) protocol or NTLM. The Kerberos V5 protocol is the default protocol for computers in
an Active Directory domain. If any computer in a transaction does not support the Kerberos V5
protocol, the NTLM protocol is used.

With the Kerberos V5 protocol, the client requests a ticket from a domain controller in its account
domain to the server in the trusting domain. This ticket is issued by an intermediary that is trusted
by the client and the server. The client presents this trusted ticket to the server in the trusting
domain for authentication.

When a client tries to access resources on a server in another domain using NTLM authentication,
the server that contains the resource must contact a domain controller in the client account domain
to verify the account credentials.

Trusted domain objects

Trusted domain objects (TDOs) are objects that represent each trust relationship within a particular
domain. Each time that a trust is established, a unique TDO is created and stored in its domain (in
the System container). Attributes such as trust transitivity, type, and the reciprocal domain names
are represented in the TDO.

Forest trust TDOs store additional attributes to identify all the trusted namespaces from its partner
forest. These attributes include domain tree names, user principal name (UPN) suffixes, service
principal name (SPN) suffixes, and security identifier (SID) namespaces.

Understanding Trust Types

Trust Types

You can use the New Trust Wizard or the Netdom command-line tool to create four types of trusts:
external trusts, realm trusts, forest trusts, and shortcut trusts. The following table describes these
trust types.
Trust
Transitivity Direction Description
type

Use external trusts to provide access to resources that are


One-way or located on a Windows NT 4.0 domain or a domain that is
External Nontransitive
two-way located in a separate forest that is not joined by a forest
trust.

Use realm trusts to form a trust relationship between a


Transitive or One-way or
Realm non-Windows Kerberos realm and an Active Directory
nontransitive two-way
domain.

Use forest trusts to share resources between forests. If a


One-way or
Forest Transitive forest trust is a two-way trust, authentication requests that
two-way
are made in either forest can reach the other forest.

Use shortcut trusts to improve user logon times between


One-way or two domains within An Active Directory forest. This is
Shortcut Transitive
two-way useful when two domains are separated by two domain
trees.

When you create external trusts, shortcut trusts, realm trusts, or forest trusts, you have the option
to create each side of the trust separately or both sides of a trust simultaneously.

If you choose to create each side of the trust separately, you must run the New Trust Wizard twice—
once for each domain. When you create trusts using the method, you must supply the same trust
password for each domain. As a security best practice, all trust passwords should be strong
passwords.

If you choose to create both sides of the trust simultaneously, you run the New Trust Wizard once.
When you choose this option, a strong trust password is automatically generated for you. You must
have the appropriate administrative credentials for the domains between which you are creating the
trust.

Understanding Trust Direction

Trust direction

The trust type and its assigned direction affect the trust path that is used for authentication. A trust
path is a series of trust relationships that authentication requests must follow between domains.
Before a user can access a resource in another domain, the security system on domain controllers
must determine whether the trusting domain (the domain that contains the resource that the user is
trying to access) has a trust relationship with the trusted domain (the user's logon domain). To
determine this, the security system computes the trust path between a domain controller in the
trusting domain and a domain controller in the trusted domain. In the following illustration, the trust
path is indicated by an arrow that shows the direction of the trust.
All domain trust relationships have only two domains in the relationship: the trusting domain and
the trusted domain.

One-way trust

A one-way trust is a unidirectional authentication path that is created between two domains. This
means that in a one-way trust between Domain A and Domain B, users in Domain A can access
resources in Domain B. However, users in Domain B cannot access resources in Domain A. Some
one-way trusts can be either a nontransitive trust or a transitive trust, depending on the type of
trust that is created. For more information about trust types, see Understanding Trust Types.

Two-way trust

All domain trusts in an Active Directory forest are two-way, transitive trusts. When a new child
domain is created, a two-way, transitive trust is automatically created between the new child
domain and the parent domain. In a two-way trust, Domain A trusts Domain B and Domain B trusts
Domain A. This means that authentication requests can be passed between the two domains in both
directions. Some two-way relationships can be either nontransitive or transitive, depending on the
type of trust that is created. For more information, see Understanding Trust Types.

Understanding Trust Transitivity

Trust transitivity

Transitivity determines whether a trust can be extended outside the two domains between which
the trust was formed. You can use a transitive trust to extend trust relationships with other domains.
You can use a nontransitive trust to deny trust relationships with other domains.

Transitive trust

Each time that you create a new domain in a forest, a two-way, transitive trust relationship is
automatically created between the new domain and its parent domain. If child domains are added
to the new domain, the trust path flows upward through the domain hierarchy, extending the initial
trust path that is created between the new domain and its parent domain.

Transitive trust relationships flow upward through a domain tree as it is formed, creating transitive
trusts between all domains in the domain tree.

Authentication requests follow these trust paths. Therefore, accounts from any domain in the forest
can be authenticated at any other domain in the forest. With a single logon process, accounts with
the proper permissions can access resources in any domain in the forest.
In addition to the default transitive trusts that are established in an Active Directory forest, by using
the New Trust Wizard you can manually create the following transitive trusts:

Shortcut trust : A transitive trust between a domain in the same domain tree or forest that
shortens the trust path in a large and complex domain tree or forest.

Forest trust : A transitive trust between a forest root domain and a second forest root
domain.

Realm trust : A transitive trust between an Active Directory domain and a Kerberos V5
realm.

The following illustration shows a two-way, transitive trust relationship between the Domain A tree
and the Domain 1 tree. All domains in the Domain A tree and all domains in the Domain 1 tree have
transitive trust relationships by default. As a result, users in the Domain A tree can access resources
in domains in the Domain 1 tree, and users in the Domain 1 tree can access resources in the
Domain A tree when the proper permissions are assigned at the resource.

Nontransitive trust

A nontransitive trust is restricted by the two domains in the trust relationship. It does not flow to
any other domains in the forest. A nontransitive trust can be a two-way trust or a one-way trust.
Nontransitive trusts are one-way by default, although you can also create a two-way relationship by
creating two one-way trusts.

In summary, nontransitive domain trusts are the only form of trust relationship that is possible
between the following:

An Active Directory domain and a Windows NT domain

An Active Directory domain in one forest and a domain in another forest (when the forests
are not joined by a forest trust)

You can use the New Trust Wizard to manually create the following nontransitive trusts:

External trust : A nontransitive trust between an Active Directory domain and a Windows NT
domain or an Active Directory domain in another forest.

Realm trust : A nontransitive trust between an Active Directory domain and a Kerberos
version 5 (V5) realm.

Understanding When to Create an External Trust

When to create an external trust


You can create an external trust to form a one-way or two-way, nontransitive trust with domains
that are outside your forest. External trusts are sometimes necessary when users need access to
resources in a Windows NT 4.0 domain or in a domain that is located in a separate forest that is not
joined by a forest trust, as shown in the following illustration.

When you establish a trust between a domain in a particular forest and a domain outside that forest,
security principals from the external domain can access resources in the internal domain.
Active Directory Domain Services (AD DS) creates a foreign security principal object in the internal
domain to represent each security principal from the trusted external domain. These foreign security
principals can become members of domain local groups in the internal domain. Domain local groups
can have members from domains outside the forest.

Directory objects for foreign security principals are created by AD DS, and they should not be
modified manually. You can view foreign security principal objects in the Active Directory Users and
Computers snap-in by enabling advanced features. (On the View menu, click Advanced Features. )

Understanding When to Create a Shortcut Trust

When to create a shortcut trust

Shortcut trusts are one-way or two-way, transitive trusts that administrators can use to optimize the
authentication process.

Authentication requests must first travel a trust path between domain trees. In a complex forest this
can take time, which you can reduce with shortcut trusts. A trust path is the series of domain trust
relationships that authentication requests must traverse between any two domains. Shortcut trusts
effectively shorten the path that authentication requests travel between domains that are located in
two separate domain trees.

Shortcut trusts are necessary when many users in a domain regularly log on to other domains in a
forest. Using the following illustration as an example, you can form a shortcut trust between
domain B and domain D, between domain A and domain 1, and so on.
Using one-way trusts

A one-way, shortcut trust that is established between two domains in separate domain trees can
reduce the time that is necessary to fulfill authentication requests—but in only one direction. For
example, when a one-way, shortcut trust is established between domain A and domain B,
authentication requests that are made in domain A to domain B can use the new one-way trust
path. However, authentication requests that are made in domain B to domain A must still travel the
longer trust path.

Using two-way trusts

A two-way, shortcut trust that is established between two domains in separate domain trees
reduces the time that is necessary to fulfill authentication requests that originate in either domain.
For example, when a two-way trust is established between domain A and domain B, authentication
requests that are made from either domain to the other domain can use the new, two-way trust
path.

Understanding When to Create a Realm Trust

When to create a realm trust

You can establish a realm trust between any non-Windows Kerberos version 5 (V5) realm and an
Active Directory domain. This trust relationship allows cross-platform interoperability with security
services that are based on other versions of the Kerberos V5 protocol, for example, UNIX and MIT
implementations. Realm trusts can switch from nontransitive to transitive and back. Realm trusts
can also be either one-way or two-way.

Create a Shortcut Trust

To create a shortcut trust using the Windows interface

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .

2. In the console tree, right-click the domain node for the domain that you want to establish a
shortcut trust with, and then click Properties .

3. On the Trusts tab, click New Trust , and then click Next .

4. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of
the domain, and then click Next .

5. On the Direction of Trust page, do one of the following:

o To create a two-way shortcut trust, click Two-way .


Users in this domain and users in the specified domain will be able to use this trust
path.

o To create a one-way incoming shortcut trust, click One-way:incoming .

Users in the specified domain will not be able to use this trust path.

o To create a one-way outgoing shortcut trust, click One-way:outgoing .

Users in this domain will not be able to use this trust path.

6. Continue to follow the instructions in the wizard.

Create an External Trust

To create an external trust using the Windows interface

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .

2. In the console tree, right-click the domain node for the domain that you want to establish a
trust with, and then click Properties .

3. On the Trusts tab, click the New Trust , and then click Next .

4. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of
the domain, and then click Next .

5. On the Trust Type page, click External trust , and then click Next .

6. On the Direction of trust page, do one of the following:

o To create a two-way, external trust, click Two-way .

Users in this domain and users in the specified domain will be able to access
resources in either domain.

o To create a one-way, incoming external trust, click One-way:incoming .

Users in the specified domain will not be able to access any resources in this domain.

o To create a one-way, outgoing external trust, click One-way:outgoing .

Users in this domain will not be able to access any resources in the specified domain.

7. Continue to follow the instructions in the wizard.

Create a Realm Trust

To create a realm trust using the Windows interface

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .
2. In the console tree, right-click the domain that you want to administer, and then click
Properties .

3. On the Trusts tab, click New trust , and then click Next .

4. On the Trust Name page, type the realm name for the target realm, and then click Next .

5. On the Trust Type page, select the Realm trust option, and then click Next .

6. On the Transitivity of Trust page, do one of the following:

o To form a trust relationship with the domain and the specified realm, click
Nontransitive , and then click Next .

o To form a trust relationship with the domain and the specified realm and all trusted
realms, click Transitive , and then click Next .

7. On the Direction of Trust page, do one of the following:

o To create a two-way, realm trust, click Two-way .

Users in this domain and users in the specified realm will be able to access resources
in either domain or realm.

o To create a one-way, incoming realm trust, click One-way:incoming .

Users in the specified realm will not be able to access any resources in this domain.

o To create a one-way, outgoing realm trust, click One-way:outgoing .

Users in this domain will not be able to access any resources in the specified realm.

8. Continue to follow the instructions in the wizard.

Verify a Trust

To verify a trust using the Windows interface

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .

2. In the console tree, right-click the domain that contains the trust that you want to verify,
and then click Properties .

3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or
Domains that trust this domain (incoming trusts) , click the trust to be verified, and then
click Properties .

4. Click Validate .

5. Do one of the following, and then click OK :

o Click No, do not validate the incoming trust .

If you select this option, we recommend that you repeat this procedure for the
reciprocal domain.
o Click Yes, validate the incoming trust .

If you select this option, you must type a user account and password with
administrative credentials for the reciprocal domain.

Remove a Trust

To remove a trust using the Windows interface

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .

2. In the console tree, right-click the domain that contains the trust that you want to remove,
and then click Properties .

3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or
Domains that trust this domain (incoming trusts) , click the trust to be removed, and then
click Remove .

4. Do one of the following, and then click OK :

o Click No, remove the trust from the local domain only .

If you select this option, we recommend that you repeat this procedure for the
reciprocal domain.

o Click Yes, remove the trust from both the local domain and the other domain .

If you select this option, you must type a user account and password with
administrative credentials for the reciprocal domain.

Select the Scope of Authentication for Users

To select the scope of authentication using the Windows interface

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .

2. In the console tree, right-click the domain node for the domain that you want to administer,
and then click Properties .

3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or
Domains that trust this domain (incoming trusts) , do one of the following:

o To select the scope of authentication for users that are authenticating through an
external trust, click the external trust that you want to administer, and then click
Properties . On the Authentication tab, click either Domain-wide authentication or
Selective authentication .

o To select the scope of authentication for users that are authenticating through a
forest trust, click the forest trust that you want to administer, and then click
Properties . On the Authentication tab, click either Forest-wide authentication or
Selective authentication .
Managing Forest Trusts using Active Directory Domains and Trusts Snap-in
Understanding When to Create a Forest Trust

When to create a forest trust

You can create a forest trust between forest root domains if the forest functional level is Windows
Server 2003 or higher. Creating a forest trust between two root domains with a forest functional
level of Windows Server 2003 or higher provides a one-way or two-way, transitive trust relationship
between every domain in each forest. Forest trusts are useful for application service providers,
organizations undergoing mergers or acquisitions, collaborative business extranets, and
organizations seeking a solution for administrative autonomy.

Using one-way, forest trusts

A one-way, forest trust between two forests allows members of the trusted forest to use resources
that are located in the trusting forest. However, the trust operates in only one direction. For
example, when a one-way, forest trust is created between forest A (the trusted forest) and forest B
(the trusting forest), members of forest A can access resources that are located in forest B, but
members of forest B cannot access resources that are located in forest A, using the same trust.

Using two-way, forest trusts

A two-way, forest trust between two forests allows members from either forest to use resources
that are located in the other forest, and domains in each respective forest trust domains in the other
forest implicitly. For example, when a two-way, forest trust is established between forest A and
forest B, members of forest A can access resources that are located in forest B, and members of
forest B can access resources in forest A, using the same trust.

Create a Forest Trust

To create a forest trust

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .

2. In the console tree, right-click the domain that you want to administer, and then click
Properties .

3. On the Trusts tab, click New trust , and then click Next .

4. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of
the domain, and then click Next .

5. On the Trust Type page, click Forest trust , and then click Next .

6. On the Direction of Trust page, do one of the following:

o To create a two-way, forest trust, click Two-way .

Users in this forest and users in the specified forest will be able to access resources
in either forest.
o To create a one-way, incoming forest trust, click One-way:incoming .

Users in the specified forest will not be able to access any resources in this forest.

o To create a one-way, outgoing forest trust, click One-way:outgoing .

Users in this forest will not be able to access any resources in the specified forest.

7. Continue to follow the instructions in the wizard.

Change the Routing Status of a Name Suffix

To change the routing status of a name suffix

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .

2. In the console tree, right-click the domain node for the domain that you want to administer,
and then click Properties .

3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or
Domains that trust this domain (incoming trusts) , click the forest trust that you want to
administer, and then click Properties .

4. On the Name Suffix Routing tab, under Name suffixes in the x.xforest , click the suffix for
which you want to modify the routing status, and then click Edit .

5. In Existing name suffixes in x.x , click the suffix that you want to modify, and then click
Enable or Disable .

Enable or Disable an Existing Name Suffix from Routing

To enable or disable an existing name suffix from routing

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .

2. In the console tree, right-click the domain node for the domain that you want to administer,
and then click Properties .

3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or
Domains that trust this domain (incoming trusts) , click the forest trust that you want to
administer, and then click Properties .

4. Click the Name Suffix Routing tab, and under Name suffixes in the x.x. forest , do one of the
following:

o To enable a name suffix, click the suffix that you want to enable, and then click
Enable . If the Enable button appears dimmed, the name suffix is already enabled.

o To disable a name suffix, click the suffix that you want to disable, and then click
Disable . If the Disable button appears dimmed, the name suffix is already disabled.
Exclude Name Suffixes from Routing to a Local Forest

To exclude name suffixes from routing to a local forest

1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts,
click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .

2. In the console tree, right-click the domain node for the domain that you want to administer,
and then click Properties .

3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or
Domains that trust this domain (incoming trusts) , click the forest trust that you want to
administer, and then click Properties .

4. Click the Name Suffix Routing tab. Under Name suffixes in the x.x. forest , click the unique
name suffix for which you want to exclude the routing status, and then click Edit .

5. In Name suffixes to exclude from routing to x.x , click Add , type a DNS name suffix that is
subordinate to the unique name suffix, and then click OK .

Active Directory Sites and Services Snap-in


Active Directory® Sites and Services is a Microsoft Management Console (MMC) snap-in that you can
use to administer the replication of directory data among all sites in an Active Directory Domain
Services (AD DS) forest. This snap-in also provides a view of the service-specific objects that are
published in AD DS.

Administrators who are responsible for forest-wide service administration can use Active Directory
Sites and Services to manage the intersite replication topology for the forest. Administrators who
are responsible for application services can be delegated responsibility for the service containers
into which application-specific objects are published.

When you add the Active Directory Domain Services server role to a server, Active Directory Sites
and Services is added to the Administrative Tools menu.

You can use the Active Directory Sites and Services snap-in to manage the site-specific objects that
implement the intersite replication topology. These objects are stored in the Sites container in
Active Directory Domain Services (AD DS).

Site Management

In your physical network, a site represents a set of computers that are connected by a high-speed
network, such as a local area network (LAN). Typically, all computers in the same physical site reside
in the same building or perhaps the same campus network.

In AD DS, a site object represents the aspects of the physical site that you can manage, specifically,
replication of directory data between domain controllers. You can use Active Directory Sites and
Services to manage the objects that represent the sites and the servers that reside in those sites.

Site objects and their related objects are replicated to all domain controllers in an Active Directory
forest. You can manage the following objects in Active Directory Sites and Services:

Sites

Subnets

Servers

NTDS Settings

Connections

Site links

IP and SMTP intersite transports

Sites

Site objects are located in the Sites container. You can use site objects to accomplish the following
tasks:

Create new sites

Delegate control over sites by using Group Policy and permissions

In every site, there is an NTDS Site Settings object. This object identifies the intersite topology
generator (ISTG). The ISTG is the one domain controller in the site that generates connection objects
from domain controllers in different sites. It also performs advanced replication management tasks.
Subnets

Subnet objects identify the ranges of IP addresses within a site. You can use subnet objects to
accomplish the following tasks:

Create new subnets

Associate subnets with sites

Provide a location for a site that can be used by the printer location tracking feature in
Group Policy

Servers

Server objects are created automatically when you add the Active Directory Domain Services server
role. Servers represent domain controllers in the replication topology.

You can use server objects to accomplish the following tasks:

Identify domain controllers that will act as preferred bridgehead servers. You can use
preferred bridgehead servers to control intersite replication so that it occurs only between
those domain controllers that you specify and not between domain controllers that might be
less able to handle intersite replication traffic.

Move servers between sites. If you create a new site and you have already installed domain
controllers with IP addresses that map to the new site, you can move the domain controllers
to the new site.

NTDS Settings

Every server object contains an NTDS Settings object, which represents the domain controller in the
replication system. The NTDS Settings object stores connection objects, which make replication
possible between two or more domain controllers.

You can use NTDS Settings objects to accomplish the following tasks:

Generate the replication topology. The Check Replication Topology command for the NTDS
Settings object signals the ISTG to perform a check of all connections between domain
controllers and add or remove any connections that are needed.

Enable or disable the global catalog on a server. When you enable the global catalog, the
domain controller replicates the read-only directory partitions that make up the global
catalog in the forest.

Connections

Replication partners of servers in a site are identified by connection objects. Replication occurs in
one direction. A connection object for a server contains information about the other server (the
"from" server) that sends replication to the first server. Connection objects store schedules that
control replication within a site. By default, they automatically poll a replication partner for new
changes once every hour. For intersite replication, connection objects derive their schedule from the
site link object. You do not have to manage schedules on connection objects. Connection objects are
created automatically by the replication system.

You can use connection objects to accomplish the following tasks:


Identify replication partnerships of servers in the site

Force replication over a connection, when you do not want to wait for scheduled replication
or to test replication over a connection

Site links

Site links represent the flow of replication between sites. You can manage intersite replication by
configuring site properties: over what time periods replication can occur, how often replication
occurs within a certain time period, and the preferred routes between two sites.

You can use site link objects to accomplish the following tasks:

Add and remove sites that use the site link

Set the cost of replication over the site link, which determines the likelihood that replication
occurs over this site link when there are multiple routes that replication could take to reach
a destination site

Set the site link schedule, which determines the hours and days that replication is available
(can occur) over the site link

Set the replication interval, which determines how often replication occurs over the site link
when replication is available

IP and SMTP intersite transports

Replication uses remote procedure call (RPC) over either the IP transport or the Simple Mail Transfer
Protocol (SMTP) transport. You can use SMTP to send replication within mail messages in
environments where wide area network (WAN) links are not available. In this case, replication occurs
according to the messaging schedule and not the site link schedule. By default, intersite replication
uses the IP transport protocol to deliver replication packets. You can use the IP and SMTP Intersite
Transport containers to accomplish the following tasks:

Create site links. You can add site links to the replication topology as needed to
accommodate new sites.

Create site link bridges. Site links are bridged by default in AD DS, and they are not necessary
in most deployments.

Service publication

Some services, such as Certificate Services, Message Queuing, and Exchange Server, publish
information in the Sites container in AD DS automatically when they are installed. Other services can
be published in the directory with programming interfaces.

Active Directory Sites and Services exposes published service-related objects in the Services node.
This node is not visible by default. To view this node, open Active Directory Sites and Services, and
then, on the View menu, click Show Services Node .

The objects in the Services node in Active Directory Sites and Services are published for use by the
respective application administrators. For this reason, information about these objects is available in
documentation for the service or application.

Create a Site
To create a site

1. Open Active Directory Sites and Services. To open Active Directory Sites and Services, click
Start , click Administrative Tools , and then click Active Directory Sites and Services .

2. In the console tree, right-click Sites , and then click New Site .

3. In Name , type the name of the new site.

4. In Link Name , click a site link object, and then click OK .

Create a Subnet

To create a subnet

1. Open Active Directory Sites and Services. To open Active Directory Sites and Services, click
Start , click Administrative Tools , and then click Active Directory Sites and Services .

2. In the console tree, double-click Sites , right-click Subnets , and then click New Subnet .

3. In Prefix , type the IP version 4 (IPv4) or IP version 6 (IPv6) subnet prefix.

4. In Select a site object for this prefix , click the site to associate with this subnet, and then
click OK .

Create a Site Link

To create a site link

1. Open Active Directory Sites and Services. To open Active Directory Sites and Services, click
Start , click Administrative Tools , and then click Active Directory Sites and Services .

2. In the console tree, right-click the intersite transport protocol that you want the site link to
use.

Where?

o Active Directory Sites and Services\Sites\Inter-Site Transports\IP or SMTP

3. Click New Site Link .

4. In Name , type the name for the site link.

5. In Sites not in this site link , click a site to add to the site link, and then click Add . Repeat to
add more sites to the site link. To remove a site from the site link, in Sites in this link , click
the site, and then click Remove .

6. When you have added the sites that you want to be connected by this site link, click OK .

Add a Site to or Remove a Site from a Site Link

To add a site to or remove a site from a site link

1. Open Active Directory Sites and Services. To open Active Directory Sites and Services, click
Start , click Administrative Tools , and then click Active Directory Sites and Services .
2. In the console tree, click the intersite transport folder that contains the site link in which you
are adding or removing a site.

Where?

o Active Directory Sites and Services\Sites\Inter-Site Transports\IP or SMTP

3. In the details pane, right-click the site link in which you want to add or remove a site, and
then click Properties .

4. In the appropriate list, click the site that you want to add to or remove from this site link,
and then click Add or Remove , respectively.

Configure the Intersite Replication Schedule

Understanding Replication Between Sites

Active Directory Domain Services (AD DS) handles replication between sites, or intersite replication,
differently than replication within sites because bandwidth between sites is usually limited. The
Active Directory Knowledge Consistency Checker (KCC) builds the intersite replication topology using
a least-cost spanning tree design. Intersite replication is optimized for bandwidth efficiency.
Directory updates between sites occur automatically based on a configurable schedule. Directory
updates that are replicated between sites are compressed to preserve bandwidth.

Building the intersite replication topology

AD DS uses information that you provide (through the Active Directory Sites and Services snap-in)
about your sites and site links to build the most efficient intersite replication topology automatically.
The directory stores the replication topology as connection objects, which the system creates
automatically to form the replication topology both within sites and between sites. Connection
objects identify replication partners for both intrasite replication and intersite replication. These
objects always represent one-way, inbound replication to the server that contains the object. The
intersite replication topology is updated regularly to respond to any changes that occur in the
network. You do not have to create or manage connection objects. However, you can control the
timing of intersite replication through the information that you provide when you configure site link
objects.

Note

You can use Active Directory Sites and Services to administer the replication of directory data among
all the sites in an Active Directory Lightweight Directory Services (AD LDS) configuration set.

Determining when intersite replication occurs

AD DS preserves bandwidth between sites by minimizing the frequency of replication and by making
it possible for you to schedule the availability of site links for replication. By default, intersite
replication across each site link occurs every 180 minutes (3 hours). You can adjust this frequency to
match your specific needs. Be aware that increasing this frequency increases the amount of
bandwidth that replication uses. In addition to scheduling the frequency of replication, you can also
schedule the availability of site links for replication. By default, a site link is available to carry
replication traffic 24 hours a day, 7 days a week. You can limit this schedule to specific days of the
week and times of day. For example, you can schedule intersite replication so that it occurs only
after normal business hours, five days a week.

If you have multiple site links configured so that there is more than one route between two sites,
you can configure the cost of replication on the site link to identify a preference for one route over
the other.

Using replication transports

The default transport for AD DS replication within sites is Remote Procedure Call (RPC) over IP. RPC
over IP is also used for intersite replication. The IP container in Active Directory Sites and Services
contains objects that represent site links that use RPC over IP to package and transfer replication
data between sites. To keep data secure while it is in transit between sites, RPC over IP replication
uses both authentication (with the Kerberos version 5 (V5) authentication protocol) and data
encryption.

When a direct or reliable IP connection is not available, you can configure replication between sites
to use Simple Mail Transfer Protocol (SMTP). However, SMTP replication functionality is limited to
nondomain replication (schema, configuration, and global catalog updates). It also requires an
enterprise certification authority (CA) when you use it over site links. SMTP is an optional
component of Intersite Messaging. You must add it before you can use SMTP for replication.

Configure Intersite Replication Availability

To configure intersite replication availability

1. Open Active Directory Sites and Services. To open Active Directory Sites and Services, click
Start , click Administrative Tools , and then click Active Directory Sites and Services .

2. In the console tree, click the intersite transport folder that contains the site link for which
you are configuring intersite replication availability.

Where?

o Active Directory Sites and Services\Sites\Inter-Site Transports\IP or SMTP

3. In the details pane, right-click the site link whose schedule you want to configure, and then
click Properties .

4. Click Change Schedule .

Note

When you are logged on with an account that does not have sufficient credentials to change
the schedule, the available option is View Schedule .

5. Select the block of time during which you want replication to be either available or not
available, and then click Replication Not Available or Replication Available , respectively.

Important

Use the IP intersite transport unless your network has remote sites where network connectivity is
intermittent or end-to-end IP connectivity is not available. Simple Mail Transfer Protocol (SMTP)
replication has restrictions that do not apply to IP replication.
Configure Intersite Replication Frequency

To specify how often replication can occur during any block of availability in the intersite replication
schedule, you can use the Active Directory Sites and Services snap-in to configure the frequency
setting in the site link object properties. At the specified interval (for example, once every
60 minutes), a domain controller that is acting as a bridgehead server in a site requests changes from
its source replication partner in a different site.

Membership in the Enterprise Admins group in the forest or the Domain Admins group in the forest
root domain, or equivalent, is the minimum required to complete this procedure.

To configure intersite replication frequency

1. Open Active Directory Sites and Services. To open Active Directory Sites and Services, click
Start , click Administrative Tools , and then click Active Directory Sites and Services .

2. In the console tree, click the intersite transport folder that contains the site link for which
you are configuring intersite replication availability.

Where?

o Active Directory Sites and Services\Sites\Inter-Site Transports\IP or SMTP

3. In the details pane, right-click the site link whose schedule you want to configure, and then
click Properties .

4. In Replicate every , type or select the number of minutes between replications.

Important

Use the IP intersite transport unless your network has remote sites where network connectivity is
intermittent or end-to-end IP connectivity is not available. Simple Mail Transfer Protocol (SMTP)
replication has restrictions that do not apply to IP replication.

Add or Remove the Global Catalog

You can use the same user interface (UI) in the Active Directory Sites and Services snap-in to add or
remove the global catalog. Enabling the global catalog can cause additional replication traffic.
However, global catalog removal occurs gradually in the background and does not affect replication
or performance.

Membership in the Enterprise Admins group in the forest or the Domain Admins group in the forest
root domain, or equivalent, is the minimum required to complete this procedure.

To add or remove the global catalog

1. Open Active Directory Sites and Services. To open Active Directory Sites and Services, click
Start , click Administrative Tools , and then click Active Directory Sites and Services .

2. In the console tree, click the server object to which you want to add the global catalog or
from which you want to remove the global catalog.
Where?

o Active Directory Sites and Services\Sites\SiteName\Servers

3. In the details pane, right-click NTDS Settings of the selected server object, and then click
Properties .

4. Select the Global Catalog check box to add the global catalog, or clear the check box to
remove the global catalog.

Verify Global Catalog Readiness

To verify global catalog readiness using the Windows interface

1. Open the Ldp snap-in. To open Ldp, click Start , click Run , type ldp , and then click OK .

2. On the Connection menu, click Connect .

3. In Connect , type the name of the server whose global catalog readiness you want to verify.

4. In Port , if 389 does not appear, type 389 .

5. If the Connectionless check box is selected, clear it, and then click OK .

6. In the details pane, verify that the isGlobalCatalogReady attribute has a value of TRUE .

7. On the Connection menu, click Disconnect , and then close Ldp.

Verify Global Catalog DNS Registrations

To verify global catalog DNS registrations

1. Restart the global catalog server whose DNS registrations you want to verify.

2. Open DNS Manager. To open DNS Manager, click Start , click Administrative Tools , and then
click DNS .

3. To connect to a domain controller in the forest root domain for which you want to verify
DNS registrations, right-click DNS , and then click Connect to DNS Server .

4. In the console tree, click the _tcp container for the forest root domain.

Where?

o DNS\ DNSServer \Forward Lookup Zones\ ForestRootDomain \

5. In the details pane, in the Name column, look for _gc , and in the Data column, look for the
name of the server. The records that begin with _gc are global catalog service location (SRV)
resource records.

ADSI Edit
Active Directory® Service Interfaces Editor (ADSI Edit) is a Lightweight Directory Access Protocol
(LDAP) editor that you can use to manage objects and attributes in Active Directory Domain Services
(AD DS).

ADSI Edit (adsiedit.msc) provides a view of every object and attribute in an Active Directory forest.
You can use ADSI Edit to query, view, and edit attributes that are not exposed through other AD DS
Microsoft Management Console (MMC) snap-ins: Active Directory Users and Computers,
Active Directory Sites and Services, Active Directory Domains and Trusts, and Active Directory
Schema.

ADSI Edit runs as a Microsoft Management Console (MMC) snap-in. To open ADSI Edit, on a
computer with the Active Directory Lightweight Directory Services (AD LDS) server role installed,
click Start , click Administrative Tools , and then click ADSI Edit .

ADSI Edit node

To view the following UI options, in the console tree, click ADSI Edit , and then, on the Action menu,
click Connect to . The Connection Settings dialog box appears

You can use the following options in the Connection Settings dialog box to create a connection to a
directory partition on an instance of Active Directory Lightweight Directory Services (AD LDS).

Option Details

Type a display name for the connection. The connection will be listed in the console
Name
tree using the connection name that you provide.

Connection Specify how you want to connect to the AD LDS instance. You can connect to a
Point distinguished name or naming context in the AD LDS instance, or you can select a well-
known naming context.

Note

AD LDS does not provide a naming context by default.

Specify the computer running the AD LDS instance that you want to administer. You
must specify the server name or IP address. If the AD LDS instance is not using the
Computer
default Lightweight Directory Access Protocol (LDAP) communications port number
(389), you must also specify the port number that the AD LDS instance is using.

Click this button to specify the credentials and bind method that you want to use for
Advanced
connections to the AD LDS instance

The Refresh command on the Action menu updates the information about connections and objects
that is displayed in ADSI Edit.

Connection node

To view the following commands, in the console tree, click a connection node for an already
established connection, and then, on the Action menu, click one of the commands in the following
table.

Command Details

Removes the currently selected connection node from ADSI Edit. This command
Remove affects only the contents of the ADSI Edit console tree; the command does not delete
any objects from the AD LDS instance.

Update
Reloads the schema information from AD LDS into the cache of the local computer.
Schema Now

New Creates a new query when you point to New and then click Query .

Rename Specifies a new name for the connection node.

Updates the information about connections and objects that is displayed in


Refresh
ADSI Edit.

Object node

To view the following commands, in the console tree, click a directory object in a directory partition
in an AD LDS instance, and then, on the Action menu, click one of the commands in the following
table.
Command Details

Moves the object to another container in AD LDS. Opens a dialog box that you can
Move
use to select the destination container.

New
Connection Creates a new connection and adds the new connection to the console tree.
from Here

Creates a new child object in the selected container when you point to New and
then click Object . Opens a set of chained dialog boxes that begins with the class of
the object. If you do not have permission to create an object in the selected
New
container, no classes are listed. After a class is selected, a dialog box opens for each
required attribute. In the final dialog box, click More to view and edit any optional
attributes.

Deletes the selected object from AD LDS. A dialog box appears asking you to confirm
Delete the deletion. This command does not appear in the menu if you do not have
permissions to delete the object from AD LDS.

Rename Changes the name of the object in AD LDS.

Updates the information that is displayed in ADSI Edit about connections and
Refresh
objects.

Properties Opens a dialog box in which you can edit the attribute values of an object.

This option is available only for objects that contain a unicodePwd attribute. This
Reset
option provides a dialog box in which the value of the unicodePwd attribute can be
Password
reset.

Schema Manager
Overview of the Active Directory Schema Snap-in

You can use the Active Directory Schema Microsoft Management Console (MMC) snap-in to view
and manage Active Directory Domain Services (AD DS) schema objects. The Active Directory Schema
snap-in has more strict installation and use requirements than other administrative tools. To make
changes in the Active Directory Schema snap-in, you must be a member of the Schema Admins
security group in the forest root domain of your Active Directory forest. By default, the
Administrator account for the forest root domain is the only member of the Schema Admins group.

With the Active Directory Schema snap-in, you can view class and object definitions, provide
administrative access to the schema, and modify schema classes and attributes. However, modifying
the schema is an advanced and complex operation that is best handled by experienced programmers
and administrators.
Installing, Securing, and Viewing the Schema

In most Active Directory forests, you do not have to manage schema objects or their properties in
any way other than to provide security to ensure that only authorized administrators have access to
the schema. The default access to schema objects and properties is limited to the Administrator
account in the forest root domain. However, you may occasionally want to provide schema
permissions to other administrators if, for example, an application developer needs to modify a
schema object or troubleshoot a schema compatibility problem for an application.

You also may need to install the Active Directory Schema snap-in on other domain controllers. You
can use the Active Directory Schema snap-in to view schema class and attribute objects and
properties.

Installing the Active Directory Schema snap-in

Because schema management is not a typical administrative objective and because schema changes
have potentially harmful forest-wide consequences, the Active Directory Schema snap-in is not
installed by default when you add the Active Directory Domain Services (AD DS) role. Before you can
add the Active Directory Schema snap-in to Microsoft Management Console (MMC), you must
register Schmmgmt.dll in AD DS. The requirement for this preliminary step discourages improper use
of the tool. After you register Schmmgmt.dll, the Active Directory Schema snap-in is available to be
added to MMC.

You can use this procedure to first register the dynamic-link library (DLL) that is required for the
Active Directory Schema snap-in. You can then add the snap-in to Microsoft Management Console
(MMC).

Membership in Domain Admins , or equivalent, is the minimum required to complete this


procedure. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.

To install the Active Directory Schema snap-in

1. To open an elevated command prompt, click Start , type command prompt , and then right-
click Command Prompt when it appears in the Start menu. Next, click Run as administrator ,
and then click OK .

2. Type the following command, and then press ENTER:

regsvr32 schmmgmt.dll

3. Click Start , click Run , type mmc , and then click OK .

4. On the File menu, click Add/Remove Snap-in .

5. Under Available snap-ins , click Active Directory Schema , click Add , and then click OK .

6. To save this console, on the File menu, click Save .

7. In the Save As dialog box, do one of the following:

o To place the snap-in in the Administrative Tools folder, in File name , type a name
for the snap-in, and then click Save .

o To save the snap-in to a location other than the Administrative Tools folder, in Save
in , navigate to a location for the snap-in. In File name , type a name for the snap-in,
and then click Save .

Caution

Modifying the schema is an advanced operation that is best performed by experienced programmers
and system administrators.

Providing administrative access to the schema

Members of the Schema Admins group have permission to perform all modifications to the schema
except Delete All Child Objects. By default, the only member of the Schema Admins group is the
Administrator account in the forest root domain.

Granting permissions to an administrator

You can use the Active Directory Users and Computers snap-in to add another user to the Schema
Admins group. Only one additional user should be added to the group at a time. As a best practice, if
you determine that a change must be made to the schema, add an administrative user to the
Schema Admins group to allow the change. After the change is complete, remove the administrative
user from the group.

Specifying individual permissions

You can also provide permissions for specific schema management tasks without allowing
permissions to make all changes. Use the Permissions option to grant specific access to a user or
group. Again, when the access is no longer needed, remove the permissions for the user or group.

To apply permissions to perform a schema task

1. Open the Active Directory Schema snap-in.

2. In the console tree, click Active Directory Schema to connect to the domain.

3. In the console tree, right-click Active Directory Schema , and then click Permissions .

4. In Group or user names , select a user or group, or click Add to add a user or group.

5. In Permissions for <user_name> , select or clear the permission that you want to grant or
deny, respectively, and then click OK .

Viewing class and attribute definitions

The Active Directory Schema snap-in provides a view of the classSchema and attributeSchema
objects.

To view a schema class or attribute definition

1. Open the Active Directory Schema snap-in.

2. In the console tree, double-click Active Directory Schema .

3. Do one of the following:

o To view a class definition, in the console tree, click and expand Classes . Right-click
the class for which you want to view a definition, and then click Properties .

o To view an attribute definition, in the console tree, click Attributes . In the details
pane, right-click the attribute for which you want to view a definition, and then click
Properties .
Group Policy Management Console
Group Policy provides an infrastructure for centralized configuration management of the operating
system and applications that run on the operating system.

Group Policy Management Console (GPMC) is a scriptable Microsoft Management Console (MMC)
snap-in, providing a single administrative tool for managing Group Policy across the enterprise.
GPMC is the standard tool for managing Group Policy.

The Group Policy Management Console (GPMC) is included with Windows Server® 2008 and later.
However, this feature is not installed with the operating system. Use Server Manager to install the
GPMC.

To install the GPMC using the Server Manager user interface

1. Do one of the following to open Server Manager .

o In Windows Server 2008 R2 and Windows Server 2008, click Start and then point to
Administrative Tools . Click Server Manager .

2. Do one of the following to add the GPMC feature.

o In Windows Server 2008 R2 and Windows Server 2008, in the console tree, click
Features . In the Features pane, click Add Features .

In the Add Feature Wizard dialog box, select Group Policy Management Console
from the list of available features. Click Install .

3. Close Server Manager when the installation completes.

To start GPMC

Do either of the following:

o Press the Windows logo key + R to open the RUN dialog box. Type gpmc.msc in the
text box, and then click OK or press ENTER.

o Click Start, click All Programs, click Accessories, and then click Run. Type gpmc.msc
in the text box, and then click OK or press ENTER.

Getting in deeper on Group Policy is out of scope for this course. Students are encouraged to explore
further on Group Policies and GPMC.

References:
http://technet.microsoft.com/en-us/library/cc794908(v=ws.10).aspx - Administering Active
Directory Domain Services

http://technet.microsoft.com/en-us/library/cc754217.aspx - Active Directory Users and Computers

http://technet.microsoft.com/en-us/library/cc770299.aspx - Active Directory Domains and Trusts

http://technet.microsoft.com/en-us/library/cc730868.aspx - Active Directory Sites and Service

http://technet.microsoft.com/en-us/library/cc730667.aspx - Schema Manager

http://technet.microsoft.com/en-us/library/cc753298.aspx - Group Policy Management Console

Labs:

- Explore the Management consoles introduced in this module by creating users, groups, Ous,
etc.

Module 5: Backup / Restore of Active Directory


Backing Up Active Directory Domain Services

This section describes the different types of backups that you can perform to ensure that you can
recover Active Directory Domain Services (AD DS) if Active Directory data quality or consistency is
jeopardized by human error, hardware breakdown, or software issues. You can perform regular,
scheduled backups—which are essential for dependable operations—and you can perform
immediate, ad hoc backups when necessary or as an alternative to scheduling regular backups,
although scheduling is preferred.

Backup tools and processes are improved in Windows Server 2008 to provide easier methods for
backing up the data that is required to recover AD DS and the full server.

Windows Server backup tools

To back up AD DS in Windows Server 2008, you use the Windows Server Backup tool.

To use Windows Server Backup tools, you must install Windows Server Backup Features in Server
Manager.

In the features list in Server Manager, Windows Server Backup Features has two parts:

Windows Server Backup (Wbadmin.msc), a graphical user interface (GUI) snap-in that is
available on the Administrative Tools menu

You can use the Windows Server Backup GUI to perform critical-volumes backups and full
server backups.

Note

You can perform a system state backup only by using the Wbadmin.exe command-line tool.
Command-line Tools, which is required to install the Wbadmin.exe command-line tool for
Windows Server Backup. “Command-line Tools” refers to a set of Windows PowerShell tools.
When you select Command-line Tools, you are prompted to install the required Windows
PowerShell feature.

You can use the Windows Server Backup command-line tool, Wbadmin.exe, to perform all
types of backup, including system state backup.

You can use the Windows Server Backup snap-in to back up entire volumes only, as follows: those
volumes that contain system state files (critical-volumes backup) or all volumes (full server backup).
The Windows Server Backup snap-in has two wizard options: a Backup Schedule Wizard and a
Backup Once Wizard.

To use one of the wizards for backing up critical volumes, you must know which volumes to select, or
you can allow the wizard to select them when you specify that you want to enable system recovery.
When you use the command-line tool for backing up critical volumes, the tool selects the correct
volumes automatically.

To back up system state, you must use the Wbadmin.exe command-line tool.

Windows Server backup types

In Windows Server 2008, you can use Windows Server Backup tools to back up three categories of
domain controller data, all of which can be used to recover AD DS. Each backup type backs up a
different set of data.

Contents of Windows Server backup types

The following list describes the backup types and the data that they contain:

System state, which includes all the files that are required to recover AD DS. System state
includes at least the following data, plus additional data, depending on the server roles that
are installed:

o Registry

o COM+ Class Registration database

o Boot files

o Active Directory Certificate Services (AD CS) database

o Active Directory database (Ntds.dit) file and log files

o SYSVOL directory

o Cluster service information

o Microsoft Internet Information Services (IIS) metadirectory

o System files that are under Windows Resource Protection

Critical volumes, which includes all volumes that contain system state files:
o The volume that hosts the boot files, which consist of the Bootmgr file and the Boot
Configuration Data (BCD) store

o The volume that hosts the Windows operating system and the registry

o The volume that hosts the SYSVOL tree

o The volume that hosts the Active Directory database

o The volume that hosts the Active Directory database log files

Full server, which includes all volumes on the server, including Universal Serial Bus (USB)
drives. The backup does not include the volume where the backup is stored.

Criteria for using backup types

The following table shows the qualities and restrictions that apply to each backup type. Use this
table to determine the backup type to use.

Critical-
System state Full server
Feature volumes
backup backup
backup

Can be used to recover from registry or directory service


Yes Yes Yes
configuration errors (recover AD DS)

Can be used for full server (bare-metal) recovery with


No Yes Yes
Windows Recovery Environment (Windows RE)

Can be used to recover from unbootable conditions No Yes Yes

Can be used to recover specific files and folders No Yes Yes

Can be created by using Windows Server Backup snap-in


No Yes Yes
(GUI)

Can be created by using Wbadmin.exe command line


Yes Yes Yes
tool

Has incremental backup support No* Yes ?

Can be stored on a DVD or on a network share if the


backup is performed manually (is not a scheduled No Yes Yes**
backup)

Can use any of the volumes that are included in the


Yes*** No No
backup as the target volume

Can be scheduled by using the Windows Server Backup


No Yes Yes
snap-in
* Each consecutive backup requires as much space as the first. To help manage the number of
versions of system state backups that you store, you can use the wbadmin delete
systemstatebackup command to remove old versions.

** Must be stored on a different hard disk from the source volumes, including external disks or
DVDs. External storage devices must be connected to the backup computer.

*** No, by default, but you can override the default by making a change in the registry. To store the
system state backup on a volume that is included in the backup, you must add the
AllowSSBToAnyVolume registry entry to the server that you are backing up. However, there are
some known issues with storing system state backup on a volume that is included in the backup.

Backup guidelines

The following guidelines for backup include the performance of backups to ensure redundancy of
Active Directory data:

Create daily backups of all unique data, including all domain directory partitions on global
catalog servers.

Create daily backups of critical volumes on at least two unique domain controllers, if
possible. When you have environments with single-domain-controller forests, single-
domain-controller domains, or empty root domains, take special care to back up more often.

Ensure that backups are available in sites where they are needed. Do not rely on copying a
backup from a different site, which is very time consuming and can significantly delay
recovery.

Where domains exist in only one site, store additional backup files offsite in a secure
location so that no backup file of a unique domain exists in only one physical site at any
point in time. This precaution provides an extra level of redundancy in case of physical
disaster or theft.

Make sure that your backups are stored in a secure location at all times.

Back up volumes that store Domain Name System (DNS) zones that are not Active Directory–
integrated. You must be aware of the location of DNS zones and back up DNS servers
accordingly. If you use Active Directory–integrated DNS, DNS zone data is captured as part of
system state and critical-volume backups on domain controllers that are also DNS servers.

If you do not use Active Directory–integrated DNS, you must back up the zone volumes on a
representative set of DNS servers for each DNS zone to ensure fault tolerance for the zone.

Note

The DNS server stores settings in the registry. Therefore, system state or critical-volume backup is
required for DNS, regardless of whether the zone data is Active Directory–integrated or stored in the
file system.

If you have application directory partitions in your forest, make sure that you make a backup
of the domain controllers that replicate those application directory partitions.

Create additional backups of domains in every geographic location where:


o Large populations of users exist.

o Critical populations of users exist, such as those who support company executives or
operate critical business units.

o Mission-critical work is performed.

o A wide area network (WAN) outage would disrupt business.

o The elapsed time that it takes to perform either of the following tasks would be cost
prohibitive because of slow link speeds, the size of the directory database, or both:

To create a domain controller in its intended domain over the network.

Or

To copy or transport installation media from a site where a backup exists to a site
that has no backup for the purpose of performing an installation from media (IFM).

Note

You can use a system state or critical-volumes backup to restore only the domain controller on
which the backup was generated or to create a new additional domain controller in the same
domain by installing from restored backup media. You cannot use a system state or critical-volumes
backup to restore a different domain controller or to restore a domain controller onto different
hardware. You can only use a full server backup to restore a domain controller onto different
hardware.

Scheduling regular backups

You can use the Backup Schedule Wizard to schedule regular, automatic critical-volumes or full
server backups of your domain controllers. You need a current, verified, and reliable backup to:

Restore Active Directory data that becomes lost.

Recover a domain controller that cannot start up or operate normally because of software
failure, hardware failure, or administrative error. For example, an administrator might have
set overly restrictive permissions, either explicitly or by using a security policy, that deny the
operating system access to the Ntds.dit file and log files.

Install AD DS from installation media that you create by using the ntdsutilifm command.

Perform a forest recovery if forest-wide failure occurs.

Immediate (unscheduled) backup

In addition to scheduling regular backups, perform an immediate backup when certain events occur
in your environment. You can use the Backup Once Wizard or the command line to back up AD DS
when the following conditions arise:

You have moved the Active Directory database, log files, or both to a different location on a
disk.

The operating system on a domain controller is upgraded.


A Service Pack is installed on a domain controller.

A hotfix is installed that makes changes to the Active Directory database.

A current backup is required for installing from backup media for a new domain controller.

The tombstone lifetime is changed administratively by changing the value in the


tombstoneLifetime attribute of the object CN=Directory Service,CN=Windows
NT,CN=Services,CN-Configuration,DC=ForestRootDomain. The tombstone lifetime value in
an Active Directory forest defines the number of days that a domain controller preserves
information about deleted objects. For this reason, this value also defines the useful life of a
backup that you use for disaster recovery or installation from backup media.

Backup frequency

The frequency of your backups depends on criteria that vary for individual Active Directory
environments. In most Active Directory environments, users, computers, and administrators make
daily changes to directory objects, such as group membership or Group Policy. For example,
computer accounts, including domain controller accounts, change their passwords every 30 days by
default. Therefore, every day a percentage of computer passwords changes for domain controllers
and domain client computers. Rolling the computer password of a domain controller back to a
former state affects authentication and replication. A percentage of user passwords might also
expire on a daily basis, and if they are lost as a result of domain controller failure, they must be reset
manually. Generally, no external record of these changes exists except in AD DS. Therefore, the
more frequently you back up domain controllers, the fewer problems you will encounter if you need
to restore this type of information.

The more Active Directory objects and domain controllers you have, the more frequent your
backups should be. For example, in a large organization, to recover from the inadvertent deletion of
a large organizational unit (OU) by restoring the domain from a backup that is days or weeks old, you
might have to re-create hundreds of accounts that were created in that OU since the backup was
made. To avoid re-creating accounts and potentially performing large numbers of manual password
resets, ensure that recent system state backups are always available to recover recent Create,
Modify, and Delete operations.

Backup frequency criteria

Use the following criteria to assess the frequency of your backups:

Small environments with a single domain controller in the forest or domains that exist in a
single physical location (that is, domains that have a single point of failure): create backups
at least daily.

Medium (10 to 49 domain controllers) and large environments (50 to 1,000 or more domain
controllers): Create backups of each unique directory partition in the forest on two different
computers at least daily with an emphasis on backing up application directory partitions,
empty root domains, domains in a single geographic site, and sites that have large
populations of users or that host mission-critical work.

Make backups with increasing frequency until you are confident that if you lose the objects that
were created or modified since the last backup, the loss would not create a disruption of your
operations. Major changes to the environment should always be immediately followed by a new
system state backup.
Note

We always recommend that you have at least two domain controllers in each domain of your
Active Directory forest.

Recovering Active Directory Domain Services


You can use the information in this section to recover Active Directory Domain Services (AD DS)
when directory services are disrupted as a result of problems with hardware, software, the network
environment, or human error. To guard against damage from these types of disruptions, make sure
that you are always prepared to restore AD DS with a timely backup of the volumes and servers that
are critical to successful operation of your forest.

When recovery of AD DS by restoration from a backup is necessary, the most common cause is
either administrative error or hardware failure. The best defense against these problems is
prevention. Be sure to take steps to protect Active Directory data from accidental deletion. You can
also manage hardware replacement in a timely fashion, before it leads to failure and loss of
Active Directory data.

Causes of disruptions

Disruptions to directory services can be caused by many conditions on a domain controller, in a


domain or forest, and with service clients and applications that use AD DS. The following are some of
the conditions that can disrupt directory services:

Reordering or changes to drive letters that cause the operating system, the directory service
file, and logs to be unavailable in their expected locations

Excessive permissions on objects in AD DS, the file system, or the registry, or explicitly
defined and assigned in Group Policy

Disk failure, which prevents access to or causes damage to the following sets of files:
operating system, directory service and log, SYSVOL, and registry or other critical system
files

Inability to restart AD DS in normal mode, for example, after an unscheduled power outage
or software update

Antivirus utilities and other utilities, such as disk optimization utilities, which prevent
unfettered access to the directory service file and logs

Inability of a domain controller to respond to Lightweight Directory Access Protocol (LDAP)


requests, logon requests, or replication requests

Inability to boot from AD DS, for example, after an unscheduled power outage or software
update

Physical site disaster, such as natural disasters or virus attacks or other security attacks

Accidental deletions in AD DS, the file system, or the registry

Rollback to a known good point in time

Corruption that is localized to a domain controller


Corruption that has replicated (the worst-case scenario)

Keys to protecting against disruptions

The keys to protecting your network from disruptions are preparation and prevention.

To make sure that you are always able to recover from disruption, prepare by scheduling backups as
follows:

Back up the volumes that are required to recover AD DS and the entire domain controller.

Back up all critical domain controllers, as described in Backing Up Active Directory Domain
Services.

Back up on a daily schedule and when significant changes are made to the registry or the
directory.

Before you introduce configuration changes on domain controllers in production, test your
configuration changes in a lab or on a test computer that mirrors the production environment in the
same way that you test hardware configuration, service pack and software update revisions,
performance load, and so on. Some configuration changes have immediate implications; some are
apparent when a single event or operation occurs (such as a reboot or service startup); and some
have chained implications (for example, if X and Y both occur, then Z occurs). Other changes have
time-based or threshold-based implications. Be sure that you are aware of all the effects of a
configuration change before you implement it in production.

The most common causes of directory service disruption requiring recovery are administrative error
and hardware failure. The best defense against these problems is prevention. You can prevent
disruptions by taking steps to protect against easily avoidable problems:

Use the Protect object from accidental deletion option in Windows Server 2008 to prevent
inadvertent deletions of critical data. For more information, see “Preventing unwanted
deletions” in this topic.

Monitor all critical services.

Manage hardware replacement in a timely fashion.

When you consider recovery options, the objective is to use the fastest method that results in the
least intrusive and most complete recovery. Options for recovery can range from repair of individual
elements to restoration of a single domain controller. In the worst-case scenario, the only option
might be to recover all domain controllers in a domain or forest.

Preventing unwanted deletions

Most large-scale deletions are accidental. In many cases, you may have to perform a recovery
operation to recover objects that have been deleted from AD DS.

In Windows Server 2008, the Active Directory Users and Computers snap-in provides the Protect
object from accidental deletion option. When enabled, Protect object from accidental deletion
implements the Deny delete subtree permission. This option is available in Active Directory Users
and Computers on the domain controller and when viewed through Remote Server Administration
Tools (RSAT) on computers running Windows Server 2008 and Windows Vista. When you enable
Advanced Features on the View menu, the Protect object from accidental deletion option is
available on the Object tab. You can open the Properties page for each container in the domain and
enable this option.

Note

CN=Users,DC=DomainName and CN=Computers,DC=DomainName are protected from deletion by


system flags on the objects.

Use this option to protect all other containers up to the domain level. Good candidates for
protection are containers that store Group Policy objects (GPOs) and Active Directory–integrated
Domain Name System (DNS) zones. When you enable the Protect object from accidental deletion
option, neither the container nor any child object can be deleted by any administrator or other user.
An administrator with the right to log on locally to a domain controller and the right to open
Active Directory Users and Computers can enable or disable the setting.

Pay particular attention to protecting organizational units (OUs) that might have been created in an
earlier version of Windows. When you create an OU by using Active Directory Users and Computers
in Windows Server 2008, the Protect container from accidental deletion check box is selected by
default. On domain controllers that are running earlier versions of Windows, you must apply the
Deny access control entries (ACEs) permission on the Security tab of the properties page of the
containers to implement protection from accidental deletion.

Recovery solutions

When you are faced with unacceptable directory service conditions that cannot be resolved reliably
by manual updates, your recovery solutions depend on data issues, hardware issues, time
constraints, and the backups that are available.

Solutions for configuration errors—nonauthoritative restore

To undo errors in configuration so that AD DS returns to a previous healthy state and is then brought
up to date through replication, perform a nonauthoritative restore from backup. This process
overwrites the current version of AD DS with the version in the backup. After replication, the
directory is current with the rest of the domain.

You can restore AD DS by using a system state backup, a critical-volumes backup, or a full server
backup. If a system state backup is available, use the system state backup to recover from registry or
directory service configuration errors. You can use a critical-volumes backup as well, but it contains
more than Active Directory data and it is not required for restoring AD DS only. Use full-server
recovery for more serious problems, as described in “Solutions for hardware failure or file
corruption” later in this topic.

Note

Nonauthoritative restore from backup requires that the domain controller is running in Directory
Services Restore Mode (DSRM). You cannot perform this procedure by stopping AD DS.

Solutions for data loss—authoritative restore

Accidental deletions can occur in any writable directory partition. Such deletions are most common
in the domain directory partition, but they can also occur in the configuration directory partition.
Objects in the schema directory partition are protected against deletion. The method for recovering
deleted objects is authoritative restore.
If you have data loss and you can identify the source and quantity of the loss, you can recover the
lost data by performing an authoritative restore. If you lose domain data, you must perform
recovery by restoring a domain controller that hosts a writable copy of the domain directory
partition where the data loss occurred. If objects are deleted from the configuration directory
partition, you can recover these objects by restoring any domain controller in the forest. There are
special considerations if the deleted objects have a forward link-back link relationship with each
other. This relationship exists for security groups and distribution groups.

Restoring group memberships

Security principals are objects that can have group memberships. Recovering deleted security
principals requires not only restoring the object itself but also restoring the group memberships of
each restored security principal. You use files that are generated by Ntdsutil during authoritative
restore to recover group memberships. Group membership is defined by linked attributes on the
group object and on the group member object: the member attribute of the group object is a
forward link attribute that links to the memberOf attribute (the back link) of the group member,
which can be a user, a computer, or another group.

If you perform the restore on a domain controller that is not a global catalog server, only group
memberships for groups that are stored in the domain are restored. If you perform the restore on a
global catalog server, group memberships in universal groups that are stored in other domains in the
forest are also restored. However, restoring memberships in domain local groups that are stored in
other domains requires additional steps that involve using the files that Ntdsutil generates during
authoritative restore.

When you authoritatively restore security principals on a domain controller that is running a version
of Windows Server later than Windows Server 2003 (that is, Windows Server 2003 with Service
Pack 1 (SP1), Windows Server 2003 Service Pack 2 (SP2), Windows Server 2003 R2, or Windows
Server 2008), the Ntdsutil command-line tool recovers group memberships automatically (restores
the memberOf value on the restored security principal object) for all groups that were created or
updated at a forest functional level of at least either Windows Server 2003 or Windows Server 2003
interim. However, replication order can undo the restored memberships in the recovery domain. For
this reason, it is best to perform the additional steps to recover group memberships in the recovery
domain as well.

Methods of authoritative restore

Depending on replication conditions in the domain of the deletions, you can use the following
methods to perform an authoritative restore:

Nonauthoritative restore from backup, followed by authoritative restore: Unless you can
isolate a domain controller that has not received the deletions, authoritative restore must
be preceded by a nonauthoritative restore from backup to restore the directory to a former
state that contained the deleted objects. With the deleted objects restored, you can mark
them as authoritative so that replication does not overwrite them with the delete condition
that still exists on the other domain controllers in the domain.

Authoritative restore only: If you identify the data loss quickly and you can isolate a global
catalog server in the domain where the deletion occurred that has not received replication
of the deletions, you can mark the objects as authoritative on the global catalog server and
avoid performing an initial restore from a backup (nonauthoritative restore). This option
depends on your ability to stop inbound replication on the global catalog server before
replication of the deletions is received. Global catalog servers often have longer replication
latency than other domain controllers. Global catalog servers are preferred as recovery
domain controllers because they store more group information. However, any latent domain
controller in the domain of the deletions that has not received replication of the deletions
can serve as the recovery domain controller if you want to avoid restoring from backup.

Recovery options with no available backup

If you have data loss but you do not have a backup, you must recreate the deleted objects. As an
alternative, where data loss is minimal, you might be able to recover lost data by using the undelete
capability that recovers objects by reanimating the object tombstone (the retained record of the
object deletion). The Windows Server 2003 and Windows Server 2008 directory database supports
an LDAP application programming interface (API) that reanimates the tombstone of a single object
(that is, it “undeletes” the object). This API is available for developing applications to restore the
attributes that are preserved on tombstones, which include the object security identifier (SID),
globally unique identifier (GUID), and security descriptor, as well as any indexed attributes. On
domain controllers that are running Windows Server 2003 with SP1, Windows Server 2003 with SP2,
Windows Server R2, or Windows Server 2008, the sIDHistory attribute is also retained. All other
attributes must be recreated. In the case of a deleted user object, you must repopulate attributes to
re-establish group memberships, profile path, home directory, and contact information. You must
also reset passwords and communicate the password to the users so they can log on to the domain.

Solutions for hardware failure or file corruption

If you have hardware issues that require the replacement of the hard drive on a domain controller,
you must either recover the full server to the new hardware or reinstall the operating system. If you
have widespread corruption in the file system, your best solution is also full server recovery or
reinstallation. To decide whether or not to perform a full server recovery, consider the following
conditions:

A full server recovery reformats and repartitions all disks that are attached to the server.

A full server recovery might be more time consuming than reinstalling the operating system.

Reinstallation requires a cleanup of server metadata on the failed domain controller.

Reinstallation results in data loss. All servers have roles and features installed. Each role has
configuration state in AD DS, the file system, and the registry, and a role frequently has its
own data store. For example, the server might be configured for DNS, Dynamic Host
Configuration Protocol (DHCP), Windows Internet Name Service (WINS), administration
tools, and registry settings for maximum transmission unit (MTU), maxPacketSize, and
security. If you have to reinstall, you must either export and import all these settings or
recreate them. This method is certain to be time consuming and error prone.

Reinstalling and restoring criteria

In general, use the following criteria to the decide whether to reinstall or restore a domain controller
from backup:

Reinstall the operating system under the following conditions:

o You do not have an available backup.


o You must have the domain controller back online as soon as possible and
reinstallation is faster than restoring.

o You have exhausted all known avenues of troubleshooting a fault or error condition,
and continued troubleshooting is not likely to succeed or will result in diminishing
returns with more time spent.

Perform a full server restore of the domain controller under the following conditions:

o Reinstalling will result in an unacceptable loss of data.

o You want to recover from localized or replicated corruption.

o The domain controller is running other server services, such as Exchange, or it


contains other data that you must restore from a backup.

Restoring AD DS after reinstalling the operating system

If you reinstall the operating system, you can restore AD DS in one of the following ways:

Use Dcpromo to reinstall AD DS and allow replication from another, healthy domain
controller in the domain to update the domain controller.

Restore AD DS from backup (nonauthoritative restore). Then, allow replication from


another, healthy domain controller in the domain to update the domain controller. This
method requires less replication than reinstalling AD DS.

Install AD DS from installation media. This method, called install from media (IFM), requires
that you have created installation media that can be used to install AD DS. You use Ntdsutil
to create the media on a healthy domain controller in the domain. In this case, recovery is
faster because Active Directory replication is not required.

References:
http://technet.microsoft.com/en-us/library/cc816584(v=WS.10).aspx - Backing Up Active Directory
Domain Services

http://technet.microsoft.com/en-us/library/cc816751(v=WS.10).aspx - Recovering Active Directory


Domain Services

Labs:

- Perform a backup of your Active Directory database, and restore it onto a fresh formatted
server.