Active Directory

Fundamentals

Lowell Vanderpool
TECH SAVVY PRODUCTIONS
CONTACT US:
[email protected]
SUPPORT US:
If you would like to support the channel, Join our channel membership, it’s
$2.99/month (less than a Starbucks coffee); see the “Join” button on our channel
homepage.

OR
Subscribe to the channel as it helps our channel perform better on YouTube’s
algorithm.

SOCIAL MEDIA AND WEBSITE:

Check out our Website: https://www.techsavvyproductions.com

Mr.V Linkedin: https://www.linkedin.com/in/lowell-vanderpool-57970623/

Page | 1
 We translate subtitles on our videos into the
many languages.

Page | 2
https://activedirectoryfaq.com/

Active Directory

Active Directory Service (ADSI) is a COM-based service providing a mechanism for

locating, identifying, and accessing the users and resources available in a distributed
computing environment system. In particular, the Active Directory service is used to
manage enterprise directory information for distribution by a Windows domain
server.

https://www.dnsstuff.com/active-directory-best-practices

Virtualized Domain Controllers: 4 Myths and 12 Best Practices

Kerberos and Active Directory

Active Directory Replication: A Guide for IT Pros

Virtualized Domain Controllers: 4 Myths and 12 Best Practices
Kerberos and Active Directory
What is Active Directory?
What is Active Directory: The Ultimate Guide
Active Directory Glossary
Functional Overview
What about Microsoft LAPS?
Remote Server Administration Tools for Windows 10/11
Lightweight Directory Access Protocol
Azure Active Directory
Active Directory Replication: A Guide for IT Pros

Page | 3
What is Active Directory?
For more information, visit www.netwrix.com
Brian Svidergol
Introduction

Page | 4
Page | 5
IT administrators have been working with and around Active Directory since the
introduction of the technology in Windows 2000 Server. Windows 2000 Server
was released on February 17, 2000 but many administrators began working with
Active Directory in late 1999 when it was released to manufacturing (RTM) on
December 15, 1999.

This e-book is intended not only for beginner SysAdmins who want learn about
Active Directory structure, key terminology and configurations. More experienced
administrators will find a few best practices of AD management and discover the
areas that are often lesser known to IT pros.

Page | 6
Every Active Directory design includes at least one organizational forest.

Page | 7
https://youtu.be/6yonrl3LU58

I. Introduction to Directory Services Technologies

Like many other areas of IT, directory services has rapidly expanded with new
features and functionality along with additional complexity. Instead of a single
directory product such as AD DS, there are quite a few other services that make
up the directory services category. In addition to the Microsoft solutions, many
third-party vendors are creating products that standalone on their own or
enhance and expand the Microsoft offerings.

Page | 8
Today, directory services technologies from Microsoft includes the following
products:

Active Directory Domain Services (AD DS).

• AD DS is the core focus of this e-book so it doesn’t require an introduction.
But, how about an interesting fact instead?

• According to Microsoft Corporate Vice President Takeshi Numoto, Active

Directory is used by 93% of the Fortune 1000.

What's new in Active Directory Domain Services for Windows

Server 2016
• 08/15/2022

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016

Page | 9
The following new features in Active Directory Domain Services (AD DS) improve
the ability for organizations to secure Active Directory environments and help
them migrate to cloud-only deployments and hybrid deployments, where some
applications and services are hosted in the cloud and others are hosted on
premises. The improvements include:

• Privileged access management

• Extending cloud capabilities to Windows 10 devices through Azure
Active Directory Join
• Connecting domain-joined devices to Azure AD for Windows 10
experiences
• Enable Windows Hello for Business in your organization
• Deprecation of File Replication Service (FRS) and Windows Server 2003
functional levels

Privileged access management

Privileged access management (PAM) helps mitigate security concerns for Active
Directory environments that are caused by credential theft techniques such pass-
the-hash, spear phishing, and similar types of attacks. It provides a new
administrative access solution that is configured by using Microsoft Identity
Manager (MIM). PAM introduces:

• A new bastion Active Directory forest, which is provisioned by MIM.

The bastion forest has a special PAM trust with an existing forest. It
provides a new Active Directory environment that is known to be free
of any malicious activity, and isolation from an existing forest for the
use of privileged accounts.
• New processes in MIM to request administrative privileges, along with
new workflows based on the approval of requests.
• New shadow security principals (groups) that are provisioned in the
bastion forest by MIM in response to administrative privilege requests.
The shadow security principals have an attribute that references the
SID of an administrative group in an existing forest. This allows the
shadow group to access resources in an existing forest without
changing any access control lists (ACLs).
• An expiring links feature, which enables time-bound membership in a
shadow group. A user can be added to the group for just enough time

Page | 10
 required to perform an administrative task. The time-bound
membership is expressed by a time-to-live (TTL) value that is
propagated to a Kerberos ticket lifetime.

Note

Expiring links are available on all linked attributes. But the

member/memberOf linked attribute relationship between a group and
a user is the only example where a complete solution such as PAM is
preconfigured to use the expiring links feature.

• KDC enhancements are built in to Active Directory domain controllers

to restrict Kerberos ticket lifetime to the lowest possible time-to-live
(TTL) value in cases where a user has multiple time-bound
memberships in administrative groups. For example, if you are added
to a time-bound group A, then when you log on, the Kerberos ticket-
granting ticket (TGT) lifetime is equal to the time you have remaining
in group A. If you are also a member of another time-bound group B,
which has a lower TTL than group A, then the TGT lifetime is equal to
the time you have remaining in group B.
• New monitoring capabilities to help you easily identify who requested
access, what access was granted, and what activities were performed.

Requirements for Privileged access management

• Microsoft Identity Manager

• Active Directory forest functional level of Windows Server 2012 R2 or
higher.

Azure AD Join

Azure Active Directory Join enhances identity experiences for enterprise, business
and EDU customers- with improved capabilities for corporate and personal
devices.

Benefits:

• Availability of Modern Settings on corp-owned Windows devices.

Oxygen Services no longer require a personal Microsoft account: they

Page | 11
 now run off users' existing work accounts to ensure compliance.
Oxygen Services will work on PCs that are joined to an on-premises
Windows domain, and PCs and devices that are "joined" to your Azure
AD tenant ("cloud domain"). These settings include:
o Roaming or personalization, accessibility settings and
credentials
o Backup and Restore
o Access to Microsoft Store with work account
o Live tiles and notifications
• Access organizational resources on mobile devices (phones, tablets)
that can't be joined to a Windows Domain, whether they are corp-
owned or BYOD.
• Single-Sign On to Office 365 and other organizational apps, websites,
and resources.
• On BYOD devices, add a work account (from an on-premises domain
or Azure AD) to a personally owned device and enjoy SSO to work
resources, via apps and on the web, in a way that helps ensure
compliance with new capabilities such as Conditional Account Control
and Device Health attestation.
• MDM integration lets you auto-enroll devices to your MDM (Intune or
third-party).
• Set up "kiosk" mode and shared devices for multiple users in your
organization.
• Developer experience lets you build apps that cater to both enterprise
and personal contexts with a shared programing stack.
• Imaging option lets you choose between imaging and allowing your
users to configure corp-owned devices directly during the first-run
experience.

For more information, see, Introduction to device management in Azure Active

Directory.

Page | 12
https://youtu.be/fRKT6Z9rgUw

He has shown you, O mortal, what is good.

And what does the Lord require of you?

To act justly and to love mercy

and to walk humbly with your God.

Windows Hello for Business

Windows Hello for Business is a key-based authentication approach for

organizations and consumers that goes beyond passwords. This form of
authentication relies on breach, theft, and phish-resistant credentials.

The user logs on to the device with a biometric or PIN logon information that is
linked to a certificate or an asymmetrical key pair. The Identity Providers (IDPs)
validate the user by mapping the public key of the user to IDLocker and provides
log on information through One Time Password (OTP), Phone or a different
notification mechanism.

Page | 13
For more information, see, Windows Hello for Business

Deprecation of File Replication Service (FRS) and Windows Server 2003

functional levels

Although File Replication Service (FRS) and the Windows Server 2003 functional
levels were deprecated in previous versions of Windows Server, it bears repeating
that the Windows Server 2003 operating system is no longer supported. As a
result, any domain controller that runs Windows Server 2003 should be removed
from the domain. The domain and forest functional level should be raised to at
least Windows Server 2008 to prevent a domain controller that runs an earlier
version of Windows Server from being added to the environment.

At the Windows Server 2008 and higher domain functional levels, Distributed File
Service (DFS) Replication is used to replicate SYSVOL folder contents between
domain controllers. If you create a new domain at the Windows Server 2008
domain functional level or higher, DFS Replication is automatically used to
replicate the SYSVOL folder. If you created the domain at a lower functional level,
you will need to migrate from using FRS to DFS replication for the SYSVOL folder.
For migration steps, you can either follow these steps or you can refer to
the streamlined set of steps on the Storage Team File Cabinet blog.

The Windows Server 2003 domain and forest functional levels continue to be
supported, but organizations should raise the functional level to Windows Server
2008 (or higher if possible) to ensure SYSVOL replication compatibility and
support in the future. In addition, there are many other benefits and features
available at the higher functional levels higher. For more information, see the
following resources:

• Understanding Active Directory Domain Services (AD DS) Functional

Levels
• Raise the Domain Functional Level
• Raise the Forest Functional Level

Page | 14
In this guide AD design
Understanding AD DS Design

Identifying Your AD DS Design and Deployment Requirements

Mapping Your Requirements to an AD DS Deployment Strategy

Designing the Logical Structure for Windows Server 2008 AD DS

Designing the Site Topology for Windows Server 2008 AD DS

Enabling Advanced Features for AD DS

Evaluating AD DS Deployment Strategy Examples

Appendix A: Reviewing Key AD DS Terms

Page | 15
 If I speak in the tongues of men or of angels, but do not have love, I am only a
resounding gong or a clanging cymbal. If I have the gift of prophecy and can
fathom all mysteries and all knowledge, and if I have a faith that can move
mountains, but do not have love, I am nothing. If I give all I possess to the
poor and give over my body to hardship that I may boast, but do not have love, I
gain nothing.

Love is patient, love is kind. It does not envy, it does not boast, it is not proud. It
does not dishonor others, it is not self-seeking, it is not easily angered, it keeps
no record of wrongs. Love does not delight in evil but rejoices with the truth. It
always protects, always trusts, always hopes, always perseveres.

AD DS Troubleshooting
• 07/29/2021

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2

This section includes troubleshooting recommendations and procedures for

diagnosing and fixing problems that may occur during Active Directory replication.
It focuses on how to respond to Directory Service event log entries and how to
interpret messages that tools such as Repadmin.exe and Dcdiag.exe might report.

Repadmin.exe and Dcdiag.exe are available on all domain controllers that run
Windows Server 2012 R2 or later versions. For more information about how to
use these tools to troubleshoot problems, see the following articles.

• Configuring a Computer for Troubleshooting Active Directory

• Troubleshooting Active Directory Replication Problems

Another useful technology is Event Tracing for Windows (ETW). You can use ETW
to troubleshoot LDAP communications among the domain controllers. For more
information, see Using ETW to troubleshoot LDAP connections.

You can also install Remote Server Administration Tools (RSAT) on a member
server that is running Windows 10. For information about how to install RSAT,
see Remote Server Administration Tools.

Page | 16
Active Directory Lightweight Directory Services (AD LDS).
AD LDS is the lightweight, developer- friendly, directory that can be deployed on a
client computer and client operating system as well as on a server. It isn’t as full
featured as AD DS (for example, Group Policy isn’t part of it) but it can be useful
as a decentralized directory for developers and testers.
Active Directory Federation Services
• 07/29/2021

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012

This document contains a list of all of the documentation areas for AD FS for Windows
Server 2016, 2012 R2, and 2012. This includes the following:

• AD FS Overview
• AD FS Design
• AD FS Deployment
• AD FS Development
• AD FS Operations
• AD FS Technical Reference

Active Directory Federation Service (AD FS) enables Federated Identity and Access Management
by securely sharing digital identity and entitlements rights across security and enterprise
boundaries. AD FS extends the ability to use single sign-on functionality that is available within a
single security or enterprise boundary to Internet-facing applications to enable customers,
partners, and suppliers a streamlined user experience while accessing the web-based
applications of an organization.

Page | 17
https://youtu.be/_jOY-EIDTxk

Page | 18
 Of making many books there is no end, and much study wearies the body.

Now all has been heard;

here is the conclusion of the matter:

Fear God and keep his commandments,

for this is the duty of all mankind.

For God will bring every deed into judgment,

including every hidden thing,

whether it is good or evil.

Active Directory Federation Services (AD FS)

AD FS is a claims-based identity solution that helps independent organizations

connect their directory services technologies together to facilitate single sign-on
and cross-organizational resource access.

Today, it has become a fairly common solution because it helps organizations

connect to cloud services such as Microsoft Azure.

Additionally, there are two other roles that you may be wondering about. Active
Directory Certificate Services (AD CS) and Active Directory Rights Management
Services (AD RMS) are often grouped in with the other technologies listed above
to form the suite of technologies offered by Microsoft for on-premise Active
Directory related deployments.

Page | 19
Additionally, there are products outside of the immediate Active Directory family
such as Microsoft Forefront Identity Manager (FIM). Beyond the on-premise
technologies, there are also several cloud-based solutions that offer services in
the cloud such as Azure Active Directory and Azure Multi-Factor Authentication.
For this white paper, we are focusing on AD DS deployed on-premise.

II. Administration Tools

There are numerous tools for Active Directory. The tool that we will cover today is
Active Directory Users and Computers (ADUC), which was released with Windows
2000 Server. ADUC is an MMC snap-in that enables administrators to manage

Page | 20
Active Directory objects, including users, computers, groups, organizational units
(OUs), and attributes.

Page | 21
While the features of ADUC and many other features have been added to a
new tool named Active Directory Administrative Center, ADUC remains a popular
tool that administrator’s use to manage their environment.

Page | 22
In addition to managing objects, ADUC can also manage domain operations. For
example, you can raise the domain functional level from ADUC. You can also
transfer the RID, PDC Emulator, and Infrastructure FSMO roles to a different
domain controller by using ADUC.

Page | 23
Page | 24
Managing an object consists of some of the more obvious tasks such as
• Resetting a user’s password,
• adding users to security groups,
• and moving computer objects.

However, the Advanced Features setting within ADUC can also allow you to
manage the LostAndFound container, NTDS Quotas, Program Data, and System
information.

This view is not enabled by default but you can enable through the View menu.

Page | 25
The Advanced Features option adds many tabs to the properties page of an
object, including Published Certificates, Attribute Editor, Password Replication,
and others.

The View menu also allows you to filter the view based on the object type, such as
user, computer, printer and more. Individual columns can also be added or
removed, to customize the view to include other attributes that have been
assigned to the object, for example the last modify date, city, country, email
address, and more.
Finally, ADUC also enables you to delegate control of objects through the
Delegation of Control wizard or by manually modifying permissions on an object.

Inside AD
There are many aspects to an AD DS deployment. In this white paper, we will look
at domain controllers, the AD DS database, and SYSVOL. While we only focus on
parts of these three components in this e-book, other parts and components are
also important.

Domain Controllers
The domain controller is the backbone of Active Directory. Without a domain
controller, you can’t have a directory!

You can use up to 1,200 domain controllers in a single domain.

But, don’t judge another administrator’s environment by the size or scale of it!
Let’s look at the evolution of the domain controller:
Windows NT 3.1 introduced the original Microsoft domain. Windows NT 3.1
(subsequently 3.5 and then 3.51) should not be confused with Windows 3.1 which
was a 16-bit client operating system. The domain functionality included with
Windows NT was not a multi-master model like AD DS. Thus, there was a primary
domain controller (PDC) and backup domain controllers (BDCs).

All changes were handled by the PDC. A BDC could be promoted to a PDC in a
disaster recovery situation.

Page | 26
Today, we have the PDC Emulator FSMO role which is directly related to the
original PDC.

https://youtu.be/OXvGAAnu7FE

Windows 2000 Server introduced Active Directory.

With the release of Windows
2000 Server, Microsoft revamped a large amount of the traditional domain and
marketed the service as Active Directory. A key feature of Active Directory was
the multi-master model which allowed most of the Active Directory functionality,
including changes, to take place on any DC in the domain.

Windows Server 2003 introduced new features.

With Windows Server 2003, Active Directory was updated with some
administrative enhancements (such as multiselecting objects in ADUC), added the
ability to create forest trusts, and added the universal group membership caching
feature. Other features were added or expanded too, especially around
command-line administration.

Page | 27
Windows Server 2003 R2 introduced AD FS and Active Directory
Application Mode (ADAM).
AD FS and ADAM were big enhancements, especially looking at them today
in 2015. Back then, they weren’t used much though. ADAM later became AD LDS
while AD FS was updated along the way for cloud integration.
7
Windows Server 2008 introduced read-only domain controllers
(RODCs) and fine-grained password policies.
With Windows Server 2008, RODCs became an option
which allowed administrators to deploy DCs in insecure computer closets at
branch offices, among other uses. In addition, fine-grained password policies
were introduced, albeit with some administrative challenges such as not having a
graphical user interface to manage the policies.

Windows Server 2008 R2 introduced the recycle bin and the

PowerShell module.
Windows Server 2008 R2 continued refining some of the features introduced in
Windows Server 2008 and offered the Recycle Bin and a PowerShell module
which
was paramount for administrators to be able to effectively manage AD DS from
PowerShell.

Page | 28
 https://youtu.be/-bsLmDfvF1Y

Page | 29
 Windows Server 2012 introduced simplified management and
enhanced virtualization support.
The long awaited graphical user interface tools to manage the Recycle
Bin and fine-grained password policies were introduced. Additionally,
virtualization was enhanced and support for virtualizing DCs became mainstream.
See https://technet.microsoft.com/en-us/library/hh831477.aspx for a complete
guide on the changes.

Windows Server 2012 R2 focused on security enhancements.

New features included multi-factor authentication, single sign-on from connected
devices, and multi-factor access control. See https://technet.microsoft.com/en-
us/library/dn268294.aspx for a complete guide on the changes.

Page | 30
Inside AD
There are some good practices to adhere to when deploying DCs. Many of these
practices are documented. But not many organizations are implementing these
practices. We will skip over the well-known good practices such as maintaining
the Active Directory database on one set of disk spindles, the log files on
separate disk spindles, and the operating system on its own set of disk spindles.

Some of the lesser implemented good practices for domain controllers are:
Many administrators avoid change, especially for systems such as AD DS that are
incredibly stable. So when a new administrator proposes switching over to the
Server Core installation, he is often met with icy stares.

But the reality is that most administrators administrate AD DS remotely by

launching ADUC or PowerShell on their client or administrative computer.

All of the core management tools including the Active Directory Administrative
Center (ADAC) and Windows PowerShell work almost identically when used
locally on a DC or remotely from a client computer or an administrative computer.

Thus, by moving to the Server Core installation, the administrative experience

isn’t degraded. And, you gain security enhancements and some small
performance enhancements.

Run the Server Core installation of the operating system

Back in the old days, like 10 years ago, most organizations used physical servers
because virtualization was in its infancy. So, when it was time to provision a new
file server, DHCP server, or print server, administrators often just tapped an
existing server.

A DC was often used too. Fast forward to 2015 when virtualization is the de facto
standard and automated provisioning helps deliver a new VM in minutes and the
old way of doing things isn’t nearly as compelling.

Page | 31
Do not run other software or services on a DC
Now, when you need a place for a file server, DHCP server, print server, or some
other application server, you can provision a new VM. Or, better yet, you can
provision a new VM as a utility server. A utility server is a server that hosts all of
the applications and services that are too small to warrant a dedicated server.

This allows your DCs to stick with a dedicated service which brings more stability.

While all of your read-write DCs should be in a secure data center, there are
plenty of IT and non-IT people that have access to the data center. For example,
the contracted electricians that works on the cooling system have data center
access. In addition, there are likely network guys, cabling guys, and IT
management with data center access. Anybody that has physical access to a DC
can gain access to a physical DC in only a couple of minutes at a console in the
data center. There are specialized freeware boot images available that you can
use to boot into and reset passwords, install malware, or gain access to the disk
data, assuming that the disk isn’t encrypted. To avoid this, perform the following
configurations:

Security for your domain Controller:

• Adjust the startup order and set a BIOS password

• Ensure that all removable media is not part of the BIOS boot order
• TPM
• Secure Boot
• Locked hardware enclosure for unauthorized removal

Instead, only the hard disk where the operating system installed should be part
of the boot order. This is true for your virtualization host servers too, if you have
virtual DCs.

Set a strong BIOS password.

If you don’t set a BIOS password, somebody can
update the boot order, boot to the Windows Server installation media or many

Page | 32
freeware toolkits, perform a repair to get to a command prompt. Once at the
command prompt, they can wreak some havoc and quickly reset passwords for
domain accounts.

Keep the DCs in a locked cabinet.

While a BIOS password is one layer of security, if
the attacker is semi-capable, he or she will likely know how to reset the BIOS so
that the configuration resets and password is removed. Often, this requires
gaining access to the motherboard. You can reduce the risk of such an attack by
keeping DCs in a locked cabinet. Some servers also allow for chassis locks. In high
security environments, you should opt for both.

You should try to match the configuration settings for each DC. You can
accomplish some of this by using build automation through deployment tools
such as System Center Configuration Manager. Items of interest for DCs are the
event log size settings to ensure that you have large sizes to capture auditing and
security related information, boot settings such as the timeout waiting for OS
selection on physical servers, firmware and BIOS versions and settings, and
hardware configuration. Of course, there are many other configuration items to
standardize by using Group Policy.

The primary goal is to configure the DCs identically.

Standardize the configuration of all domain controllers.

SYSVOL
The system volume (SYSVOL) is a special directory on each DC. It is made up of
several folders with one being shared and referred to as the SYSVOL share. The
default location is %SYSTEMROOT%\SYSVOL\sysvol for the shared folder,
although you can change that during the DC promotion process or anytime
thereafter.

Page | 33
SYSVOL is made up of:

The folders are used to store:

• Group Policy templates (GPTs), which are replicated via SYSVOL container
(GPC) is replicated via Active Directory replication

• Scripts, such as startup scripts that are referenced in a GPO.

Junction points. Junction points work like a shortcut. One directory can
point to a different directory. In File Explorer, a junction point and a
directory look and feel the same. You can view junction points by running
the dir /AL /S command.

SYSVOL replication occurs over DFSR. Initially with Windows 2000 Server,
Windows Server 2003, and Windows Server 2003 R2, replication was handled by
File Replication Service (FRS).

Starting with domains created in Windows Server 2008, DFSR is the

default SYSVOL replication method. FRS wasn’t very efficient. Any time that a file
in SYSVOL changed, FRS replicated the entire file to all domain controllers. With
DFSR, only the changed part of the file is replicated, although only for files over
64KB. DFSR uses Remote Differential Compression (RDC). RDC is what enables the
replication of only changed data.

Some admins may remember migrating from FRS to DFSR when

Windows Server 2008 was released. Without reliable and timely replication, one
side effect that users may experience is inconsistent GPO application since the
SYSVOL data may not be in sync across all of the DCs.

Page | 34
IV. Forests, Domains, Trusts
Forests and domains are fairly well understood by administrators. Trusts aren’t
though. In this section, we’ll take a look at some portions of forests, domains,
and trusts and discuss some good practices around them.

Forests
A forest is the top most logical container in an AD DS environment. It was first
introduced with Active Directory in Windows Server 2000. A forest is made up of
one or more domains and all of the objects in the domains. In the database, a
forest is a just a container, similar to many of the objects below it such as
domains and OUs. Importantly, the forest is the defined security boundary for an
AD DS environment. In the early days of Active Directory, the domain was
originally defined as the security boundary. Unlikely many of the other
components that we discuss in this white paper, there aren’t any direct
limitations on the number of forests that you can deploy. Since they are the top
most object, you can create as many as you want, assuming that you have enough

Page | 35
physical servers or VMs (don’t take this as a recommendation though!).

There are three forest-wide directory partitions in a forest:

• Schema.

The schema partition defines all of the classes, objects, and attributes that
can be used. The schema is shared among all of the domains in the forest. Objects
such as users, groups, and OUs are defined in the schema.

• Configuration

The configuration partition is responsible for managing the forest

topology, forest settings, and domain settings. You can find a list of all of the
domains, DCs, and GCs in the configuration partition. You can view the
configuration partition in a domain named contoso.com by viewing
cn=configuration,dc=contoso,dc=com in ADSIEdit.

• Application

Page | 36
The application partition is used to store application data. A common
example of data in the application partition is DNS.

Of the 5 FSMO roles, 2 of the roles are specific to the forest:

Schema Master.
This role is used for schema updates. As such, the role holder
must be online and available to perform a schema update.

Domain Naming Master.

This role is used to add and remove domains for the forest. As such, the role
holder must be online and available to perform domain additions and removals.

Page | 37
Forests, Domains, Trusts
There is a good amount of guidance around Active Directory forests published on
the internet.

Below are some of the recommended practices surrounding forests:

Always start with a single forest.
Then, if you have requirements that cannot be
met with a single forest implementation, begin adding forests as necessary. Better
yet, go back and validate the requirements first.

Using multiple forests in a production environment is often unnecessary and adds

management overheard and unneeded complexity.

With a backend technology that everybody expects to be always running, you

should opt for a simple implementation that is implemented and maintained
based on good practices, as opposed to a multi-forest implementation with a
large number of domain controllers.

Page | 38
For many environments, a single production forest will meet or exceed
requirements.

Additionally, it is a good idea to have a second non-production forest to use for

development, testing, and quality assurance.

Avoid the empty forest root domain.

Upon initial release of Active Directory, Microsoft recommended using an empty

forest root domain which would form a security
boundary for enterprise objects stored in the root domain such as the Enterprise
Admins group. However, not long thereafter, the guidance changed and the
empty forest root was no longer recommended by default. Administrators found
that maintaining the empty forest root domain added to the administrative
overhead of their environment without returning much value.

Today, the latest thinking is forest reduction. Minimize the total number of
forests.

If using two-way forests trusts, consolidate forests.

Page | 39
Each forest that you maintain requires administrative overhead. In addition, each
forest increases the complexity of your environment which also makes it harder
to secure, maintain, and recover.

If you are using two-way trusts between forests, you should strongly consider
consolidating forests because a two-way trust between forests is effectively a
single forest with extra overhead.

Page | 40
Active Directory Forests Best Practices
AD forests have been around since 2000, so there are many different theories
about the best way to configure Active Directory and forests. Current best
practices include:
• When possible, consolidate to a single forest
• Secure resources and data via GPO and apply a least privileged model
• Use GPOs to further limit users ability to create new folders without
following a set process. The least privileged permissions model.
• Give your domain admins a 2nd admin account they use only when
required per the change management process.
• If you have multiple AD forests with trust relationships, consider
consolidation.
• If you need to create a restricted access forest, make sure it is truly
restricted. As secure as we want the primary forest to be, a restricted

Page | 41
 access forest should be Castle Black. Put a 700’ wall around it and keep it
there.

Domains
A domain is the logical container that sits directly below the forest container.
Previous to Active Directory, there was a Windows domain that was part of
previous Windows Server versions. It had similar core functionality as an Active
Directory domain but without a forest above it. Historically, the beginning of the
domain as we know it goes back to X.400 which is a telecommunications standard
first recommended in 1984!

Each domain is contained in a single forest container. A domain houses other

containers and objects below it. In the early days of Active Directory, the domain
was originally defined as the security boundary. However, that definition has
been updated and now the forest is defined as the security boundary. That was a
key change that went unnoticed by some administrators.

Page | 42
From a scalability perspective, you can have a very large number of domains in a
single forest, as follows:

Once you use the Windows Server 2003 forest functional level or a higher level, a
single forest can support up to 1,200 domains.

Several components work together in a domain. A domain includes the following

components:

• Schema

• Global catalog

• Replication service

• Operations master roles

The schema, defined earlier in the Forest section, defines objects that are used in
a domain. These can be both physical and logical objects. For example, a physical
computer is represented by a computer account object, while a subnet is
represented by a subnet object. Objects have many attributes. Object attributes
define the properties, limits, and format of the objects. Attributes can be multi-
valued, strings, integers, Boolean (true or false), or many other types. The specific
attributes that an object has is defined by the schema.

A global catalog server stores information about every object within a domain.
Administrators and users query a global catalog server to find information about
objects. For example, if an administrator needs to look up information about a
user account, including address, phone number, and office location, he
would query the global catalog server to retrieve the information.

Page | 43
The operations master roles, also known as flexible single master operations
(FSMO) roles, perform specific tasks within a domain. The five FSMO roles are:

• Schema Master

• Domain naming Master

• Infrastructure Master

• Relative ID (RID) Master

• PDC Emulator

Page | 44
In every forest, there is
a single Schema and
Domain naming Master which are discussed in the Forest section of this e-book.

In each domain,
• 1 Infrastructure Master

• 1 RID Master

• 1 PDC Emulator

At any given time, there can only be one DC performing the functions of each
role. Therefore, a single DC could be running all five FSMO roles, however, there
can be no more than five servers in a single-domain environment that run the
roles.

Page | 45
For additional domains, each domain will contain its

• own Infrastructure Master

• RID Master

• PDC Emulator

Windows 2000 Server. Upon initial release, Active Directory supported up to 800
domains in a single forest.

The RID Master provisions RIDs to each DC in a domain. New objects in a

domain, such as a user or computer object, receive a unique security identifier
(SID). The SID includes a domain identifier, which is unique to each domain, and

Page | 46
a specific RID for each object. Combining the two ensures that every object in the
domain has a unique identifier, but contains both the domain SID and the RID.

The PDC Emulator controls authentication within a domain, whether

Kerberos v5 or NTLM. When a user changes their password, the change is
processed by the PDC Emulator.

Finally, the Infrastructure Master synchronizes objects with the global

catalog servers. The infrastructure Master will compare its data to a global catalog
server’s data and receive the data not found in its database from the global
catalog server.

If all DCs in a domain are also global catalog servers, then all DCs will have up-to-
date information, assuming that replication is
functional. In such a scenario, the location of the Infrastructure Master role is
irrelevant since it doesn’t have any real work to do.

Page | 47
Trusts
A trust is a relationship between forest and/or domains. In a forest, all of the
domains trust each because a two-way transitive trust is created when each
domain is added.

This allows authentication to pass through from one domain to any other domain
in the same forest.

You can create trusts outside of the forest too with other AD DS forests and
domains or Kerberos v5 realms. Back in the days of Windows NT 4.0, there wasn’t
a forest or a hierarchical structure. If you had multiple domains, you had to
manually create trusts between them.

With Active Directory, you automatically have two-way transitive trusts between
domains in the same forest. Back with Windows NT 4.0, you had to use NetBIOS
to establish trusts too! Luckily, things have come a long way and now we’ve got
additional trust functionality, especially around securing trusts with selective
authentication and SID filtering.

Each trust in a domain is stored as a trustedDomain object (TDO) in the System

container. Thus, to find and list all of the trusts and trust types in a domain named
contoso.com, run the Windows PowerShell command:

Get-ADObject –SearchBase “cn=system,dc=contoso,dc=com” –

Filter * -Properties trustType | where {$_.objectClass –eq
“trustedDomain”} | select Name,trustType

There are 4 valid values for the trustType attribute. However, only the value 1
(indicating a trust with an NT domain) and the value 2 (indicating a trust with an
Active Directory domain) are common. There is a lot of other good information
about trusts stored in the trustedDomain object. In a domain named
contoso.com, run the Windows PowerShell command to look at all of the trust
properties:
Get-ADObject –SearchBase “cn=system,dc=contoso,dc=com” –Filter
* -Properties * | where {$_.objectClass –eq “trustedDomain”} |
FL

Page | 48
You can also view many of the core properties of a trust by running the Get-
ADTrust
–Filter * command. The table below shows the trust properties and a description
of
each property.
DisallowTransivity I think this is a Microsoft typo as it really should be
“DisallowTransitivity”. This can be set to
True or False based on whether the trust disallows tranitivity.
Direction
Valid values are bidirectional, inbound, or outbound. Note that the direction is
relative to the
domain in which you are running the query.
Trust property Property description
DistinguishedName The DN of the trusted domain object.
ForestTransitive This is set to True when a forest trust is transitive and False when
a forest trust is
non-transitive.
IntraForest This is set to True when a trust is between domains in the same forest
or set to False when
a trust is between domains in different forests.
IsTreeParent Valid values are True and False.
IsTreeRoot Valid values are True and False.
Name The name of the domain that is part of the trust, not the domain where the
query is run.
ObjectClass This is set to trustedDomain for trusts.
ObjectGUID
Globally unique identifier for the trust.
An example is de207451-51ed-44cd-4248- 85ad9fcb2d50.
SelectiveAuthentication Set to True if the trust is configured for selective
authentication or False if it isn’t.
SIDFilteringForestAware Set to True if a forest trust is configured for selective
authentication.
SIDFilteringQuarantined Set to True when SID filtering with quarantining is used
for a trust. Used for external trusts
only.

Target Set to the domain name of the other side of the trust.

Page | 49
Source Set to the DN of the trust root. In a forest trust, the DN of the root domain
of the forest is the
source.
TGTDelegation Set to True if Kerberos full delegation is enabled on outbound
forest trusts. Default is False.
TrustAttributes Set to a numerical value indicating the trust configuration.
TrustedPolicy Undocumented.
TrustingPolicy Undocumented.
TrustType
Set to Uplevel for trusts with Active Directory forests and domains, DownLevel for
trusts
pre-Active Directory domains such as NT 4 domains, Kerberos realm for
trusts with Unix/Linux realms.
UplevelOnly Set to True if only Windows 2000 and later operating systems can
use the trust link.
UsesAESKeys Set to True for realm trusts that use AES encryption keys.
UsesRC4Encryption Set to True for realm trusts that use RC4 encryption keys.

From a scalability perspective, there are a couple of things about trusts that you
should be aware of:
Maximum number of trusts for Kerberos authentication.

If a client in a trusted
domain attempts to access a resource in a trusting domain, the client can’t
authenticate if the truth path has more than 10 trust links. In environments with a
large number of trusts and long trust paths, you should implement shortcut trusts
to improve performance and ensure Kerberos authentication functionality.
Performance deteriorates after 2,400 trusts.

In really large and complex environments, you may have an enormous number of
trusts. After you reach 2,400 trusts,
any additional trusts added to your environment could significantly impact
performance over the trusts, especially related to authentication.

Page | 50
Group Policy
Group Policy provides a method of centralizing configuration settings and
management of operating systems, computer settings, and user settings in an
environment. While these settings are managed by using Group Policy Objects
(GPOs), GPOs cannot be applied directly to user or computer objects. A GPO must
be applied to a domain, site, or organizational unit.

By default, all objects within the container that the GPO has been
applied to will receive the GPO settings. Child objects and containers will also
receive the configured settings through inheritance, unless inheritance blocking is
configured.

Blocking inheritance complicates configurations and can cause unexpected

results. Additionally, GPOs may be set to be enforced which ensures that GPOs
will always be applied, regardless of inheritance settings. The enforced setting
should also be used with caution.

• How to Search Group Policy for a Specific Setting in Windows 10 and

Windows 11: https://techdirectarchive.com/2022/09/30/how-to-search-
group-policy-for-a-specific-setting-in-windows-10-and-windows-11/

Group Policy processes policy settings in the following order:

1. Local Group Policy

2. Site-linked policies
3. Domain-linked policies
4. OU-linked policies

Any policy that is configured by two or more GPOs will be overwritten or modified
by the last GPO that is processed. For example, if a site policy is applied that
modifies system settings, and an OU policy modifies the same system settings,
then the OU policy will take precedent because it is processed last. Additionally, if
a policy is enforced, the settings that are defined by that specific policy cannot be
overwritten by a subsequent GPO, even if the other GPO is processed last.
GPOs that modify computer settings are applied at computer startup. Settings
that are for users are applied at the time that the user logs on. By default, GPOs

Page | 51
are processed synchronously. Synchronous processing ensures that all settings
are applied before the user completes the log on process. Alternatively,
asynchronous processing can
be configured, to allow multiple operations to be performed. However,
asynchronous processing can cause undesired effects. For example, if a policy is
configured to remove Start Menu options for a user, the user could log on (and
have access to the start menu) before the policy is applied. By default, GPOs are
also reapplied every 90 minutes, with a randomized offset of up to 30 minutes.
For domain controllers, the policies are refreshed every 5 minutes.

Both of these refresh settings can be configured by using Group Policy.

If you do not wish to wait for a policy to refresh automatically, the gpupdate.exe
command can be used locally, or with switches, remotely. The gpupdate.exe
command processes the policies and applies only the settings that have been
changed since the last refresh. Additionally, other command switches can be used
to force applying all settings, specifying only user or computer settings, logging
off, or restarting a computer after applying the settings.

To troubleshoot or view the applied policies, the gpresult.exe command can be

used. The gpresult.exe command also has switches, allowing you to view the final
applied policy in HTML format. The gpresult.exe command can also be ran
remotely against target computers by name or by IP address. You can also specify
specific user accounts to see the settings that would be applied if that user were
to log on.

Page | 52
Page | 53
Inside the AD DS Database

The Active Directory database is made up of a single file named ntds.dit. By

default, it is stored in the %SYSTEMROOT%\NTDS folder. The folder also contains
the following related files:

Edb.log. There are typically multiple log files starting with “edb” such as
edb0013A.

log and edb0013B.log. Additionally, there is the edb.log file which is the active log
file. These logs are the transaction logs used to record changes made in AD DS. All
changes are first written to a transaction log and eventually make their way into
the
database a short time later.

Page | 54
Temp.edb. As the name implies, this file is a temporary file used to track
transactions that are taking place. It is also used when you run a database
compaction job.

Res1.log and res2.log or edbres00001.jrs and edbres00002.jrs.

These log files are

each 10MB in space and used in a situation where you are critically low on disk
space on the system volume. In older versions of Windows Server, the res1.log
and res2.log files are used. Since Windows Server 2008, the “edbres” naming is
used, along with a new file extension of .jrs.

Page | 55
The Active Directory database is based on Microsoft’s Joint Engine Technology
(JET) which is a database engine that was developed in 1992. Microsoft Access is
also based on the JET technology. Over the years, there have been rumors that
Active Directory’s database would be moved over to SQL Server (similar to rumors
for Microsoft Exchange) but so far, that doesn’t seem likely. I’ve heard third-hand
that SQL was tested as the AD DS database engine but that performance issues
prevented it from becoming the database standard. Because AD DS is a single use
database, it can effectively run on JET technology (whereas JET technology may
not be a good fit for the majority of transactional database needs which often
have multiple uses).

Microsoft chose to use the Indexed Sequential Access Method (ISAM) model for
indexing data in the AD DS database. To work with the data, including transferring
data in and out of the database, the Extensible Storage Engine (ESE) is used. ESE
helps to maintain a consistent, and therefore optimal, database, especially in the
event of a system crash. ESE is sometimes called JET Blue and is used by other
technologies besides Active Directory including Microsoft Exchange, Windows
Server’s BranchCache, and Microsoft’s Desktop Search.

The database technologies for Active Directory have been around a long time.
Each technology, by itself, could account for several pages of text to dive into how
they work.

Page | 56
Edb.chk. This file is a checkpoint file. Checkpoint files are commonly used in a
transactional database system to keep track of which log file entries have been
committed to the database. This is useful during a system crash to avoid data loss.

Extensible Storage Engine Architecture at

https://technet.microsoft.com/en- us/library/aa998171(v=exchg.65).aspx

How the Active Directory data store really works (inside NTDS.dit) – a blog
by Christoffer Andersson at https://technet.microsoft.com/en-
us/library/aa998171(v=exchg.65).aspx

Page | 57
Replication
Active Directory replication is the method of transferring and updating Active
Directory objects from one DC to another DC. The connections between DCs are
built based on their locations within a forest and site. Each site in Active Directory
contains one or more subnets, which identify the range of IP addresses associated
with the site. By mapping the IP address of a DC to a subnet, Active Directory
knows which DCs are in which site. Connections are configured between sites to
ensure that Active Directory objects are replicated between sites.

Active Directory replication relies on the following technologies to operate

successfully:

DNS
Remote procedure call (RPC)
SMTP (optional)
Kerberos
LDAP

Multimaster replication. Multimaster replication, compared to single-master

replication as used in Windows NT 4.0, ensures that each domain controller can
receive updates for objects for which it is authoritative. This provides fault

Page | 58
tolerance within an Active Directory environment.

Pull replication. Pull replication ensures that DCs request object changes instead
of changes being pushed (especially unnecessarily). Pulling slightly reduces
replication traffic between DCs.

Store-and-forward replication. Store-and-forward replication ensures that every

DC communicates with a subset of DCs to transfer the object changes that have
occurred. With store- and-forward, every DC would communicate with every
other DC, which is inefficient. Store-and- forward replication balances the
replication load among the DCs within an Active Directory environment.

There are four main components of replication in Active Directory:

• State-based replication. State-based replication ensures that each DC tracks

the
state of replication updates which eliminates conflicts and unnecessary
replication.

Replication is managed by the Knowledge Consistency Checker (KCC). The KCC

manages replication between DCs in a single site by using automatically created
connections. The KCC reads configuration data and reads and writes connection
objects for DCs. The KCC only uses RPC to communicate with the directory
service.

Intrasite replication does not use compression and changes are sent to DCs
immediately. However, intersite replication relies on user-defined links that must
be created. The KCC uses these links to create a topology so that replication is
managed across the site-to-site links. Site connections can be controlled on a
schedule and the replication data is compressed to minimize bandwidth usage.
The default replication schedule for site-to-site connections is 180 minutes which
is usually way too long for the vast majority of organization. This can be

Page | 59
configured to as low as 15 minutes in the GUI, and even faster by modifying the
registry. A replication packet size is calculated based on the amount of RAM in the
DC. By default, the packet size limits are 1/100th the size of RAM, with a
minimum of 1 MB and a maximum of 10 MB. Additionally, the maximum
number of objects in a packet is 1/1,000,000th the size of the system RAM, with a
minimum of 100 objects, and a maximum of 1,000 objects. Therefore, in modern
servers that have more than 1 GB or RAM, replication packet sizes will either
contain up to 10 MB of data or up to 1,000 objects. .The maximum packet size
and object limit can be configured by modifying the registry in the following
location:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters

The following are components the primary replication components:

Knowledge Consistency Checker (KCC).

The KCC is a process that runs on each DC
and communicates directly with Ntdsa.dll to read and write replication objects.

Page | 60
Directory System Agent (DSA).
The DSA is a directory service component that runs
as Ntdsa.dll on each DC. It provides an interface for services and processes to read
the directory database.

Extensible Storage Engine (ESE).

The ESE manages directory database records,
which may contain one or more columns.

Page | 61
Remote Procedure Call (RPC).
Directory replication is communicated by using the RPC protocol.
RPC is a communication protocol that allows developers to execute
code on a local or remote system without having to develop specific code for
remote execution. The KCC also uses RPC to communicate with DCs to request
information when building a replication topology.

Intersite Topology Generator (ISTG).

The ISTG manages the intersite inbound replication connection objects for a
specific site. There is one ISTG server in each site.

By default, the first DC in each site is the ISTG. To find the ISTG in a site named HQ
in a domain named tailspintoys.com, you can run the Windows PowerShell
command:
Get- ADObject –Identity "cn=NTDS Site Settings,
cn=HQ,cn=sites,cn=configuration,dc=tailspintoys,dc=com" -Properties
interSiteTopologyGenerator | Select interSiteTopologyGenerator

The Active Directory objects that are used by the KCC and its components include:
The diagram below shows a typical two-site Active Directory environment with
some of the replication components.

A typical two-site Active Directory environment Beginning with Windows

PowerShell in Windows Server 2012, there are 25 cmdlets to
specifically manage Active Directory replication. These cmdlets offer functionality
such as viewing replication information, configuring sites, managing site links, and
forcing replication to occur.

Page | 62
Page | 63
The RepAdmin.exe command line tool is also available to provide information
and configure Active Directory replication.

Page | 64
Another replication tool is the
Active Directory Replication Status Tool. It is available at
http://www.microsoft.com/en-us/download/details.aspx?id=30005 . You can use
it to analyze and troubleshoot

Active Directory replication issues.

Sites.
Sites are Active Directory objects in the site class, which correspond to the
subnets in a given site.

Subnets.
Subnet objects are in the subnet class, and define the network IP subnet
that is corresponded with a site.

Servers.
A server object, in the server class, represents server computers, including

DCs.
Server objects are treated as security principals which are stored in a separate
directory partition and have separate globally unique identifiers (GUIDs).

NTDS Settings.
NTDS Setting objects are in the nTDSDSA class, and represent an instance of
Active Directory on a specific DC.

Page | 65
Connections.
Connection objects are in the nTDSConnection class, and define a
one-way, inbound route from a source DC to the DC that is storing the connection
object.

Site Links.
Site Link objects are in the siteLink class, and identify the protocol and
schedule to replicate data between two or more sites.

NTDS Site Settings.

NTDS Site Setting objects are in the nTDSSiteSettings class, and
identify site-wide settings for Active Directory. There is only one NTDS Site
Settings object per site in the Sites container.

Cross-reference.
Cross-reference objects are in the crossRef class, and store the location of Active
Directory partitions in the Partitions container.

Page | 66
DNS and DHCP

AD DS provides a built-in method of storing and replicating DNS records by using

Active Directory-integrated DNS zones. All of the records and zone data stored
within the zone are replicated to other DNS servers by using the native AD DS
replication service. Each DC stores a writable copy of the DNS zone data for
namespaces for which they are authoritative. Active Directory-integrated zones
also provide the ability to use secure dynamic updates, which supports controlling
which computers may make updates and prevents unauthorized changes from
being made.

DNS zone data is stored in an application directory partition. A forest-wide

partition named ForestDnsZones is used for the zone data. For each AD DS
domain, a domain partition is created named DomainDnsZones.

Page | 67
Typically, DNS implementations are used with a contiguous namespace. For
example, the Fully Qualified Domain Name (FQDN) of an AD DS domain might be
corp.contoso.com, and the FQDN of a client in that domain would be
lient.corp.contoso.com.
However, AD DS and Active Directory-integrated DNS zones support disjoint
namespaces. In such a scenario, the FQDN of the AD DS domain might be
na.corp.contoso.com, while a client FQDN could be client.corp.contoso.com.
Notice that the “na” portion of the FQDN is not present in the client FQDN. There
are several requirements and considerations when using a disjoint namespace.
For more information, see https://technet.microsoft.com/en-
us/library/cc731125%28v=ws.10%29.aspx

AD DS requires DNS to function, and uses three specific components for the AD
DS infrastructure:

Domain controller locator.

The Locator is implemented in the Net Logon service and provides the names of
DCs in an AD DS environment. The Locator uses address (A) and service (SRV) DNS
resource records to identify DCs in an AD DS environment.

Active Directory domain names in DNS.

The AD DS domain names in DNS are the FQDN that we discussed earlier.

Active Directory DNS objects.

While DNS domains and AD DS domains typically have the same name, they are
two separate objects with different roles. DNS stores zones and zone data
required by AD DS and responds to DNS queries from clients.

AD DS stores object names and object records and uses LDAP queries to retrieve
or modify data. DNS zones that are stored in AD DS have a container object that is

Page | 68
in the dnsZone class. The dnsZone object has a DNS node, which uses the
dnsNode class. Each unique name in a DNS zone has a unique dnsNode object. For
AD DS, this also includes individual functions.

Therefore, one DC may have multiple roles, such as being a global catalog server,
which is indicated in the dnsNode object.

As mentioned earlier, DCs are identified by the SRV records in a DNS zone.
Components of AD DS are stored in DNS using the following format in the _msdcs
subdomain: _Service.Protocol.DcType._msdsc.DnsDomainName. For example, the
Lightweight Directory Access Protocol (LDAP) service of the Primary Domain
Controller (PDC) in the contoso.com AD DS domain would be
ldap._tcp.pdc.contoso.com.
The service and protocol strings use underscores (_) as a prefix to avoid potential
collisions with existing resources or records in the namespace. The Net Logon
service requires 17 different SRV records to perform lookups. A full list of SRV
records can be found at
https://technet.microsoft.com/en-us/library/cc759550%28v=ws.10%29.aspx

In addition to the SRV records, the Net Logon service also requires two A records
for clients that may not be SRV- aware. This includes a record for the
DnsDomainName, and a record for gc._msdsc.DnsForestName. This enables non-
SRV-aware clients to look up a domain controller or global catalog server by using
an A record.

DNS is susceptible to security threats, such as foot printing, denial-of-service

attacks, data modification, and redirection. To mitigate these threats, DNS zones
can be secured by using secure dynamic updates, restricting zone transfers, plus
implementing zone delegation and DNS Security Extensions (DNSSEC). By using
secure dynamic updates, computers will be authenticated through Active
Directory, and security settings will be applied when performing a zone transfer.

Page | 69
Additionally, zone transfers can also be restricted to specific IP addresses within
the network. Zone delegation can be approached by using two methods. First, is
to limit DNS changes to a single team or entity, with all changes tracked and
approved. This method limits the amount of people making changes, but allows
for a single point of failure.

Secondly, zones can be delegated to individuals who will be managing each

component of a network or domain. While changes may still need to be approved
and tracked, this spreads out risk among multiple people, and may limit damage if
only one component becomes compromised. DNSSEC validates DNS responses by
providing origin authority, data integrity, and authenticated denial of existence.
Windows Server 2012’s implementation of DNSSEC meets the standards for RFC
4033, 4034, and 4035.

There are six resource record types that are used specifically with DNSSEC:
Resource record signature (RRSIG)
Next Secure (NSEC)
Next Secure 3 (NSEC3)
Next Secure 3 Parameter (NSEC3PARAM)
DNS Key (DNSKEY)
Delegation Signer (DS)

For more information on each of the record types and their use, see
https://technet.microsoft.com/en- us/library/jj200221.aspx

Page | 70
DHCP is another network service that is used by Windows Server. In an AD DS
environment, DHCP servers must be authorized before they can lease IP
addresses to clients on a network. DHCP servers are authorized by their IP
addresses, and will be checked against AD DS to verify that it is authorized to
lease IP addresses.
If an unauthorized DHCP server detects an authorized DHCP server, the
unauthorized DHCP server will stop leasing addresses to clients. In an AD DS
environment, the DHCP service must be installed on a server that is a member of
the domain, or it cannot be authorized. Installing and running the DHCP service
on a stand-alone server is supported, but must be on a separate network or VLAN
than any authorized DHCP server.
To authorize a DHCP
server, the administrator must be a member of the Enterprise Admins built-in
security group. However, the right to authorize DHCP server may be delegated to
other administrators within the domain. To authorize a DHCP by using it’s FQDN,
the FQDN must not exceed 64 characters. If the FQDN is more than 64 characters,
it must be authorized by using an IP address.

DHCP can be integrated with DNS to provide dynamic updates to pointer (PTR)
and A records in a DNS zone. This ability enables a DHCP server to be a proxy for
any DHCP client running an operating system that does not automatically update
their DNS registration.

In Windows Server 2012, DHCP can be configured with DHCP failover. DHCP
failover enables the DHCP server to be configured in hot standby mode, which
provides redundancy, or load balance mode, which allocates client leases across
two DHCP servers.

Page | 71
The mode can be changed at any time, but a DHCP scope only supports using one
mode at a time. IPv4 addresses that have been leased or reserved, including the
options and settings for each scope, are shared by two DHCP servers. A single
DHCP server supports up to 31 failover relationships. Failover relationships can be
reused for additional scopes to avoid exceeding the limit.

When using DHCP hot standby mode, two servers operate the DHCP service,
however
one server provides and responds to all DHCP requests. The secondary server will
only
provide leases if the primary server is unreachable. To provide leases, a
percentage of
the IP address pool must be reserved for use by the secondary server. By default,
this
is set to 5%. If the secondary server leases all of the IP addresses in the reserved
space,
it will not issue additional IP addresses from the primary server’s scope. Existing
leases
will be renewed if requested by a DHCP client. Additionally, when the secondary
server
leases an IP address, the lease time is the maximum client lead time (MCLT)
duration,
not the full scope lease time. After the MCLT time has expired, the secondary
server will
use the entire address pool in the scope, assuming that the primary server has
resumed.
Using DHCP in load balancing mode is the default method of deployment. In this
method, two servers provide the DHCP services simultaneously for a DHCP scope.
The load balancing method is defined by a percentage of IP addresses on each
server,
and by default is split 50:50. This ratio or percentage can be configured to any
amount
between the two servers. The DHCP servers load balance based on a hash of the

Page | 72
requesting client’s MAC address. The MAC address thus determines which DHCP
server
will respond to a client’s DHCP request. Similar to hot standby mode, if the
partner
server is unavailable, the remaining server will lease and renew IP addresses for
the
MCLT duration. After the MCLT time has expired, if the partner server is not
online, the
remaining server will lease addresses from the entire IP address pool for the
scope.

Security
Security is a huge topic because it encompasses so many areas. Even in a specific
technology like AD DS, security is a huge topic. For this e-book, we will focus on 3
specific areas of security in AD DS:
Securing LDAP traffic with SSL/TLS
Modifying the access control list (ACL) on administrative accounts
Enabling strong authentication in a domain
The first step to securing LDAP traffic with SSL/TLS is to install AD CS. It is a good
practice is to install the role on a member server. Before you begin implementing
a PKI,
you should spend ample time gathering information, designing the PKI, and
planning.
Once you have an operational PKI, you can issue a certificate to each DC.
It is also possible to use a third-party Certification Authority (CA) to secure LDAP
communication. The certificate must not have strong private key protection
enabled.
Additionally, the DC FQDN must appear in either the Common Name of the
Subject
field, or as a DNS entry in the Subject Alternative Name extension. They Enhanced
Key
Usage must also include Server Authentication as an option, object identifier

Page | 73
(OID)
1.3.6.1.5.5.7.3.1 By enabling LDAP over SSL, LDAP communication can occur on
both
ports 389 (LDAP) and 636 (LDAP/SSL). Global catalog requests performed with SSL
used port 3269.
The certreq.exe command can be used to create a new certificate request. To
create a
request, run the following command:
certreq -new request.inf request.req
The request.inf file must contain the DC FQDN, and also provides information on
the key length and request time. For a full example of the request.inf file, see
http://
support.microsoft.com/kb/321051. The request.req file will be created, and must
be submitted to the CA. After receiving the certificate, process the request with
the
certreq.exe command.
certreq -accept certnew.cer
To verify that SSL has been enabled successful, the Active Directory
Administration
Tool (ldp.exe) can be used to manually connect to the AD DS environment. Launch
the ldp.exe tool, and perform a new connection. In the port field, specify 636. If
the
RootDSE information is displayed, LDAP over SSL has been configured
successfully.
Chapter IX | Security 27
Another way to secure AD DS is to modify the ACL of user accounts that have
administrative privileges. User accounts in administrative groups have their ACLs
replaced
every hour by a process on the PDC Emulator. This process compares the ACLs on
each
account in the administrative groups and the group itself to the AdminSDHolder
object.
In a domain named contoso.com, the object is located at
CN=AdminSDHolder,CN=System,
DC=Contoso,DC=Com. Any difference between the account and the

Page | 74
AdminSDHolder
object is then replaced on the account. The following groups and members of
these
groups are checked by the AdminSDHolder process:
Administrators
Account Operators
Cert Publishers
Backup Operators
Domain Admins
Enterprise Admins
Print Operators
Schema Admins
Server Operators
Additionally, the Administrator and krbtgt user accounts are also checked
independently
regardless of group membership. Accounts that are protected by the
AdminSDHolder
process can be identified by the adminCount attribute of the account. If the
account is
being protected, this attribute will be set to 1.
To modify the ACL of an account being protected by the AdminSDHolder process,
three
steps must be taken to verify that the ACL is not replaced.
1. Remove the account object from all protected groups.
2. Set the adminCount attribute to 0.
3. Enable inheritance on the account object.
Note that simply changing the adminCount to 0 without removing the object from
the
protected groups will not stop the process from replacing the ACLs. Removing the
object from the groups without modifying the adminCount attribute doesn’t fix
the
situation.
Another solution is to modify the AdminSDHolder object to include the ACLs that
you
want to apply to the user accounts. By including the additional access control

Page | 75
entries
in the AdminSDHolder object, they will also be included when the ACLs of each
account
object is compared. This is useful for modifying the permissions of all
administrative
user account objects.
Another area of AD DS security is to enable strong domain authentication in your
environment. This will ensure that users can authenticate to Active Directory by
using only strong authentication protocols. By default, Windows Server 2012
accepts
authentication requests that use NTLM and NTLMv2, although it responds by
replying
with NTLMv2 only. This setting can be restricted by modifying the “Network
Security:
LAM Manager Authentication Level” setting in group policy. This setting is applied
to DCs,
and can be set to “Send NTLMv2 response only. Refuse LM and NTLM.” By
configuring this
setting, DCs will not respond unless they receive an NTLMv2 request.
Chapter X | Auditing 28
X. Auditing
Prior to Windows Server 2008 R2 and Windows 7, auditing in Windows was a
fairly
simple topic. You navigated to the auditing policies in a GPO and enabled auditing
and chose Success, Failure, or both. There were a number of articles on the
internet
describing each of the auditing policies and many administrators quickly avoided
anything that didn’t provide much value. Below is a screen capture showing the
available audit policy settings.
Figure 10.1
Audit policy settings
In Windows Server 2008 R2, a new feature was introduced to allow for advanced
auditing policies in Group Policy. Officially, 53 new settings were made available
to
replace the original 9 policy settings shown above. A little known fact is that these

Page | 76
53
new settings were actually available in Windows Server 2008. However, you had
to
use logon scripts and auditpol.exe to take advantage of the new settings. Thus,
most
administrators didn’t.
One common area of confusion is the apparent overlap of the original 9 policy
settings (hereafter called the basic audit policy settings) and the advanced audit
policy
settings. There actually isn’t any overlap though. Let’s examine why by looking at
the account management auditing. With basic audit policy settings, you can
enable
the “Audit account management” policy for Success and Failure. With advanced
audit
policy, you can enable auditing for application group management, computer
account
management, distribution group management, account management events,
security
group management, and user account management. Enabling the “Audit account
management” basic audit policy setting is the same as enabling auditing in the 6
subcategories available in an advanced audit policy. Neither provide more data.
But,
as many administrators have realized, generating too much audit data can be
worse
than not generating any audit data because of the massive volume of audit data
that
can be generated. Administrators have been struggling with audit data for a long
time.
Some of the common struggles are:
Chapter X | Auditing 29
Windows event logs fill up. Windows event logs can be configured in a number of
different ways. You can set a maximum log size and delete old event as needed.
You can archive a log when it fills up and then start a new log. Or, you can
configure the logs not to overwrite events and require manual intervention. You
can

Page | 77
even shut the server down if you can’t write to the Security event log.
Administrators often can’t afford for new events not to be written or for servers
to shut down
when a log fills up. Thus, overwriting events or archiving are the most common
settings. But this leads to administrative overhead: monitor event log sizes,
monitor disk space, move archived logs off of server, manage archived logs, and
figuring
out a way to search through all of the data.
Disk volumes run out of space. I still find it amusing that in 2015, disk space is still
the major source of server downtime in many companies. Log files are a common
problem whether from auditing or from applications such as IIS. I have heard from
several organizations that experienced an outage and the root cause was the
system volume running out of space due to Windows event log archiving.
Inability to locate specific audit data. When you generate a massive amount of
data, every data management task, even normally simple tasks, become complex
and time consuming. Tasks such as compressing the files, copying the files to
another location over the network, or searching through the files for a specific
key term become problematic and incredibly time consuming. Administrators are
turning toward third-party solutions to help.
Inability to use audit data in a timely fashion. Imagine a call from the security
team
about an employee that has potentially viewed confidential HR data. They ask you
to pull up audit data for the user over the last few weeks. Not a big deal if you
have
1GB worth of audit data. But when you have 500GB worth of audit data, it
suddenly becomes your full time job for a few weeks.
The advanced audit policy settings can help. By offering more granular auditing
options, you can greatly reduce the amount of data gathered. This minimizes the
struggles mentioned above. But, there is a big investment in time to switch over
to the
advanced audit policy settings. For some organizations, that investment will pay
for
itself and more.
Let’s take a quick look at how this impacts the number of events captured. In this
first

Page | 78
example, in a Windows Server 2003 R2 domain named adatum.com, I set basic
audit
settings so that only account management success events are being audited, as
shown
below. There isn’t any significance to the operating system version because the
basic
audit settings shown below are available in every version of Windows Server since
Windows 2000 Server.
Figure 10.2
Basic audit settings
Chapter X | Auditing 30
Then, I created a new computer object and refreshed the Security event log.
Below are
the entries related to the new computer object creation.
Figure 10.3
Entries related to the new
computer object creation
There are 5 events. Next, in a Windows Server 2012 R2 domain named
contoso.com,
I created an advanced audit policy based on wanting to audit only successful user
account management events, as shown below.
Figure 10.4
An advanced audit policy
Then, I created a new computer object and refreshed the Security event log.
Below are
the entries related to the new computer object creation.
Figure 10.5
Entries related to the new
computer object creation
With the advanced auditing policy, only 2 events were logged. That’s a big
difference,
especially when you think about how that would extrapolate once all auditing
categories were configured. Note that not only would we save some time with the
granular
approach, but we will also save quite a bit more time later after the other auditing

Page | 79
categories are configured. Now, you may be wondering why creating a computer
account is showing up in user account auditing? That’s because computer objects
are
part of the AD DS user class along with user objects! You may also be wondering
why
the event log IDs are different for each environment. This is unrelated to the
auditing
configuration and instead is because of a change in the event log IDs used in
Windows
Server 2008 and newer. Many of the event IDs changed between versions of
Windows
Server.
Chapter XI | User Unfriendly Log Data 31
XI. User Unfriendly Log Data
As a side effect of auditing and logging, administrators have to deal with a ton of
data
and information. Often, not only is there an overload of information, but often
the
information isn’t readily usable. Here are some of the pain points that
administrators
are dealing with when it comes to audit and log data:
The information is unformatted. In this situation, information is captured but it is
unformatted. In other words, everything looks the same and it can be a struggle
to
extract the key pieces of information that you need. In these situations,
administrators struggle to work with the data – filtering, sorting, manipulating,
and extracting are difficult without hours of administrative effort.
The informatio is verbose. In this situation, there is too much information. For
example, take an example of a user signing in to their computer in the morning.
Instead of a single event log entry, you end up with several entries, each covering
a part of the overall sign in process. Another example is a packet capture. You
may be troubleshooting an authentication issue on a DC, but your packet capture
contains tons of other irrelevant data. In some cases, administrators can turn to
tools to create filters to minimize data capture. But that isn’t nearly as effective
for

Page | 80
capturing Windows security related data on an ongoing basis.
The information is uncorrelated. For example, imagine a scenario where you are
troubleshooting authentication from a federated partner. You have information
in the Windows event logs on the DC, Windows event logs on the AD FS servers,
Windows event logs on the target web server, Windows event logs on the client
computer, AD FS proxy logs, AD FS specific logs, and IIS logs. What’s worse is that
there isn’t any correlation to the logs beyond a date and time stamp. The built-in
tools in Windows don’t provide a good event correlation solution for this problem
so administrators are often using third-party tools to help.
The information is ignored. After extended periods of time dealing with
unformatted, verbose, and uncorrelated information, administrators often start
ignoring
logs, ignoring alerts, and ignoring important information that may be buried “in
there somewhere”. This same phenomenon is often seen in monitoring projects
when so many alerts are being generated that they go unanswered.
Part of the solution to this problem is to reduce the amount of information you
capture. But that sometimes goes against what a security team wants a company
to
capture – everything. So there is a balancing act. You need to capture enough
information to make it useful but without making it a burden. Administrators
often turn
to third- party tools to help come up with the right solution.
About Netwrix

Netwrix is a software company that enables information security and governance

professionals to reclaim
control over sensitive, regulated and business-critical data, regardless of where it
resides. Over 10,000
organizations worldwide rely on Netwrix solutions to secure sensitive data, realize
the full business value
of enterprise content, pass compliance audits with less effort and expense, and
increase the productivity
of IT teams and knowledge workers.
Founded in 2006, Netwrix has earned more than 150 industry awards and been
named to both the Inc.

Page | 81
5000 and Deloitte Technology Fast 500 lists of the fastest growing companies in
the U.S.
For more information, visit www.netwrix.com.
PHONES: OTHER LOCATIONS: SOCIAL:
+33 9 75 18 11 19
1-949-407-5125 +34 911 982608
Toll-free (USA): 888-638-9749
1-

Page | 82
Active Directory Technical Specification

1 Introduction
This is the primary specification for Active Directory, both Active Directory
Domain Services (AD DS) and Active Directory Lightweight Directory Services
(AD LDS). When the specification does not refer specifically to AD DS or AD LDS, it
applies to both. The state model for this specification is prerequisite to the other
specifications for Active Directory: [MS-DRSR] and [MS-SRPL].
When no operating system version information is specified, information in this
document applies to all relevant versions of Windows. Similarly, when no DC
functional level is specified, information in this document applies to all DC
functional levels.
The information in this specification is applicable to the following Microsoft
products or supplemental software. References to product versions include
released service packs.
Note: The terms "earlier" and "later", when used with a product version, refer to
either all preceding versions or all subsequent versions, respectively. The term
"through" refers to the inclusive range of versions. Applicable Microsoft products
are listed chronologically in this section.
▪ Windows 2000 Server operating system
▪ Windows Server 2003 operating system
▪ Windows Server 2003 R2 operating system
▪ Windows Server 2008 operating system
▪ Windows Server 2008 R2 operating system
▪ Windows Server 2012 operating system
▪ Windows Server 2012 R2 operating system
▪ Windows Server 2016 operating system

Page | 83
▪ Windows Server v1709 operating system
▪ Windows Server v1803 operating system
▪ Windows Server v1809 operating system
▪ Windows Server 2019 operating system
▪ Windows Server v1903 operating system
▪ Windows Server 2022 operating system

AD DS:
First became available as part of Microsoft Windows 2000 operating
system and is available as part of Windows 2000 Server, Windows
Server 2003, and Windows Server 2003 R2 products; in these products
it is called "Active Directory".
It is also available as part of Windows Server 2008 and later. AD DS is
not present in Windows NT 3.1 operating system, Windows NT 3.51
operating system, Windows NT 4.0 operating system, or Windows XP
operating system.

AD LDS: first became available during the release of Windows

Server 2003.
In Windows XP, Windows Server 2003, and Windows Server 2003 R2, it is a
standalone application called "Active Directory Application Mode (ADAM)". AD
LDS is also available as part of Windows Server 2008 and later. Unless otherwise
specified, information in this specification is also applicable to AD LDS. There are
two versions of ADAM, ADAM RTW (introduced in the same timeframe as
Windows Server 2003 operating system with Service Pack 1 (SP1)) and ADAM SP1

Page | 84
(introduced in the same timeframe as Windows Server 2003 operating system
with Service Pack 2 (SP2)); unless otherwise specified, where ADAM is discussed
in this document it refers to both versions of ADAM.
AD LDS for a particular Windows client is a standalone application that provides
AD LDS capabilities for that Windows client. Information that is applicable to AD
LDS on applicable Windows Server releases is generally also applicable to AD LDS
on Windows clients, including Windows 11 operating system and later, except
where it is explicitly specified that such information is not applicable to that
product.
Information that is applicable to AD LDS on Windows Server v1903 is also
applicable to AD LDS for Windows 10 v1903 operating system.
▪ Information that is applicable to AD LDS on Windows Server 2022 is also
applicable to AD LDS for Windows 10 v21H1 operating system.
State is included in the state model for this specification only as necessitated by
the requirement that a licensee implementation of the protocols of applicable
Windows Server releases has to be capable of receiving messages and responding
in the same manner as applicable Windows Server releases. Behavior is specified
in terms of request message received, processing based on current state,
resulting state transformation, and response message sent. Unless otherwise
specified in the sections that follow, all of the behaviors are required for
interoperability.
The following typographical convention is used to indicate the special meaning of
certain names:
▪ Underline, as in instanceType: the name of an attribute or object class whose
interpretation is specified in the following documents:
▪ [MS-ADA1] Attribute names for AD DS whose initial letter is A through L.
▪ [MS-ADA2] Attribute names for AD DS whose initial letter is M.
▪ [MS-ADA3] Attribute names for AD DS whose initial letter is N through Z.
▪ [MS-ADSC] Object class names for AD DS.
▪ [MS-ADLS] Object class names and attribute names for AD LDS.

Page | 85
For clarity, bit flags are sometimes shown as bit field diagrams. In the case of bit
flags for Lightweight Directory Access Protocol (LDAP) attributes, these diagrams
take on big-endian characteristics but do not reflect the actual byte ordering of
integers over the wire, because LDAP transfers an integer as the UTF-8 string of
the decimal representation of that integer, as specified in [RFC2252].
2 References
Links to a document in the Microsoft Open Specifications library point to the
correct section in the most recently published version of the referenced
document. However, because individual documents in the library are not updated
at the same time, the section numbers in the documents may not match. You can
confirm the correct section numbering by checking the Errata.

3 Normative References
We conduct frequent surveys of the normative references to assure their
continued availability. If you have any issue with finding a normative reference,
please contact [email protected]. We will assist you in finding the relevant
information.
[C706] The Open Group, "DCE 1.1: Remote Procedure Call", C706, August 1997,
https://publications.opengroup.org/c706

Note Registration is required to download the document.

[GRAY] Gray, J., and Reuter, A., "Transaction Processing: Concepts and
Techniques", The Morgan Kaufmann Series in Data Management Systems, San
Francisco: Morgan Kaufmann Publishers, 1992, Hardcover ISBN: 9781558601901.

[IEEE1003.1] The Open Group, "IEEE Std 1003.1, 2004 Edition", 2004,
http://www.unix.org/version3/ieee_std.html

[ISO-8601] International Organization for Standardization, "Data Elements and

Interchange Formats - Information Interchange - Representation of Dates and
Times", ISO/IEC 8601:2004, December 2004,
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=40
874&ICS1=1&ICS2=140&ICS3=30

Note There is a charge to download the specification.

Page | 86
[ISO/IEC-14977] International Organization for Standardization, "Information
technology -- Syntactic metalanguage -- Extended BNF", ISO/IEC 14977:1996,
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnum
ber=26153

[ISO/IEC-9899] International Organization for Standardization, "Programming

Languages - C", ISO/IEC 9899:TC2, May 2005, http://www.open-
std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

[ITUX680] ITU-T, "Abstract Syntax Notation One (ASN.1): Specification of Basic

Notation", Recommendation X.680, July 2002, http://www.itu.int/ITU-
T/studygroups/com17/languages/X.680-0207.pdf

[ITUX690] ITU-T, "ASN.1 Encoding Rules: Specification of Basic Encoding Rules

(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)",
Recommendation X.690, July 2002, http://www.itu.int/ITU-
T/studygroups/com17/languages/X.690-0207.pdf

[KNUTH1] Knuth, D., "The Art of Computer Programming: Volume 1/Fundamental

Algorithms (Second Edition)", Reading, MA: Addison-Wesley, 1973, ASIN:
B000NV8YOA.

[MS-ADA1] Microsoft Corporation, "Active Directory Schema Attributes A-L".

[MS-ADA2] Microsoft Corporation, "Active Directory Schema Attributes M".

[MS-ADA3] Microsoft Corporation, "Active Directory Schema Attributes N-Z".

[MS-ADLS] Microsoft Corporation, "Active Directory Lightweight Directory

Services Schema".

[MS-ADSC] Microsoft Corporation, "Active Directory Schema Classes".

[MS-APDS] Microsoft Corporation, "Authentication Protocol Domain Support".

[MS-CTA] Microsoft Corporation, "Claims Transformation Algorithm".

[MS-DRSR] Microsoft Corporation, "Directory Replication Service (DRS) Remote

Protocol".

[MS-DTYP] Microsoft Corporation, "Windows Data Types".

Page | 87
[MS-ERREF] Microsoft Corporation, "Windows Error Codes".

[MS-FRS1] Microsoft Corporation, "File Replication Service Protocol".

[MS-GKDI] Microsoft Corporation, "Group Key Distribution Protocol".

[MS-GPSB] Microsoft Corporation, "Group Policy: Security Protocol Extension".

[MS-KILE] Microsoft Corporation, "Kerberos Protocol Extensions".

[MS-LSAD] Microsoft Corporation, "Local Security Authority (Domain Policy)

Remote Protocol".

[MS-MAIL] Microsoft Corporation, "Remote Mailslot Protocol".

[MS-NLMP] Microsoft Corporation, "NT LAN Manager (NTLM) Authentication

Protocol".

[MS-NRPC] Microsoft Corporation, "Netlogon Remote Protocol".

[MS-PAC] Microsoft Corporation, "Privilege Attribute Certificate Data Structure".

[MS-RPCE] Microsoft Corporation, "Remote Procedure Call Protocol Extensions".

[MS-SAMR] Microsoft Corporation, "Security Account Manager (SAM) Remote

Protocol (Client-to-Server)".

[MS-SFU] Microsoft Corporation, "Kerberos Protocol Extensions: Service for User

and Constrained Delegation Protocol".

[MS-SPNG] Microsoft Corporation, "Simple and Protected GSS-API Negotiation

Mechanism (SPNEGO) Extension".

[MS-SRPL] Microsoft Corporation, "Directory Replication Service (DRS) Protocol

Extensions for SMTP".

[MS-UCODEREF] Microsoft Corporation, "Windows Protocols Unicode Reference".

[MS-W32T] Microsoft Corporation, "W32Time Remote Protocol".

Page | 88
[MSKB-3106637] Microsoft Corporation, "Incorrect results in LDAP query, domain
controller restarts, or user logons are denied in Windows Server 2012 R2",
https://support.microsoft.com/en-us/kb/3106637

[MSKB-3155495] Microsoft Corporation, "You can't use the Active Directory

shadow principal groups feature for groups that are always filtered out in
Windows", revision 2.0, May 2016, https://support.microsoft.com/en-
us/kb/3155495

[MSKB-3192404] Microsoft Corporation, "October 2016 Preview of Monthly

Quality Rollup for Windows 8.1 and Windows Server 2012 R2",
https://support.microsoft.com/en-us/kb/3192404

[MSKB-4019217] Microsoft Corporation, "May 16, 2017 - KB4019217 (Preview of

Monthly Rollup)", https://support.microsoft.com/en-us/kb/4019217

[MSKB-4025334] Microsoft Corporation, "July 18, 2017—KB4025334 (OS Build

14393.1532)", https://support.microsoft.com/en-us/kb/4025334

[MSKB-4038801] Microsoft Corporation, "September 28, 2017—KB4038801 (OS

Build 14393.1737)", https://support.microsoft.com/help/4038801

[MSKB-4490425] Microsoft Corporation, "Updates to TGT delegation across

incoming trusts in Windows Server", https://support.microsoft.com/en-
us/help/4490425/updates-to-tgt-delegation-across-incoming-trusts-in-windows-
server

[MSKB-4505903] Microsoft Corporation, "July 26, 2019--KB4505903 (OS Build

18362.267)", July 2019, https://support.microsoft.com/en-
us/help/4505903/windows-10-update-kb4505903

[RFC1001] Network Working Group, "Protocol Standard for a NetBIOS Service on

a TCP/UDP Transport: Concepts and Methods", RFC 1001, March 1987,
http://www.ietf.org/rfc/rfc1001.txt

[RFC1002] Network Working Group, "Protocol Standard for a NetBIOS Service on

a TCP/UDP Transport: Detailed Specifications", STD 19, RFC 1002, March 1987,
http://www.rfc-editor.org/rfc/rfc1002.txt

Page | 89
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13,
RFC 1034, November 1987, http://www.ietf.org/rfc/rfc1034.txt

[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification",

STD 13, RFC 1035, November 1987, http://www.ietf.org/rfc/rfc1035.txt

[RFC1088] McLaughlin III, L., "A Standard for the Transmission of IP Datagrams
over NetBIOS Networks", RFC 1088, February 1989,
http://www.ietf.org/rfc/rfc1088.txt

[RFC1166] Kirkpatrick, S., Stahl, M., Recker, M., "Internet Numbers", RFC 1166,
July 1990, http://www.ietf.org/rfc/rfc1166.txt

[RFC1274] Barker, P. and Kille, S., "The COSINE and Internet X.500 Schema", RFC
1274, November 1991, http://www.ietf.org/rfc/rfc1274.txt

[RFC1278] Hardcastle-Kille, S. E., "A string encoding of Presentation Address", RFC

1278, November 1991, http://www.ietf.org/rfc/rfc1278.txt

[RFC1777] Yeong, W., Howes, T., and Kille, S., "Lightweight Directory Access
Protocol", RFC 1777, March 1995, http://www.ietf.org/rfc/rfc1777.txt

[RFC1798] Young, A., "Connection-less Lightweight X.500 Directory Access

Protocol", RFC 1798, June 1995, http://www.ietf.org/rfc/rfc1798.txt

[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June
1996, http://www.rfc-editor.org/rfc/rfc1964.txt

[RFC2078] Linn, J., "Generic Security Service Application Program Interface,

Version 2", RFC 2078, January 1997, http://www.ietf.org/rfc/rfc2078.txt

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997, https://www.rfc-
editor.org/rfc/rfc2119.html

[RFC2136] Thomson, S., Rekhter Y. and Bound, J., "Dynamic Updates in the
Domain Name System (DNS UPDATE)", RFC 2136, April 1997,
http://www.ietf.org/rfc/rfc2136.txt

Page | 90
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222,
October 1997, http://www.ietf.org/rfc/rfc2222.txt

[RFC2246] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", RFC 2246,
January 1999, https://www.rfc-editor.org/info/rfc2246

[RFC2247] Kille, S., Wahl, M., Grimstad, A., et al., "Using Domains in LDAP/X.500
Distinguished Names", RFC 2247, January 1998,
http://www.ietf.org/rfc/rfc2247.txt

[RFC2251] Wahl, M., Howes, T., and Kille, S., "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997, http://www.ietf.org/rfc/rfc2251.txt

[RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, S., "Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997,
http://www.ietf.org/rfc/rfc2252.txt

[RFC2253] Wahl, M., Kille, S., and Howe, T., "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253,
December 1997, http://www.ietf.org/rfc/rfc2253.txt

[RFC2255] Howes, T. and Smith, M., "The LDAP URL Format", RFC 2255, December
1997, http://www.ietf.org/rfc/rfc2255.txt

[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997, http://www.ietf.org/rfc/rfc2256.txt

[RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information
Service", RFC 2307, March 1998, http://www.ietf.org/rfc/rfc2307.txt

[RFC2589] Yaacovi, Y., Wahl, M., and Genovese, T., "Lightweight Directory Access
Protocol (v3): Extensions for Dynamic Directory Services", RFC 2589, May 1999,
http://www.ietf.org/rfc/rfc2589.txt

[RFC2696] Weider, C., Herron, A., Anantha, A., and Howes, T., "LDAP Control
Extension for Simple Paged Results Manipulation", RFC 2696, September 1999,
http://www.ietf.org/rfc/rfc2696.txt

Page | 91
[RFC2782] Gulbrandsen, A., Vixie, P., and Esibov, L., "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2782, February 2000,
http://www.ietf.org/rfc/rfc2782.txt

[RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", RFC
2798, April 2000, http://www.ietf.org/rfc/rfc2798.txt

[RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and Morgan, R., "Authentication
Methods for LDAP", RFC 2829, May 2000, http://www.ietf.org/rfc/rfc2829.txt

[RFC2830] Hodges, J., Morgan, R., and Wahl, M., "Lightweight Directory Access
Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000,
http://www.ietf.org/rfc/rfc2830.txt

[RFC2831] Leach, P. and Newman, C., "Using Digest Authentication as a SASL

Mechanism", RFC 2831, May 2000, http://www.ietf.org/rfc/rfc2831.txt

[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical
Specification", RFC 2849, June 2000, http://www.ietf.org/rfc/rfc2849.txt

[RFC2891] Howes, T., Wahl, M., and Anantha, A., "LDAP Control Extension for
Server Side Sorting of Search Results", RFC 2891, August 2000,
http://www.ietf.org/rfc/rfc2891.txt

[RFC3377] Hodges, J. and Morgan, R., "Lightweight Directory Access Protocol (v3):
Technical Specification", RFC 3377, September 2002,
http://www.ietf.org/rfc/rfc3377.txt

[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5",
RFC 3961, February 2005, http://www.ietf.org/rfc/rfc3961.txt

[RFC4120] Neuman, C., Yu, T., Hartman, S., and Raeburn, K., "The Kerberos
Network Authentication Service (V5)", RFC 4120, July 2005, https://www.rfc-
editor.org/rfc/rfc4120.txt

[RFC4121] Zhu, L., Jaganathan, K., and Hartman, S., "The Kerberos Version 5
Generic Security Service Application Program Interface (GSS-API) Mechanism:
Version 2", RFC 4121, July 2005, http://www.ietf.org/rfc/rfc4121.txt

Page | 92
[RFC4122] Leach, P., Mealling, M., and Salz, R., "A Universally Unique Identifier
(UUID) URN Namespace", RFC 4122, July 2005, http://www.rfc-
editor.org/rfc/rfc4122.txt

[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and Ingersoll, W., "The Simple and
Protected Generic Security Service Application Program Interface (GSS-API)
Negotiation Mechanism", RFC 4178, October 2005, https://www.rfc-
editor.org/rfc/rfc4178.txt

[RFC4291] Hinden, R. and Deering, S., "IP Version 6 Addressing Architecture", RFC
4291, February 2006, http://www.ietf.org/rfc/rfc4291.txt

[RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP) Proxied

Authorization Control", RFC 4370, February 2006,
http://www.ietf.org/rfc/rfc4370.txt

[RFC4532] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP)", Who Am

I?" Operation", RFC 4532, June 2006, http://www.ietf.org/rfc/rfc4532.txt

[RFC4757] Jaganathan, K., Zhu, L., and Brezak, J., "The RC4-HMAC Kerberos
Encryption Types Used by Microsoft Windows", RFC 4757, December 2006,
http://www.ietf.org/rfc/rfc4757.txt

[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC
5056, November 2007, https://www.rfc-editor.org/rfc/rfc5056.txt

[RFC5929] Altman, J., Williams, N., and Zhu, L., "Channel Bindings for TLS", RFC
5929, July 2010, https://www.rfc-editor.org/rfc/rfc5929.txt

[RFC5952] Kawamura, S., Kawashima, M., "A Recommendation for IPv6 Address
Text Representation", RFC 5952, August 2010, https://tools.ietf.org/html/rfc5952

[RFC7049] Bormann, C., and Hoffman, P., "Concise Binary Object Representation
(CBOR)", RFC 7049, October 2013, https://www.rfc-editor.org/info/rfc7049

[RFC791] Postel, J., Ed., "Internet Protocol: DARPA Internet Program Protocol
Specification", RFC 791, September 1981, http://www.rfc-
editor.org/rfc/rfc791.txt

Page | 93
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and Rusch, A., "PKCS #1: RSA
Cryptography Specifications Version 2.2", November 2016, https://www.rfc-
editor.org/rfc/rfc8017.txt

[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange
Format", RFC 8259, December 2017, https://www.rfc-editor.org/rfc/rfc8259.txt

[W3C-WebAuthPKC1] Balfanz, D., Czeskis, A., Hodges, J., et al., Eds., "Web
Authentication: An API for accessing Public Key Credentials Level 1", W3C
Recommendation, March 2019, https://www.w3.org/TR/webauthn-1/

[X501] ITU-T, "Information Technology - Open Systems Interconnection - The

Directory: The Models", Recommendation X.501, August 2005,
http://www.itu.int/rec/T-REC-X.501-200508-S/en

[XMLSCHEMA1] Thompson, H., Beech, D., Maloney, M., and Mendelsohn, N., Eds.,
"XML Schema Part 1: Structures", W3C Recommendation, May 2001,
https://www.w3.org/TR/2001/REC-xmlschema-1-20010502/

[XMLSCHEMA2/2] Biron, P., and Malhotra, A., Eds., "XML Schema Part 2:
Datatypes Second Edition", W3C Recommendation, October 2004,
https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

[XPATH] Clark, J. and DeRose, S., "XML Path Language (XPath), Version 1.0", W3C
Recommendation, November 1999, http://www.w3.org/TR/1999/REC-xpath-
19991116/

4 Informative References
[ADDLG] Microsoft Corporation, "Security Briefs: Credentials and Delegation",
September 2005, http://msdn.microsoft.com/en-us/magazine/cc163740.aspx

[LISP15] McCarthy, J., Abrahams, P., Edwards, D., Hart, T., and Levin, M., "LISP 1.5
Programmers Manual", Cambridge, MA: The M.I.T. Press, 1965, ISBN-10:
0262130114.

[MS-ADDM] Microsoft Corporation, "Active Directory Web Services: Data Model

and Common Elements".

Page | 94
[MS-AUTHSOD] Microsoft Corporation, "Authentication Services Protocols
Overview".

[MS-DSSP] Microsoft Corporation, "Directory Services Setup Remote Protocol".

[MS-GPOD] Microsoft Corporation, "Group Policy Protocols Overview".

[MS-SYS-ARCHIVE] Microsoft Corporation, "Windows System Overview",

https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-
WINPROTLP/df36f95e-6a6b-48d6-a3ae-35a17674f546

[MS-XCA] Microsoft Corporation, "Xpress Compression Algorithm".

[MSDN-CAR] Microsoft Corporation, "Control Access Rights",

https://msdn.microsoft.com/en-us/library/ms680945(v=vs.85).aspx

[MSDN-gethostbyname] Microsoft Corporation, "gethostbyname function",

http://msdn.microsoft.com/en-
us/library/windows/desktop/ms738524(v=vs.85).aspx

[MSDOCS-SchUpd] Microsoft Corporation, "Schema Updates",

https://docs.microsoft.com/en-us/windows-server/identity/ad-
ds/deploy/schema-updates

[MSFT-CVE-2021-42278] Microsoft Corporation, "Active Directory Domain

Services Elevation of Privilege Vulnerability", CVE-2021-42278, November 9, 2021,
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42278

[MSFT-CVE-2021-42282] Microsoft Corporation, "Active Directory Domain

Services Elevation of Privilege Vulnerability", CVE-2021-42282, November 9, 2021,
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42282

[MSFT-CVE-2021-42291] Microsoft Corporation, "Active Directory Domain

Services Elevation of Privilege Vulnerability", CVE-2021-42291, November 9, 2021,
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42291

[MSFT-CVE-2022-21857] Microsoft Corporation, "Active Directory Domain

Services Elevation of Privilege Vulnerability", CVE-2022-21857, January 11, 2022,
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21857

Page | 95
[MSKB-3070083] Microsoft Corporation, "Domain join against a Windows Server
2012 R2-based domain controller fails if SPN is not unique in the forest",
https://support.microsoft.com/en-us/kb/3070083

[MSKB-5011543] Microsoft Corporation, "March 22, 2022—KB5011543 (OS Builds

19042.1620, 19043.1620, and 19044.1620) Preview", March 2022,
https://support.microsoft.com/en-us/topic/march-22-2022-kb5011543-os-builds-
19042-1620-19043-1620-and-19044-1620-preview-4fe2d1c0-720f-47fe-9523-
75339bc107a1

[MSKB-5011551] Microsoft Corporation, "March 22, 2022—KB5011551 (OS Build

17763.2746) Preview", March 2022, https://support.microsoft.com/en-
us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-
059e-40f4-87e8-e9139cc65de4

[MSKB-5011558] Microsoft Corporation, "March 22, 2022—KB5011558 (OS Build

20348.617) Preview", March 2022, https://support.microsoft.com/en-
us/topic/march-22-2022-kb5011558-os-build-20348-617-preview-8bb6ded6-
7515-44eb-9fa0-e214eb6d7a75

[MSKB-5011563] Microsoft Corporation, "March 28, 2022—KB5011563 (OS Build

22000.593) Preview", March 2022, https://support.microsoft.com/en-
us/topic/march-28-2022-kb5011563-os-build-22000-593-preview-40df54c9-b5a9-
42e5-ae1c-9a33ff91ca91

[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication

Layers", STD 3, RFC 1122, October 1989, http://www.rfc-
editor.org/rfc/rfc1122.txt

[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980,
http://www.rfc-editor.org/rfc/rfc768.txt

[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, September
1981, http://www.ietf.org/rfc/rfc792.txt

[RFC793] Postel, J., Ed., "Transmission Control Protocol: DARPA Internet Program
Protocol Specification", RFC 793, September 1981, http://www.rfc-
editor.org/rfc/rfc793.txt

Page | 96
[SPNNAMES] Microsoft Corporation, "Name Formats for Unique SPNs",
http://msdn.microsoft.com/en-us/library/ms677601.aspx

[VLVDRAFT] Boreham, D., Sermersheim, J., and Kashi, A., "LDAP Extensions for
Scrolling View Browsing of Search Results", draft-ietf-ldapext-ldapv3-vlv-09,
November 2002, http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09

5 Overview
This is the primary specification for Active Directory. The state model for this
specification is prerequisite to the other specifications for Active Directory: [MS-
DRSR] and [MS-SRPL].
Active Directory is either deployed as AD DS or as AD LDS. This document
describes both forms. When the specification does not refer specifically to AD DS
or AD LDS, it applies to both.

The remainder of this section describes the structure of this document.

The basic state model is specified in section 3.1.1.1. The basic state model is
prerequisite to the remainder of the document. Section 3.1.1.1 also includes
descriptive content to introduce key concepts and refer to places in the document
where the full specification is given.
The schema completes the state model and is specified in section 3.1.1.2. The
schema is prerequisite to the remainder of the document.

Page | 97
Active Directory is a server for LDAP. Section 3.1.1.3 specifies the extensions and
variations of LDAP that are supported by Active Directory.
LDAP is an access protocol that determines very little about the behavior of the
data being accessed. Section 3.1.1.4 specifies read (LDAP Search) behaviors, and
section 3.1.1.5 specifies update (LDAP Add, Modify, Modify DN, Delete)
behaviors. Section 3.1.1.6 specifies background tasks required due to write
operations, to the extent that those tasks are exposed by protocols.
One of the update behaviors is the maintenance of the change log for use by
Windows NT 4.0 backup domain controller (BDC) replication [MS-NRPC] section
3.6. The maintenance of this change log is specified in section 3.1.1.7.
The security services that Active Directory offers clients of LDAP are specified in
section 5.1.
Active Directory contains a number of objects, visible through LDAP, that have
special significance to the system. Section 6.1 specifies these objects.
A server running Active Directory is part of a distributed system that performs
replication. The Knowledge Consistency Checker (KCC) is a component that is
used to create spanning trees for DC-to-DC replication, and is specified in section
6.2.
A server running Active Directory is responsible for publishing the services that it
offers, in order to eliminate the administrative burden of configuring clients to
use particular servers running Active Directory. A server running Active Directory
also implements the server side of the LDAP ping and mailslot ping protocols to
aid clients in selecting among all the servers offering the same service. Section 6.3
specifies how a server running Active Directory publishes its services, and how a
client needing some service can use this publication plus the LDAP ping or mailslot
ping to locate a suitable server.
Computers in a network with Active Directory can be put into a state called
"domain joined"; when in this state, the computer can authenticate itself. Section
6.4 specifies both the state in Active Directory and the state on a computer
required for the domain joined state.

Page | 98
Each type of data stored in Active Directory has an associated function that
compares two values to determine if they are equal and, if not, which is greater.
Section 3.1.1.2 specifies all but one of these functions; the methodology for
comparing two Unicode strings is specified in section 6.5.
6 Relationship to Other Protocols
This is the primary specification for Active Directory. The state model for this
specification is prerequisite to the specification for Active Directory described in
[MS-DRSR]. This Active Directory Technical Specification depends on the following
protocols:
▪ Lightweight Directory Access Protocol (LDAP)
▪ Remote Procedure Call (RPC)
▪ Domain Name System (DNS)

Figure 1: Protocol and technical specification relationships

Other protocols make use of implementations of the Active Directory Technical
Specification as a data store.
7 Prerequisites/Preconditions
Active Directory requires an IP network and a DNS infrastructure.
8 Applicability Statement
Active Directory is not suitable for storing very large attribute values because, for
instance, there is no provision for check-pointing a large data transfer to allow
restart after a failure. The bandwidth and latency of typical networks makes
Active Directory unsuitable for storing volatile data in replicated attributes.

Page | 99
Active Directory is especially suitable for storing security account data, including
passwords, and email address book data.

Active Directory Protocols Overview

Provides an overview of the functionality and relationship of the protocols that

make up the client-server and server-to-server behavior of Active Directory.
The Active Directory protocols provide directory services for the:
• centralized storage of identity
• account information
• storage for other forms of data such as group policies
• printer location information
• foundation for authentication services in a domain environment
• domain services
• directory replication services in Windows
The Active Directory protocols are specified in [LDAP], [MS-ADTS], [MS-SRPL],
[MS-DRSR], [MS-SNTP], [MS-LSAD], [MS-LSAT], [MS-DSSP], [MS-SAMR], [MS-
SAMS], [MS-WSDS], [WFXR], [WSENUM], [MS-WSTIM], [MS-ADDM], [MS-
WSPELD], and [MS-ADCAP].

9 Introduction
Active Directory® is a directory service (DS). Directory services can be used to
provide a central store for identity and account information as well as storage of
information for other systems and applications. Use of the Active Directory
system is appropriate when there is a requirement for a DS. It is also appropriate
when building another system that has a dependency on the Active Directory
protocols. An example of such a system is the Group Policy system, which is
described in the Group Policy Protocols Overview document [MS-GPOD].

Page | 100
This document describes the member protocols that comprise the Active
Directory system. It also describes the abstract state that is shared between the
system's protocols. This document is intended for anyone who plans to
implement the Active Directory system because it provides a high-level
introduction to the functionality of the system and also describes the protocols
that an implementation of the Active Directory system supports.
This document does not duplicate or replace the content of the protocol
specifications that describe the individual protocols in the Active Directory
system. An implementer has to refer to those Technical Documents (TDs) for
information about each protocol. Additionally, the Active Directory Technical
Specification [MS-ADTS] contains vital information about the behavior of the DS,
such as the state model and processing rules, that is essential to the correct
functioning of the system.
A DS is a service that stores and organizes directory objects in a centralized,
hierarchical data store. This hierarchical organization of objects is called the
directory. A directory object is an object that contains one or more attributes.
Each attribute can have one or more values. Directory objects are identified by a
name that is unique among all directory objects in the DS. The directory objects
are organized in a hierarchical manner with regards to other directory objects. For
example, a DS might have a container directory object named Users, the contents
of which (referred to as child directory objects) are containers named for each
logical division of users; for example, Accounting Department, Human Resources
Department, Engineering Department, and so on. The contents of each of these
containers, in turn, could be user objects, each of which represents one individual
user and contains attributes that store information about that user, such as the
user name, password, or telephone number. The following diagram shows this
example.

Page | 101
Figure 2: Example of directory organization
The Active Directory system can operate in two distinct modes:
• as Active Directory Lightweight Directory Services (AD LDS)
• and as Active Directory Domain Services (AD DS).
AD LDS consists of a directory service that is accessible via the Lightweight
Directory Access Protocol (LDAP) versions 2 and 3. AD LDS is primarily intended
for use by application software as a storage mechanism. Note that information
that is applicable to AD LDS on applicable Windows Server releases is also
generally applicable to AD LDS on Windows clients. For more information, see
[MS-ADTS] section 1.
AD DS is also accessible via LDAP versions 2 and 3, but it extends the basic DS to
include additional capabilities, such as the ability to host domain naming contexts
(domain NCs), and additional protocols. This permits AD DS to store the account
information for the users of a computer network. The collection of accounts that
is stored in AD DS is referred to as a domain. Such account storage is a vital
function of the Active Directory system, and in particular of AD DS. However, the
Active Directory system is not limited to storing such information. Any

Page | 102
information that can be represented as a collection of attribute/value pairs,
including the possibility of multivalued attributes, can be modeled as a directory
object and can be stored in the Active Directory system.
Except where noted otherwise, information in this document applies to both AD
DS and AD LDS. The Active Directory system encompasses both AD DS and AD
LDS.
Physically, the Active Directory system consists of one or more computer servers
that run a directory service. In the case of both AD DS and AD LDS, these
computers are referred to as domain controllers (DCs). Even though the directory
service can be running on multiple computers, these computers replicate the
contents of the directory so that a client sees a consistent view of the directory
no matter which directory server or DC it communicates with. The network
protocols that perform this replication are described in [MS-DRSR], [MS-NRPC]
section 3.6, and [MS-SRPL].<1>
Note This document, like [MS-ADTS] and [MS-DRSR], uses the term "domain
controller" to refer to a DS that runs as either AD DS or AD LDS. Both AD DS and
AD LDS are considered to be directory services.
Directory objects can be created and deleted in the directory. Subsequent to its
creation, the contents of a directory object can be modified by adding or
removing attributes and their values, or by changing the values of existing
attributes. Clients can retrieve the contents of directory objects either by reading
the attributes of a specific object or by querying for any objects that match client-
specified criteria.
The core protocol that clients use to perform operations is LDAP version 3 as
described in [MS-ADTS] which is preferred over version 2. Clients can also
communicate with the Active Directory system by using the network protocols
described in [MS-DRSR], [MS-SRPL], [MS-SAMR], [MS-LSAD], [MS-LSAT], and [MS-
DSSP], as well as the Web Service protocols described in [MS-ADDM], [MS-
WSTIM], [MS-ADCAP], [MS-WSDS], and [MS-WSPELD]. The set of protocols that
the Active Directory system supports depends on whether the system is running
as AD DS or AD LDS (see section 2.8).

Page | 103
This document provides a description of the client-server functionality of the
Active Directory system and additional specific benefits that a client realizes from
being associated with an AD DS directory service (that is, "joined to a domain")
that are described later in this document. This document does not describe
identity and security concepts that are defined as part of the Windows Protocols
Overview Document [MS-WPO].
A directory service is a service that stores and organizes directory objects in a
centralized, hierarchical data store. A central concept in the directory service is
the directory tree. A directory tree is an arrangement of directory objects into a
tree structure. Each directory object has exactly one parent directory object,
except for the object that serves as the root of the tree and has no parent. Each
directory object can have zero or more child objects. Each directory object is
assigned a name (the relative distinguished name (RDN)) that is unique among its
sibling objects. Each directory object can be uniquely identified from among all
the other objects in the directory service by its distinguished name (DN), which is
formed by concatenating the RDNs of the directory objects along the path from
the root of the tree to the specific object. For more information, see [MSDN-
DomainTrees].
Domain Interaction
AD DS implements one or more domains within a forest. A domain provides a
number of services to its clients, primarily related to security and management.
The security principals of the domain are all available from the AD DS domain
controller; therefore, the domain serves as the primary source of identity for the
clients of the domain. The domain, through the relevant security protocols,
provides the basis for authentication within the domain, allowing principals
within the domain to establish authenticated connections with each other. During
the authentication process, the domain provides authorization information in the
form of additional identities that represent groups, enabling authorization
decisions to be made.
AD DS stores directory data and manages communication between users and
domains. This includes user logon processes, authentication, and directory
searches. AD DS provides a distributed database that stores and manages
information about network resources and application-specific data from

Page | 104
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 Active Directory forest, domains in the forest, and organizational
units (OUs) in each domain.
The Active Directory system that runs as the AD DS service on an AD DS domain
controller provides certain services and benefits to domain-joined clients. These
benefits include support for the Kerberos authentication protocol, which domain-
joined clients can use to authenticate to the AD DS domain controller and to each
other. The benefits also include certificate autoenrollment, which automatically
deploys certificates to domain-joined computers and to users whose accounts are
stored in the directory service, and automatic deployment of administrator-
configured policy settings.
Many network-related operations depend on domains in order to complete
various tasks. This document describes some of these tasks, including:
▪ Locating a domain controller using DNS and NetBIOS.
▪ Joining a domain by creating an account via the Security Account Manager
remote procedure call (RPC) protocol [MS-SAMR].
▪ Joining a domain by creating an account via LDAP.
▪ Removing a domain member.
This document includes protocols that are used to communicate with a domain
controller and maintain state. It also includes protocols that are used to augment
authentication and authorization actions, and protocols that are used to interact
with domain controllers.
The domain controller serves a central role in an enterprise network by
functioning as the root of authority for sets of users and computers. A domain
controller aggregates functionality that relates to identity management,
authentication, authorization, and other management policy. Clients of the
domain functionality in turn rely on the domain controller to establish secure
communication, authorize requests, and apply policy. A client of the domain can

Page | 105
itself be a server of some other role, for example, a file server that is handling the
file storage requirements of other client workstations.
Directory Replication
Active Directory is a distributed directory service that stores objects that
represent real-world entities, such as users, computers, services, and network
resources. Objects in the directory are distributed among all domain controllers in
a forest, and all domain controllers can be updated directly. Active Directory
replication is the process by which the changes that originate on one domain
controller are automatically transferred to other domain controllers that store the
same data.
The Active Directory replication model ensures that Active Directory data on one
domain controller will eventually converge with the replica of the same data on
other domain controllers in the same domain. The Active Directory replication
model determines how changes to Active Directory data are propagated and
tracked automatically between domain controllers. The replication model allows
directory data on each domain controller to be updated directly. Each domain
controller maintains replication metadata that indicates the update status both
for itself and relative to other domain controllers. In addition, the replication
model allows each domain controller to request (or pull) only the changes that
need to be replicated and to forward changes to other domain controllers that
require them.
When a change is made to an object in a directory partition, the value of the
changed attribute or attributes is updated on all domain controllers that store a
replica of the same directory partition. Domain controllers communicate data
updates automatically through Active Directory replication. Their communication
about updates is always specific to a single directory partition at a time.
A domain that is run by AD DS can consist of many partitions or naming contexts
(NCs). The DN of an object includes enough information to locate a replica of the
partition that holds the object. The global catalog (GC) contains a partial replica
of every NC in the directory. It also contains the schema and configuration
naming contexts (config NCs). This means that the GC holds a replica of every
object in the directory but with only a small number of their attributes. The
attributes in the GC are those that are most frequently used in search operations,

Page | 106
such as a user's first and last names or logon names, and those required to locate
the full replica of the object.
Active Directory objects are instances of schema-defined classes, which consist of
named sets of attributes. Schema definitions determine whether an attribute can
be administratively changed. Attributes that cannot be changed are never
updated and therefore never replicated. However, most Active Directory objects
have attribute values that can be updated.
Replication within a site occurs as a response to changes. On its NTDS Settings
object, the source domain controller stores a repsTo attribute that lists all servers
in the same site that pull replication from it. The Knowledge Consistency Checker
(KCC) updates these attributes, as described later in this section.
When a change occurs on a source domain controller, it notifies its destination
replication partner, prompting the destination domain controller to request the
changes from the source domain controller. The source domain controller either
responds to the change request with a replication operation or places the request
in a queue if requests are already pending. Each domain controller has a queue of
pending replication operations that are processed one at a time.
Directory Replication Service (DRS) Remote Protocol [MS-DRSR] is an RPC protocol
for replication and management of data in Active Directory. Domain controllers
use the Security Account Manager (SAM) Remote Protocol (Server-to-Server) [MS-
SAMS] to forward time-critical database changes to the primary domain
controller (PDC), and to forward time-critical database changes from a read-only
domain controller (RODC) to a writable NC replica within the same domain
outside the normal replication protocol. This protocol is used only between Active
Directory servers in the same domain. Beginning with Windows Server 2008
operating system, this protocol was extended to forward certain write operations
that are not time critical from an RODC to a writable NC replica. The SAMS
protocol addresses the requirement to propagate a subset of database changes to
the PDC more quickly than the Directory Replication Service (DRS) Remote
Protocol. This rapid propagation is used for sensitive information when the delay
imposed by standard Active Directory replication creates an unwelcome burden
on the user or creates a risk to the enterprise. An example of the former is a
password change operation; if the password is not made available rapidly, a user

Page | 107
can experience unpredictable authentication failures when the new password is
tried against domain controllers that have not yet replicated it. An example of the
latter is when an account is locked out due to multiple password failures; the
lockout condition, and, equally important, the lockout-cleared condition, has to
be propagated rapidly throughout the domain.
Replication can be event-driven or schedule-driven as explained in [MS-ADTS]
section 3.1.1.1.14.
Knowledge Consistency Checker (KCC)
A domain controller that runs Active Directory is part of a distributed system that
performs replication. The KCC is a component that reduces the administrative
burden of maintaining a functioning replication topology. The KCC ensures that a
replication path exists between the same NCs that are present in different DCs.
The KCC is explained in [MS-ADTS] sections 3.1.1.1.13 and 6.2. The KCC helps
administrators build a replication topology that incurs minimal cost. This cost is
defined by the administrator as explained in [MS-ADTS] section 3.1.1.1.13.
FSMO Roles
Each DC accepts originating updates for most attributes of most objects within its
writable NC replicas. However, certain updates are accepted only if the DC is the
single designated "master" DC for the update. This mechanism is called flexible
single master operation (FSMO).
If some or all of the updates to an object are single-mastered, that object belongs
to a defined set of objects. [MS-DRSR] section 4.1.10.5.3 (GetReplScope) specifies
these sets, which are called FSMO roles. Each FSMO role is applicable to a certain
scope: either domain-wide, or forest-wide. The domain-wide FSMO roles include
the Infrastructure Master FSMO, the Rid Master FSMO, and the PDC Emulator
FSMO. The forest-wide FSMO roles include the Domain Naming FSMO and the
Schema Master FSMO. There are no FSMO roles that apply strictly to application
NCs.
Because a server that is operating as AD LDS does not host domain NCs, it cannot
own any of the three domain-specific FSMO roles. It can own the Schema Master
FSMO and Domain Naming FSMO roles.

Page | 108
In a given NC, each FSMO role is represented by an object. [MS-DRSR] section
4.1.10.5.3 (GetReplScope) specifies these objects, which are called FSMO role
objects.
The fSMORoleOwner attribute of each FSMO role object is an object reference to
the nTDSDSA object of the DC that owns the role; that is, the DC that performs
updates to objects in the role. Information about nTDSDSA objects and how they
represent DCs are specified in [MS-ADTS] section 6.1.
An originating update to an object within a FSMO role generates an LDAP referral
if the DC that receives the request cannot perform the update; the referral is to
the DC represented by the nTDSDSA object referenced by the FSMO role object's
fSMORoleOwner attribute on the DC that received the request.
The processing of updates affected by FSMO roles is fully specified in [MS-ADTS]
section 3.1.1.5.
The IDL_DRSGetNCChanges method ([MS-DRSR] section 4.1.10) makes an
originating update to the fSMORoleOwner attribute of a FSMO role object while
preserving single-mastering of updates to the FSMO role. The ability to update
the fSMORoleOwner attribute in this way is exposed through LDAP as the root
DSE updates becomeDomainMaster, becomeInfrastructureMaster, becomePdc,
becomePdcWithCheckPoint, becomeRidMaster, and becomeSchemaMaster, as
specified in [MS-ADTS] section 3.1.1.3.
Reading the rootDSE attribute valid FSMOs on a DC returns the set of all FSMO
roles (represented as FSMO role objects) that the DC will update, as specified in
[MS-ADTS] section 3.1.1.3.
Active Directory Trust Management
Active Directory domains rarely exist in isolation. Many Active Directory
deployments in customer sites consist of two or more domains that represent
boundaries between different geographical, managerial, organizational, or
administrative layouts. For example, when company "A" acquires company "B", it
quickly becomes necessary for preexisting domains to start trusting each other.
Alternatively, in some deployments, servers that have a specific role (such as a
mail server) can be members of a "resource domain", easing the management
burden by combining like roles under one administrative domain.

Page | 109
Communication between disparate domains, especially secure communication
that involves authentication and authorization, requires that some stateful
knowledge is shared between the peer domains in order for them to trust one
another. Some of this knowledge is sensitive, forming the cryptographic basis of
trust mechanisms used in protocols such as Kerberos and Netlogon RPC. Other
state is public knowledge, such as the NetBIOS name of a peer domain, or which
security identifiers are owned by the peer domain. Information like this plays a
crucial role when performing name lookups, which are essential for authorization,
locating user accounts, or simply displaying information in some type of user
interface.
Active Directory stores trust information in trusted domain objects (TDOs) ([MS-
ADTS] section 6.1.6.2) and, depending on the kind of trust established, in
associated user accounts, interdomain trust accounts, for the trusted domain.
There are different types of trusts that exist between Active Directory domains, as
described in [MS-ADTS] section 6.1.6.2. TDOs can be managed through the LSAD
protocol ([MS-LSAD] section 3.1.4.7).

Page | 110
What is Active Directory: The Ultimate Guide

Michael Reinders
|
JAN 6, 2022

Learn what Active Directory (AD) is and how AD makes it easier for IT to
manage their organization’s computer resources. Active Directory is especially
useful for companies that have to manage lots of endpoints and servers. Read
more here.

Table of Contents[hide]
• What is Active Directory and why is it used?
• What is AD Domain Services?
• Who is Active Directory for?
• How Active Directory works
• Understanding the structure of AD Domain Services
• What about other Active Directory services?
• How Active Directory helps IT
• What are the steps in setting up Active Directory?
• Active Directory vs LDAP or NIS
• Windows Server Active Directory vs Azure Active Directory

What is Active Directory and why is it used?

Active Directory (AD) is a directory service from Microsoft that stores
information about objects on the network and makes this information easy for
administrators and users to find and use. Active Directory uses a structured
data store as the basis for a logical, hierarchical organization of directory
information. Think of it as a telephone directory but for objects and devices on
a computer network.

Page | 111
 Active Directory Users
and Computers

AD controls much of the activity that goes on in your IT environment. In

particular, they make sure each person is who they claim to be
(authentication), usually by checking the user ID and password they enter and
allowing them to access only the data they’re allowed to use (authorization).

What is AD Domain Services?

Active Directory Domain Services (AD DS)
A directory is a hierarchical structure that stores information about objects on
the network. A directory service, such as Active Directory Domain Services
(AD DS), provides methods for storing directory data and making this data
available to network users and administrators.

When you install AD DS in your environment, servers install the AD DS Server

Role and they become the keys to the kingdom for this directory service, other
known as domain controllers (DC). For example, AD DS stores information

Page | 112
about user accounts, such as names, passwords, phone numbers, computers,
and other devices like printers and other network resources.

This allows only authorized users, which are each assigned a unique security
identifier (SID), to access protected information on the same network to. The
individual attributes of a user: name, address, location, manager, and so on,
are stored in the directory database.

What determines what users can do with the various resources in your
network? Permissions. Tokens, are granted every time a user logs on to a
computer. Those access tokens contain the keys that the user needs to be
able to open the G: drive and open that Excel file in the Sales folder.

Who is Active Directory for?

Well, honestly, I would have to say AD is for almost any company or
organization out there. I have yet to come across an environment that didn’t
utilize Active Directory Domain Services. AD simplifies life for administrators
and end users while enhancing security for organizations.

Administrators and end users share the centralized user and rights
management, as well as centralized control over computer and user
configurations through the AD Group Policy feature. Users can authenticate
once and then seamlessly access any resources in the domain for which
they’re authorized (single sign-on).

Plus, files are stored in a central repository where they can be shared with
other users to ease collaboration and backed up properly by IT teams to
ensure business continuity.

How Active Directory works

So, what’s at the heart of how this service introduced in Windows 2000
works? Well, Active Directory Domain Services (AD DS) is a part of
the Windows Server operating system. The servers that run AD DS are called
domain controllers (DCs).

Page | 113
Back in the days of Windows NT Server, there was a specific role, the Primary
Domain Controller (PDC), that was specified to hold a lot of the key roles
across the domain amongst the other DCs.

Organizations normally have multiple DCs for redundancy, performance, and

business continuity. Each one has a copy of the directory for the entire
domain. Changes made to the directory on one domain controller — such as
password update or the deletion of a user account — are replicated using
a replication service to the other DCs so they all stay up to date.

In addition, the schema of the database central to AD DS includes the various

attributes each person, group, or computer can hold.

A Global Catalog (GC) server is a domain controller that stores a complete

copy of all objects in the directory of its domain and a partial copy of all
objects of all other domains in the forest; this enables users and applications
to find objects in any domain of their forest.

Desktops, laptops, and other devices running Windows (rather than Windows
Server) can be part of an AD environment, but they do not run AD DS.

AD DS relies on several established protocols and standards, including LDAP

(Lightweight Directory Access Protocol), Kerberos, and DNS (Domain Name
System).

IT admins can use various tools to access AD information, including the Active
Directory Users and Computers (ADUC), the AD Administrative Center, as
well as AD Sites and Services. I invite you to check my separate post
about how to access Active Directory.

It’s important to understand that Active Directory is only for on-premises

Microsoft environments. Microsoft environments in the cloud use Azure Active
Directory, which serves the same purposes as its on-prem namesake.
AD and Azure AD are separate but can work together to some degree if your
organization has both on-premises and cloud IT environments (a hybrid

Page | 114
deployment). I’ll give you more on what Azure Active Directory (AAD) is at the
end of this post.
Understanding the structure of AD Domain Services

There are three core logical structures to AD DS. They are domains, trees,
and forests. A domain is a group of related users, computers, and other AD
objects, such as all the AD objects for your company’s various headquarters
and branch offices. Multiple domains can be combined into a tree, and
multiple trees can be grouped into a forest.

Keep in mind that a domain is a management boundary. The objects for a

given domain are stored in a single database and can be managed together.
A forest is a security boundary. Objects in different forests are not able to
interact with each other unless the administrators of each forest create a
trust between them.

For instance, if you have multiple disjointed business units, it’s likely to assist
you with managing them if you create multiple forests.

What about other Active Directory services?

So, is Active Directory simply AD DS? Nope. There are a few other software
features that make up the whole of AD. The most common one after AD DS
is Active Directory Federation Services (AD FS).

Active Directory Federation Service (AD FS) enables Federated Identity and
Access Management (IAM) by securely sharing digital identity and
entitlements rights across security and enterprise boundaries.
AD FS extends the ability to use single sign-on functionality that is available within a
single security or enterprise boundary to Internet-facing applications to enable
customers, partners, and suppliers a streamlined user experience while accessing the
web-based applications of an organization.

Starting in Windows Server 2012 R2, AD FS included a federation service role

service that acts as an identity provider (authenticates users to provide
security tokens to applications that trust AD FS) or as a federation provider
(consumes tokens from other identity providers and then provides security
tokens to applications that trust AD FS).

Page | 115
The other main services include:

•Active Directory Lightweight Directory Services (LDAP) – a light-

weight instance of Active Directory that can be used for apps that
need a directory service.
• Active Directory Certificate Services (AD CS) – manages and issues
digital certificates to users and computers.
• Active Directory Rights Management Services (AD RMS) – lets
organizations granularly control how documents are used by entities
that have access.
• Active Directory Federation Services (AD FS) – used for enabling
access and management between enterprises.
How Active Directory helps IT

There are several benefits for IT folk in using AD DS in your organization:

• You can choose how to organize your data across the various
teams of users and roles in your organization.

• You can manage AD DS from any computer on the network, if

necessary.

• AD DS provides built-in replication and redundancy: if one domain

controller (DC) fails, another DC picks up the load.

• All access to network resources goes through AD DS, which keeps

network access rights management centralized.

The largest benefit of implementing Active Directory for your users is a

centralized token to log in to their computer. Instead of needing this user
account to access the resources on this server, and another for server two,
and so on, you can grant tokens to a single account that a user can use to
seamlessly access resources and printers across the enterprise.

Page | 116
What are the steps in setting up Active Directory?

There are several articles on Petri that contain step-by-step tutorials on how to
install AD in your environment. There is also a considerable amount of
planning that is required in laying out the design of your infrastructure.
Number of servers, physical or virtual, on-premises or in Azure, etc. I’ll give
you the high-level outline of the steps required.

Adding a new AD domain to an existing forest

1. Install the AD DS Role in Server Manager or PowerShell.

2. Promote the server to a domain controller.

Page | 117
 3. Reboot your server and start adding additional domain controllers,
and then user account objects.

4. Start joining organization devices and computers to the domain.

Once you’ve built your Active Directory environment, you’ll need to learn how
to back it up and restore it to prevent any possible interruptions to your
environment. You can check out our guides on how to back up Active
Directory and how to restore Active Directory on Petri.

Active Directory vs LDAP or NIS

We already explained what Active Directory is above. But, what about LDAP
and NIS? What are they, how are they different?

The Network Information Service or NIS (originally called Yellow Pages or YP)
is Sun Microsystems client-server Directory Service protocol for distributed
system configuration data such as user and host names between computers
on a computer network. NIS is a discovery mechanism.

What is LDAP? Companies store usernames, passwords, email addresses,

printer connections, and other static data within directories. LDAP is an open,
vendor-neutral application protocol for accessing and maintaining that data.

LDAP can also utilize authentication, so users can sign on just once and
access many different files on the server (SSO).

Page | 118
Windows Server Active Directory vs Azure Active Directory

Syncing your on-premises AD environment with Azure Active Directory

Azure Active Directory (Azure AD, or AAD) is the next evolution of identity and
access management solutions for the cloud. As I stated at the top of this post,
Microsoft introduced Active Directory Domain Services in Windows 2000 to
give organizations the ability to manage multiple on-premises infrastructure
components and systems using a single identity per user.

Azure AD takes this approach to the next level by providing organizations with
an Identity as a Service (IDaaS) solution for all their apps across cloud and
on-premises.

Feel free to read our separate post about Active Directory, Azure Active
Directory, and other identity providers to see all the core differences between
AD and AAD and how managing them differs.

Page | 119
Active Directory Glossary
This document uses the following terms:
access control entry (ACE): An entry in an access control list (ACL) that contains
a set of user rights and a security identifier (SID) that identifies a principal
for whom the rights are allowed, denied, or audited.
access control list (ACL): A list of access control entries (ACEs) that collectively
describe the security rules for authorizing access to some resource; for
example, an object or set of objects.
account: A user (including machine account), group, or alias object. Also a
synonym for security principal or principal.
account database: The portion of the directory that maintains the accounts for
the principals of the domain. In Windows NT-4 style domains, the account
database includes all information in the domain; in Active Directory–style
domains, the account database contains a subset of the entire LDAP-
accessible directory that the Active Directory–style domain hosts.
Active Directory: The Windows implementation of a general-purpose directory
service, which uses LDAP as its primary access protocol. Active Directory
stores information about a variety of objects in the network such as user
accounts, computer accounts, groups, and all related credential information
used by Kerberos [MS-KILE]. Active Directory is either deployed as Active
Directory Domain Services (AD DS) or Active Directory Lightweight
Directory Services (AD LDS), which are both described in [MS-ADOD]: Active
Directory Protocols Overview.
Active Directory Domain Services (AD DS): A directory service (DS)
implemented by a domain controller (DC). The DS provides a data store for
objects that is distributed across multiple DCs. The DCs interoperate as peers
to ensure that a local change to an object replicates correctly across DCs. AD
DS is a deployment of Active Directory [MS-ADTS].
Active Directory Lightweight Directory Services (AD LDS): A directory service
(DS) implemented by a domain controller (DC). AD LDS is a deployment of
Active Directory [MS-ADTS]. The most significant difference between AD LDS

Page | 120
 and Active Directory Domain Services (AD DS) is that AD LDS does not host
domain naming contexts (domain NCs). A server can host multiple AD LDS
DCs. Each DC is an independent AD LDS instance, with its own independent
state. AD LDS can be run as an operating system DS or as a directory service
provided by a standalone application (Active Directory Application Mode
(ADAM)).
Active Directory-style domain: A domain that is created as described in [MS-
ADTS] section 1. Active Directory-style domains implement Active Directory,
LDAP, Kerberos authentication, and advanced configurations and features
that are not supported in Windows NT 4.0-style domains.
ADCAP: The Active Directory Web Services Custom Action Protocol [MS-
ADCAP].
application naming context (application NC): A specific type of naming context
(NC), or an instance of that type, that supports only full replicas (no partial
replicas). An application NC cannot contain security principal objects in
Active Directory Domain Services (AD DS), but can contain security principal
objects in Active Lightweight Directory Services (AD LDS). A forest can have
zero or more application NCs in either AD DS or AD LDS. An application NC
can contain dynamic objects. Application NCs do not appear in the global
catalog (GC). The root of an application NC is an object of class domainDNS.
attribute: An identifier for a single or multivalued data element that is
associated with a directory object. An object consists of its attributes and
their values. For example, cn (common name), street (street address), and
mail (email addresses) can all be attributes of a user object. An attribute's
schema, including the syntax of its values, is defined in an attributeSchema
object.
backup domain controller (BDC): A domain controller (DC) that receives a copy
of the domain directory database from the primary domain controller (PDC).
This copy is synchronized periodically and automatically with the primary
domain controller (PDC). BDCs also authenticate user logons and can be
promoted to function as the PDC. There is only one PDC or PDC emulator in a
domain, and the rest are backup domain controllers.

Page | 121
 binary large object (BLOB): A collection of binary data stored as a single entity
in a database.
binding: The string representation of the protocol sequence, NetworkAddress,
and optionally the endpoint. Also referred to as "string binding". For more
information, see [C706] section "String Bindings".
certificate: A certificate is a collection of attributes and extensions that can be
stored persistently. The set of attributes in a certificate can vary depending
on the intended usage of the certificate. A certificate securely binds a public
key to the entity that holds the corresponding private key. A certificate is
commonly used for authentication and secure exchange of information on
open networks, such as the Internet, extranets, and intranets. Certificates
are digitally signed by the issuing certification authority (CA) and can be
issued for a user, a computer, or a service. The most widely accepted format
for certificates is defined by the ITU-T X.509 version 3 international
standards. For more information about attributes and extensions, see
[RFC3280] and [X509] sections 7 and 8.
client: Synonym for client computer.
client computer: The client machine in the domain or network topology of
clients, servers, and domain controllers. Alternatively, a computer that is not
a domain controller server; the computer may or may not be joined to a
domain.
configuration naming context (config NC): A specific type of naming context
(NC), or an instance of that type, that contains configuration information. In
Active Directory, a single config NC is shared among all domain controllers
(DCs) in the forest. A config NC cannot contain security principal objects.
credential: Previously established, authentication data that is used by a security
principal to establish its own identity. When used in reference to the
Netlogon Protocol, it is the data that is stored in the
NETLOGON_CREDENTIAL structure.
deleted-object: An object that has been deleted, but remains in storage until a
configured amount of time (the deleted-object lifetime) has passed, after
which the object is transformed to a recycled-object. Unlike a recycled-object

Page | 122
 or a tombstone, a deleted-object maintains virtually all the state of the
object before deletion, and can be undeleted without loss of information.
Deleted-objects exist only when the Recycle Bin optional feature is enabled.
directory: The database that stores information about objects such as users,
groups, computers, printers, and the directory service that makes this
information available to users and applications.
directory object: A Lightweight Directory Access Protocol (LDAP) object, as
specified in [RFC2251], that is a specialization of an object.
directory service (DS): A service that stores and organizes information about a
computer network's users and network shares, and that allows network
administrators to manage users' access to the shares. See also Active
Directory.
directory tree: An LDAP directory service is organized into a hierarchical tree
structure in which each directory object has exactly one parent directory
object (except for one object that serves as the root of the tree) and zero or
more child directory objects.
distinguished name (DN): In the Active Directory directory service, the unique
identifier of an object in Active Directory, as described in [MS-ADTS] and
[RFC2251].
domain: A set of users and computers sharing a common namespace and
management infrastructure. At least one computer member of the set must
act as a domain controller (DC) and host a member list that identifies all
members of the domain, as well as optionally hosting the Active Directory
service. The domain controller provides authentication of members, creating
a unit of trust for its members. Each domain has an identifier that is shared
among its members. For more information, see [MS-AUTHSOD] section
1.1.1.5 and [MS-ADTS].
domain account: A stored set of attributes representing a principal used to
authenticate a user or machine to an Active Directory domain.
domain client: A client computer that is joined to a domain. The domain client
can be a client or a server that offers other services to its clients. When the

Page | 123
 domain client acts as a supplicant to another domain client, the supplicant is
referred to as a domain client in a workstation role and the latter as a
domain client in a server role.
domain controller (DC): The service, running on a server, that implements
Active Directory, or the server hosting this service. The service hosts the data
store for objects and interoperates with other DCs to ensure that a local
change to an object replicates correctly across all DCs. When Active
Directory is operating as Active Directory Domain Services (AD DS), the DC
contains full NC replicas of the configuration naming context (config NC),
schema naming context (schema NC), and one of the domain NCs in its
forest. If the AD DS DC is a global catalog server (GC server), it contains
partial NC replicas of the remaining domain NCs in its forest. For more
information, see [MS-AUTHSOD] section 1.1.1.5.2 and [MS-ADTS]. When
Active Directory is operating as Active Directory Lightweight Directory
Services (AD LDS), several AD LDS DCs can run on one server. When Active
Directory is operating as AD DS, only one AD DS DC can run on one server.
However, several AD LDS DCs can coexist with one AD DS DC on one server.
The AD LDS DC contains full NC replicas of the config NC and the schema NC
in its forest. The domain controller is the server side of Authentication
Protocol Domain Support [MS-APDS].
domain controller server: A domain member, which can be a client or a server
that offers other services to its clients. When the domain client acts as a
supplicant to another domain client, the supplicant is referred to as a domain
client in a workstation role and the latter as a domain client in a server role.
domain functional level: A specification of functionality available in a domain.
Must be less than or equal to the DC functional level of every domain
controller (DC) that hosts a replica of the domain's naming context (NC). For
information on defined levels, corresponding features, information on how
the domain functional level is determined, and supported domain
controllers, see [MS-ADTS] sections 6.1.4.2 and 6.1.4.3. When Active
Directory is operating as Active Directory Lightweight Directory Services (AD
LDS), domain functional level does not exist.

Page | 124
 domain member (member machine): A machine that is joined to a domain by
sharing a secret between the machine and the domain.
Domain Name System (DNS): A hierarchical, distributed database that contains
mappings of domain names to various types of data, such as IP addresses.
DNS enables the location of computers and services by user-friendly names,
and it also enables the discovery of other information stored in the database.
domain naming context (domain NC): A specific type of naming context (NC),
or an instance of that type, that represents a domain. A domain NC can
contain security principal objects; no other type of NC can contain security
principal objects. Domain NCs appear in the global catalog (GC). A domain
NC is hosted by one or more domain controllers (DCs) operating as AD DS. In
AD DS, a forest has one or more domain NCs. A domain NC cannot exist in
AD LDS. The root of a domain NC is an object of class domainDNS; for
directory replication [MS-DRSR], see domainDNS.
domain object: A unit of data storage in a domain that is maintained and made
available to domain members by a domain controller (DC).
endpoint: A network-specific address of a remote procedure call (RPC) server
process for remote procedure calls. The actual name and type of the
endpoint depends on the RPC protocol sequence that is being used. For
example, for RPC over TCP (RPC Protocol Sequence ncacn_ip_tcp), an
endpoint might be TCP port 1025. For RPC over Server Message Block (RPC
Protocol Sequence ncacn_np), an endpoint might be the name of a named
pipe. For more information, see [C706].
enumeration context: A session context that represents a specific traversal
through a logical sequence of XML element information items using the Pull
operation defined in WS-Enumeration specification. See [WSENUM].
extended control: A mechanism that is used to specify extension information in
a Lightweight Directory Access Protocol (LDAP) version 3 operation. It is
documented in [RFC2251] section 4.1.12, Controls, where it is referred to as
a "control".
flexible single master operation (FSMO): A read or update operation on a
naming context (NC), such that the operation must be performed on the

Page | 125
 single designated master replica of that NC. The master replica designation is
"flexible" because it can be changed without losing the consistency gained
from having a single master. This term, pronounced "fizmo", is never used
alone; see also FSMO role, FSMO role owner, and FSMO object.
forest: For Active Directory Domain Services (AD DS), a set of naming contexts
(NCs) consisting of one schema naming context (schema NC), one
configuration naming context (config NC), one or more domain naming
contexts (domain NCs), and zero or more application naming contexts
(application NCs). Because a set of NCs can be arranged into a tree structure,
a forest is also a set containing one or several trees of NCs. For AD LDS, a set
of NCs consisting of one schema NC, one config NC, and zero or more
application NCs. (In Microsoft documentation, an AD LDS forest is called a
"configuration set".)
FSMO role: A set of objects that can be updated in only one naming context
(NC) replica (the FSMO role owner's replica) at any given time. For more
information, see [MS-ADTS] section 3.1.1.1.11. See also FSMO role owner.
FSMO role object: An object in a directory that represents a specific FSMO
role. This object is an element of the FSMO role and contains the
fSMORoleOwner attribute.
fully qualified domain name (FQDN): (1) An unambiguous domain name that
gives an absolute location in the Domain Name System's (DNS) hierarchy
tree, as defined in [RFC1035] section 3.1 and [RFC2181] section 11.
(2) In Active Directory, a fully qualified domain name (FQDN) (1) that
identifies a domain.
global catalog (GC): A unified partial view of multiple naming contexts (NCs) in
a distributed partitioned directory. The Active Directory directory service GC
is implemented by GC servers. The definition of global catalog is specified in
[MS-ADTS] section 3.1.1.1.8.
group: A collection of objects that can be treated as a whole.

Page | 126
 identity: An account that represents a person (user account), an application
(service account), and computers that participate in the domain (machine
accounts). A password is used by the system as proof of an identity.
interdomain trust account: An account that stores information associated with
a domain trust in the domain controllers (DCs) of the domain that is trusted
to perform authentication.
Interface Definition Language (IDL): The International Standards Organization
(ISO) standard language for specifying the interface for remote procedure
calls. For more information, see [C706] section 4.
Kerberos: An authentication system that enables two parties to exchange
private information across an otherwise open network by assigning a unique
key (called a ticket) to each user that logs on to the network and then
embedding these tickets into messages sent by the users. For more
information, see [MS-KILE].
Key Distribution Center (KDC): The Kerberos service that implements the
authentication and ticket granting services specified in the Kerberos
protocol. The service runs on computers selected by the administrator of the
realm or domain; it is not present on every machine on the network. It must
have access to an account database for the realm that it serves. KDCs are
integrated into the domain controller role. It is a network service that
supplies tickets to clients for use in authenticating to services.
Lightweight Directory Access Protocol (LDAP): The primary access protocol for
Active Directory. Lightweight Directory Access Protocol (LDAP) is an industry-
standard protocol, established by the Internet Engineering Task Force (IETF),
which allows users to query and update information in a directory service
(DS), as described in [MS-ADTS]. The Lightweight Directory Access Protocol
can be either version 2 [RFC1777] or version 3 [RFC3377].
mailslot: A mechanism for one-way interprocess communications (IPC). For
more information, see [MSLOT] and [MS-MAIL].
member server: A server that is joined to a domain and is not acting as an
Active Directory domain controller (DC). Member servers typically function

Page | 127
 as file servers, application servers, and so on and defer user authentication
to the domain controller.
mutual authentication: A mode in which each party verifies the identity of the
other party, as described in [RFC3748] section 7.2.1.
naming context (NC): An NC is a set of objects organized as a tree. It is
referenced by a DSName. The DN of the DSName is the distinguishedName
attribute of the tree root. The GUID of the DSName is the objectGUID
attribute of the tree root. The security identifier (SID) of the DSName, if
present, is the objectSid attribute of the tree root; for Active Directory
Domain Services (AD DS), the SID is present if and only if the NC is a domain
naming context (domain NC). Active Directory supports organizing several
NCs into a tree structure.
NetBIOS: A particular network transport that is part of the LAN Manager
protocol suite. NetBIOS uses a broadcast communication style that was
applicable to early segmented local area networks. A protocol family
including name resolution, datagram, and connection services. For more
information, see [RFC1001] and [RFC1002].
Netlogon: The Netlogon Remote Protocol, as specified in [MS-NRPC].
Network Data Representation (NDR): A specification that defines a mapping
from Interface Definition Language (IDL) data types onto octet streams. NDR
also refers to the runtime environment that implements the mapping
facilities (for example, data provided to NDR). For more information, see
[MS-RPCE] and [C706] section 14.
NT Directory Service (NTDS): A previous name for Active Directory.
object class: A set of restrictions on the construction and update of objects. An
object class can specify a set of must-have attributes (every object of the
class must have at least one value of each) and may-have attributes (every
object of the class may have a value of each). An object class can also specify
the allowable classes for the parent object of an object in the class. An object
class can be defined by single inheritance; an object whose class is defined in
this way is a member of all object classes used to derive its most specific

Page | 128
 class. An object class is defined in a classSchema object. See section 1 of
[MS-ADTS] and section 1 of [MS-DRSR].
originating update: An update that is performed to an NC replica via any
protocol except replication. An originating update to an attribute or link
value generates a new stamp for the attribute or link value.
policy: A collection of settings that contains global settings, profile settings,
firewall rules, and connection security rules. Together these settings specify
how the host firewall and Internet Protocol security (IPsec) behave on the
client computer.
primary domain controller (PDC): A domain controller (DC) designated to track
changes made to the accounts of all computers on a domain. It is the only
computer to receive these changes directly, and is specialized so as to ensure
consistency and to eliminate the potential for conflicting entries in the Active
Directory database. A domain has only one PDC.
principal: A unique entity identifiable by a security identifier (SID) that is
typically the requester of access to securable objects or resources. It often
corresponds to a human user but can also be a computer or service. It is
sometimes referred to as a security principal.
read-only domain controller (RODC): A domain controller (DC) that does not
accept originating updates. Additionally, an RODC does not perform
outbound replication. An RODC cannot be the primary domain controller
(PDC) for its domain.
relative distinguished name (RDN): In the Active Directory directory service,
the unique name of a child element relative to its parent in Active Directory.
The RDN of a child element combined with the fully qualified domain name
(FQDN) (2) of the parent forms the FQDN of the child.
relative identifier (RID): The last item in the series of SubAuthority values in a
security identifier (SID) [SIDD]. It distinguishes one account or group from all
other accounts and groups in the domain. No two accounts or groups in any
domain share the same RID.

Page | 129
 remote procedure call (RPC): A communication protocol used primarily
between client and server. The term has three definitions that are often used
interchangeably: a runtime environment providing for communication
facilities between computers (the RPC runtime); a set of request-and-
response message exchanges between computers (the RPC exchange); and
the single message from an RPC exchange (the RPC message). For more
information, see [C706].
replica: A variable containing a set of objects.
replica domain controller / replica directory server: A server that contains a
replicated copy of the directory and is able to answer client requests over
any protocol that the directory service supports.
role: The domain role quantifies the relationship between a computer and a
domain. Domain roles include the following: Joined: Linked to a domain for
purposes of policy and security. Standalone: Not associated with any domain.
Domain controller: Linked to a domain, and hosting that domain.
SASL: The Simple Authentication and Security Layer, as described in [RFC2222].
This is an authentication mechanism used by the Lightweight Directory
Access Protocol (LDAP).
schema: The set of attributes and object classes that govern the creation and
update of objects.
Secure Sockets Layer (SSL): A security protocol that supports confidentiality
and integrity of messages in client and server applications that communicate
over open networks. SSL supports server and, optionally, client
authentication using X.509 certificates [X509] and [RFC5280]. SSL is
superseded by Transport Layer Security (TLS). TLS version 1.0 is based on SSL
version 3.0 [SSL3].
security descriptor: A data structure containing the security information
associated with a securable object. A security descriptor identifies an
object's owner by its security identifier (SID). If access control is configured
for the object, its security descriptor contains a discretionary access control
list (DACL) with SIDs for the security principals who are allowed or denied
access. Applications use this structure to set and query an object's security

Page | 130
 status. The security descriptor is used to guard access to an object as well as
to control which type of auditing takes place when the object is accessed.
The security descriptor format is specified in [MS-DTYP] section 2.4.6; a
string representation of security descriptors, called SDDL, is specified in [MS-
DTYP] section 2.5.1.
security identifier (SID): An identifier for security principals that is used to
identify an account or a group. Conceptually, the SID is composed of an
account authority portion (typically a domain) and a smaller integer
representing an identity relative to the account authority, termed the
relative identifier (RID). The SID format is specified in [MS-DTYP] section
2.4.2; a string representation of SIDs is specified in [MS-DTYP] section 2.4.2
and [MS-AZOD] section 1.1.1.2.
security principal: An entity that is associated with a human user or a program
that can be authenticated. At a minimum, it has two basic attributes, a name
and an identifier, that uniquely identifies it and makes it meaningful to the
system, administrators, and users. A security principal is also known as a
principal or an account.
server: A domain controller. Used as a synonym for domain controller. See [MS-
ADOD]
Server Message Block (SMB): A protocol that is used to request file and print
services from server systems over a network. The SMB protocol extends the
CIFS protocol with additional security, file, and disk management support.
For more information, see [CIFS] and [MS-SMB].
service (SRV) resource record: A Domain Name System (DNS) resource record
used to identify computers that host specific services, as specified in
[RFC2782]. SRV resource records are used to locate domain controllers (DCs)
for Active Directory.
service principal name (SPN): The name a client uses to identify a service for
mutual authentication. (For more information, see [RFC1964] section 2.1.1.)
An SPN consists of either two parts or three parts, each separated by a
forward slash ('/'). The first part is the service class, the second part is the
host name, and the third part (if present) is the service name. For example,

Page | 131
 "ldap/dc-01.fabrikam.com/fabrikam.com" is a three-part SPN where "ldap" is
the service class name, "dc-01.fabrikam.com" is the host name, and
"fabrikam.com" is the service name. See [SPNNAMES] for more information
about SPN format and composing a unique SPN.
service ticket: A ticket for any service other than the ticket-granting service
(TGS). A service ticket serves only to classify a ticket as not a ticket-granting
ticket (TGT) or cross-realm TGT, as specified in [RFC4120].
site: A collection of one or more well-connected (reliable and fast) TCP/IP
subnets. By defining sites (represented by site objects) an administrator can
optimize both Active Directory access and Active Directory replication with
respect to the physical network. When users log in, Active Directory clients
find domain controllers (DCs) that are in the same site as the user, or near
the same site if there is no DC in the site. See also Knowledge Consistency
Checker (KCC). For more information, see [MS-ADTS].
SOAP: A lightweight protocol for exchanging structured information in a
decentralized, distributed environment. SOAP uses XML technologies to
define an extensible messaging framework, which provides a message
construct that can be exchanged over a variety of underlying protocols. The
framework has been designed to be independent of any particular
programming model and other implementation-specific semantics. SOAP 1.2
supersedes SOAP 1.1. See [SOAP1.2-1/2003].
ticket-granting service (TGS): A service that issues tickets for admission to
other services in its own domain or for admission to the ticket-granting
service in another domain.
ticket-granting ticket (TGT): A special type of ticket that can be used to obtain
other tickets. The TGT is obtained after the initial authentication in the
Authentication Service (AS) exchange; thereafter, users do not need to
present their credentials, but can use the TGT to obtain subsequent tickets.
tombstone: An object that has been deleted, but remains in storage until a
configured amount of time (the tombstone lifetime) has passed, after which
the object is permanently removed from storage. By keeping the tombstone
in existence for the tombstone lifetime, the deleted state of the object is

Page | 132
 able to replicate. Tombstones exist only when the Recycle Bin optional
feature is not enabled.
Transmission Control Protocol (TCP): A protocol used with the Internet
Protocol (IP) to send data in the form of message units between computers
over the Internet. TCP handles keeping track of the individual units of data
(called packets) that a message is divided into for efficient routing through
the Internet.
Transport Layer Security (TLS): A security protocol that supports confidentiality
and integrity of messages in client and server applications communicating
over open networks. TLS supports server and, optionally, client
authentication by using X.509 certificates (as specified in [X509]). TLS is
standardized in the IETF TLS working group.
trusted domain: A domain that is trusted to make authentication decisions for
security principals in that domain.
trusted domain object (TDO): A collection of properties that define a trust
relationship with another domain, such as direction (outbound, inbound, or
both), trust attributes, name, and security identifier of the other domain. For
more information, see [MS-ADTS].
User Datagram Protocol (UDP): The connectionless protocol within TCP/IP that
corresponds to the transport layer in the ISO/OSI reference model.
user principal name (UPN): A user account name (sometimes referred to as the
user logon name) and a domain name that identifies the domain in which the
user account is located. This is the standard usage for logging on to a
Windows domain. The format is: [email protected] (in the form of an
email address). In Active Directory, the userPrincipalName attribute of the
account object, as described in [MS-ADTS].
Windows NT 4.0-style domain: A domain that is created from Windows NT 4.0
operating system servers with an account database that includes all the
information in the domain. Windows NT 4.0-style domains do not implement
Active Directory, LDAP directories, or Kerberos authentication.

Page | 133
 writable naming context (NC) replica: A naming context (NC) replica that
accepts originating updates. A writable NC replica is always full, but a full NC
replica is not always writable. Partial replicas are not writable. See also read-
only full NC replica.
XML: The Extensible Markup Language, as described in [XML1.0].

challenge: A 64-bit nonce generated on the client side.

computer name: The DNS or NetBIOS name.
computer object: An object of class computer. A computer object is a security
principal object; the principal is the operating system running on the
computer. The shared secret allows the operating system running on the
computer to authenticate itself independently of any user running on the
system. See security principal.
credential: Previously established, authentication data that is used by a security
principal to establish its own identity. When used in reference to the
Netlogon Protocol, it is the data that is stored in the
NETLOGON_CREDENTIAL structure.
database: For the purposes of the Netlogon RPC, a database is a collection of
user accounts, machine accounts, aliases, groups, and policies, managed by a
component. The database, or the component managing the database, must
expose a mechanism to enable Netlogon to gather changes from and apply
changes to the database. Additionally, it must export a database serial
number in order to track changes for efficient replication.
database serial number: A numeric value that is incremented each time a
database transaction is applied to the database.
decryption: In cryptography, the process of transforming encrypted
information to its original clear text form.
delta: One of a set of possible changes that can be made to a database.

Page | 134
 direct trust: A type of authentication functionality in which one domain accepts
another domain as an authoritative source to provide object authentication
and other Active Directory services for that other domain. For example, if a
direct trust is established from domain, DOMAIN-A, to domain, DOMAIN-B,
DOMAIN-A trusts DOMAIN-B. If a domain, DOMAIN-A, must authenticate an
object, such as a user account, from a domain, DOMAIN-B, DOMAIN-A
requests that DOMAIN-B authenticate the user account, and DOMAIN-A will
treat the response from DOMAIN-B as reliable.
directory service (DS): A service that stores and organizes information about a
computer network's users and network shares, and that allows network
administrators to manage users' access to the shares. See also Active
Directory.
DNS name: A fully qualified domain name (FQDN).
domain: A set of users and computers sharing a common namespace and
management infrastructure. At least one computer member of the set must
act as a domain controller (DC) and host a member list that identifies all
members of the domain, as well as optionally hosting the Active Directory
service. The domain controller provides authentication of members, creating
a unit of trust for its members. Each domain has an identifier that is shared
among its members. For more information, see [MS-AUTHSOD] section
1.1.1.5 and [MS-ADTS].
domain account: A stored set of attributes representing a principal used to
authenticate a user or machine to an Active Directory domain.
domain controller (DC): The service, running on a server, that implements
Active Directory, or the server hosting this service. The service hosts the data
store for objects and interoperates with other DCs to ensure that a local
change to an object replicates correctly across all DCs.
When Active Directory is operating as Active Directory Domain Services (AD
DS), the DC contains full NC replicas of the configuration naming context
(config NC), schema naming context (schema NC), and one of the domain
NCs in its forest. If the AD DS DC is a global catalog server (GC server), it

Page | 135
 contains partial NC replicas of the remaining domain NCs in its forest. For
more information, see [MS-AUTHSOD] section 1.1.1.5.2 and [MS-ADTS].
When Active Directory is operating as Active Directory Lightweight Directory
Services (AD LDS), several AD LDS DCs can run on one server. When Active
Directory is operating as AD DS, only one AD DS DC can run on one server.
However, several AD LDS DCs can coexist with one AD DS DC on one server.
The AD LDS DC contains full NC replicas of the config NC and the schema NC
in its forest. The domain controller is the server side of Authentication
Protocol Domain Support [MS-APDS].
domain local group: An Active Directory group that allows user objects, global
groups, and universal groups from any domain as members. It can
additionally include, and be a member of, other domain local groups from
within its domain. A group object g is a domain local group if and only if
GROUP_TYPE_RESOURCE_GROUP is present in g!groupType; see [MS-ADTS]
section 2.2.12, "Group Type Flags". A security-enabled domain local group is
valid for inclusion within access control lists (ACLs) from its own domain. If a
domain is in mixed mode, then a security-enabled domain local group in
that domain allows only user objects as members.
domain member (member machine): A machine that is joined to a domain by
sharing a secret between the machine and the domain.
domain name: A domain name or a NetBIOS name that identifies a domain.
Domain Name System (DNS): A hierarchical, distributed database that contains
mappings of domain names to various types of data, such as IP addresses.
DNS enables the location of computers and services by user-friendly names,
and it also enables the discovery of other information stored in the database.
domain tree: A set of domains that are arranged hierarchically, typically
following an accompanying DNS hierarchy, with trusts between parents and
children. An example domain tree might be a.example.com, b.example.com,
and example.com; domain A and domain B each trust example.com but do
not trust each other directly. They will have a transitive trust relationship
through example.com.

Page | 136
 dynamic endpoint: A network-specific server address that is requested and
assigned at run time. For more information, see [C706].
encryption key: One of the input parameters to an encryption algorithm.
Generally speaking, an encryption algorithm takes as input a clear-text
message and a key, and results in a cipher-text message. The corresponding
decryption algorithm takes a cipher-text message, and the key, and results in
the original clear-text message.
endpoint: A network-specific address of a remote procedure call (RPC) server
process for remote procedure calls. The actual name and type of the
endpoint depends on the RPC protocol sequence that is being used. For
example, for RPC over TCP (RPC Protocol Sequence ncacn_ip_tcp), an
endpoint might be TCP port 1025. For RPC over Server Message Block (RPC
Protocol Sequence ncacn_np), an endpoint might be the name of a named
pipe. For more information, see [C706].
enterprise network: The network of computer systems in an organization, such
as a corporation. An enterprise can span geographical locations and often
includes a variety of computer types, operating systems, protocols, and
network architectures.
forest: One or more domains that share a common schema and trust each
other transitively. An organization can have multiple forests. A forest
establishes the security and administrative boundary for all the objects that
reside within the domains that belong to the forest. In contrast, a domain
establishes the administrative boundary for managing objects, such as users,
groups, and computers. In addition, each domain has individual security
policies and trust relationships with other domains.
forest trust: A type of trust where the trusted party is a forest, which means
that all domains in that forest are trusted.
forest trust information: Information about namespaces, domain names, and
security identifiers (SIDs) owned by a trusted forest.
full database synchronization: A mechanism for synchronizing an entire
database record set on a particular replication partner.

Page | 137
 fully qualified domain name (FQDN): In Active Directory, a fully qualified
domain name (FQDN) that identifies a domain.
global catalog (GC): A unified partial view of multiple naming contexts (NCs) in
a distributed partitioned directory. The Active Directory directory service GC
is implemented by GC servers. The definition of global catalog is specified in
[MS-ADTS] section 3.1.1.1.8.
globally unique identifier (GUID): A term used interchangeably with
universally unique identifier (UUID) in Microsoft protocol technical
documents (TDs). Interchanging the usage of these terms does not imply or
require a specific algorithm or mechanism to generate the value. Specifically,
the use of this term does not imply or require that the algorithms described
in [RFC4122] or [C706] must be used for generating the GUID. See also
universally unique identifier (UUID).
group: A collection of objects that can be treated as a whole.
Hash-based Message Authentication Code (HMAC): A mechanism for message
authentication using cryptographic hash functions. HMAC can be used with
any iterative cryptographic hash function (for example, MD5 and SHA-1) in
combination with a secret shared key. The cryptographic strength of HMAC
depends on the properties of the underlying hash function.
interactive logon: A software method in which the account information and
credentials input by the user interactively are authenticated by a server or
domain controller (DC).
Interface Definition Language (IDL): The International Standards Organization
(ISO) standard language for specifying the interface for remote procedure
calls. For more information, see [C706] section 4.
Key Distribution Center (KDC): The Kerberos service that implements the
authentication and ticket granting services specified in the Kerberos
protocol. The service runs on computers selected by the administrator of the
realm or domain; it is not present on every machine on the network. It must
have access to an account database for the realm that it serves. KDCs are

Page | 138
 integrated into the domain controller role. It is a network service that
supplies tickets to clients for use in authenticating to services.
key list request: A Kerberos protocol message used to request a list of key
types the KDC can supply to the client to support single sign-on capabilities in
legacy protocols.
Lightweight Directory Access Protocol (LDAP): The primary access protocol for
Active Directory. Lightweight Directory Access Protocol (LDAP) is an industry-
standard protocol, established by the Internet Engineering Task Force (IETF),
which allows users to query and update information in a directory service
(DS), as described in [MS-ADTS]. The Lightweight Directory Access Protocol
can be either version 2 [RFC1777] or version 3 [RFC3377].
Local Security Authority (LSA): A protected subsystem that authenticates and
logs users onto the local system. LSA also maintains information about all
aspects of local security on a system, collectively known as the local security
policy of the system.
Local Security Authority (LSA) database: A Microsoft-specific terminology for
the part of the user account database containing account privilege
information (such as specific account rights) and domain security policy
information.
mailslot: A mechanism for one-way interprocess communications (IPC). For
more information, see [MSLOT] and [MS-MAIL].
mixed mode: A state of an Active Directory domain that supports domain
controllers (DCs) running Windows NT Server 4.0 operating system. Mixed
mode does not allow organizations to take advantage of new Active
Directory features such as universal groups, nested group membership, and
interdomain group membership. See also native mode.
naming context (NC): An NC is a set of objects organized as a tree. It is
referenced by a DSName. The DN of the DSName is the distinguishedName
attribute of the tree root. The GUID of the DSName is the objectGUID
attribute of the tree root. The security identifier (SID) of the DSName, if
present, is the objectSid attribute of the tree root; for Active Directory

Page | 139
 Domain Services (AD DS), the SID is present if and only if the NC is a domain
naming context (domain NC). Active Directory supports organizing several
NCs into a tree structure.
NetBIOS name: A 16-byte address that is used to identify a NetBIOS resource
on the network. For more information, see [RFC1001] and [RFC1002].
Netlogon: In a Windows NT operating system-compatible network security
environment, the component responsible for synchronization and
maintenance functions between a primary domain controller (PDC) and
backup domain controllers (BDC). Netlogon is a precursor to the directory
replication server (DRS) protocol.
network logon: A software method in which the account information and
credentials previously supplied by the user as part of an interactive logon are
used again to log the user onto another network resource.
nonce: A number that is used only once. This is typically implemented as a
random number large enough that the probability of number reuse is
extremely small. A nonce is used in authentication protocols to prevent
replay attacks. For more information, see [RFC2617].
NT LAN Manager (NTLM): An authentication protocol that is based on a
challenge-response sequence for authentication.
one-way function (OWF): The calculation of a hash of the password using the
Rivest-Shamir-Adleman (RSA) MD4 function. OWF is used to refer to the
resulting value of the hash operation.
opnum: An operation number or numeric identifier that is used to identify a
specific remote procedure call (RPC) method or a method in an interface.
For more information, see [C706] section 12.5.2.12 or [MS-RPCE].
original equipment manufacturer (OEM) character set: A character encoding
used where the mappings between characters is dependent upon the code
page configured on the machine, typically by the manufacturer.
partial database synchronization: A mechanism for synchronizing a set of
database records on a particular replication partner.

Page | 140
 primary domain: A domain (identified by a security identifier (SID)) that the
server is joined to. For a domain controller (DC), the primary domain is that
of the domain itself.
primary domain controller (PDC): A domain controller (DC) designated to track
changes made to the accounts of all computers on a domain. It is the only
computer to receive these changes directly, and is specialized so as to ensure
consistency and to eliminate the potential for conflicting entries in the Active
Directory database. A domain has only one PDC.
principal: An authenticated entity that initiates a message or channel in a
distributed system.
privilege: The right of a user to perform system-related operations, such as
debugging the system. A user's authorization context specifies what
privileges are held by that user.
RC4: A variable key-length symmetric encryption algorithm. For more
information, see [SCHNEIER] section 17.1.
read-only domain controller (RODC): A domain controller (DC) that does not
accept originating updates. Additionally, an RODC does not perform
outbound replication. An RODC cannot be the primary domain controller
(PDC) for its domain.
relative identifier (RID): The last item in the series of SubAuthority values in a
security identifier (SID) [SIDD]. It distinguishes one account or group from all
other accounts and groups in the domain. No two accounts or groups in any
domain share the same RID.
remote procedure call (RPC): A communication protocol used primarily
between client and server. The term has three definitions that are often used
interchangeably: a runtime environment providing for communication
facilities between computers (the RPC runtime); a set of request-and-
response message exchanges between computers (the RPC exchange); and
the single message from an RPC exchange (the RPC message). For more
information, see [C706].

Page | 141
 RPC protocol sequence: A character string that represents a valid combination
of a remote procedure call (RPC) protocol, a network layer protocol, and a
transport layer protocol, as described in [C706] and [MS-RPCE].
RPC transport: The underlying network services used by the remote procedure
call (RPC) runtime for communications between network nodes. For more
information, see [C706] section 2.
secret key: A symmetric encryption key shared by two entities, such as
between a user and the domain controller (DC), with a long lifetime. A
password is a common example of a secret key. When used in a context that
implies Kerberos only, a principal's secret key.
secure channel: An authenticated remote procedure call (RPC) connection
between two machines in a domain with an established security context
used for signing and encrypting RPC packets.
Security Account Manager (SAM): A centrally managed service, such as Active
Directory Domain Services (AD DS), that enables a server to establish a trust
relationship with other authorized servers. The SAM also maintains
information about domains and security principals, and provides client-to-
server information by using several available standards for access control
lists (ACLs).
security account manager (SAM) built-in database: The part of the user
account database that contains account information (such as account names
and passwords) for accounts and groups that are pre-created at the database
installation.
security context: An abstract data structure that contains authorization
information for a particular security principal in the form of a
Token/Authorization Context (see [MS-DTYP] section 2.5.2). A server uses
the authorization information in a security context to check access to
requested resources. A security context also contains a key identifier that
associates mutually established cryptographic keys, along with other
information needed to perform secure communication with another security
principal.

Page | 142
 Security Descriptor Definition Language (SDDL): The format used to specify a
security descriptor as a text string, specified in [MS-DTYP] section 2.5.1.
security identifier (SID): An identifier for security principals that is used to
identify an account or a group. Conceptually, the SID is composed of an
account authority portion (typically a domain) and a smaller integer
representing an identity relative to the account authority, termed the
relative identifier (RID). The SID format is specified in [MS-DTYP] section
2.4.2; a string representation of SIDs is specified in [MS-DTYP] section 2.4.2
and [MS-AZOD] section 1.1.1.2.
security principal: A unique entity, also referred to as a principal, that can be
authenticated by Active Directory. It frequently corresponds to a human
user, but also can be a service that offers a resource to other security
principals. Other security principals might be a group, which is a set of
principals. Groups are supported by Active Directory.
security provider: A pluggable security module that is specified by the protocol
layer above the remote procedure call (RPC) layer, and will cause the RPC
layer to use this module to secure messages in a communication session with
the server. The security provider is sometimes referred to as an
authentication service. For more information, see [C706] and [MS-RPCE].
security support provider (SSP): A dynamic-link library (DLL) that implements
the Security Support Provider Interface (SSPI) by making one or more
security packages available to applications. Each security package provides
mappings between an application's SSPI function calls and an actual security
model's functions. Security packages support security protocols such as
Kerberos authentication and NTLM.
Security Support Provider Interface (SSPI): An API that allows connected
applications to call one of several security providers to establish
authenticated connections and to exchange data securely over those
connections. It is equivalent to Generic Security Services (GSS)-API, and the
two are on-the-wire compatible.
server: A computer on which the remote procedure call (RPC) server is
executing.

Page | 143
 server challenge (SC): A 64-bit nonce generated on the server side.
service principal name (SPN): The name a client uses to identify a service for
mutual authentication. For more information, see [MS-ADTS] section 2.2.21
(Service Principal Name) and [RFC1964] section 2.1.1.
session key: A relatively short-lived symmetric key (a cryptographic key
negotiated by the client and the server based on a shared secret). A session
key's lifespan is bounded by the session to which it is associated. A session
key has to be strong enough to withstand cryptanalysis for the lifespan of the
session.
shared secret: A piece of data that is known only to the security principal and
an authenticating authority; for example, a user and a domain controller. It is
used to prove the principal's identity. A password is a common example of a
shared secret. Also called a "secret key".
site: A collection of one or more well-connected (reliable and fast) TCP/IP
subnets. By defining sites (represented by site objects) an administrator can
optimize both Active Directory access and Active Directory replication with
respect to the physical network. When users log in, Active Directory clients
find domain controllers (DCs) that are in the same site as the user, or near
the same site if there is no DC in the site. See also Knowledge Consistency
Checker (KCC). For more information, see [MS-ADTS].
sub-authentication: Optional and additional authentication functionality,
usually provided by extending an authentication algorithm.
sub-authentication package: An optional component that provides additional
authentication functionality. If a sub-authentication package is installed, the
authentication package calls the sub-authentication package before
returning its authentication result. The request to verify by a sub-
authentication package is indicated by the ParameterControl field of the
LogonInformation parameter (see [MS-APDS] section 3.1.5.2.1, Verifying
Responses with Sub-Authentication Packages).
Time-To-Live (TTL): The time duration for which a Server Object is available.

Page | 144
 transitive trust: The state of two domains establishing trust through an
intermediary domain. For example, if domain A trusts domain B, and domain
B trusts domain C, then domain A can be configured to trust domain C
through transitive trust.
trust: To accept another authority's statements for the purposes of
authentication and authorization, especially in the case of a relationship
between two domains. If domain A trusts domain B, domain A accepts
domain B's authentication and authorization statements for principals
represented by security principal objects in domain B; for example, the list of
groups to which a particular user belongs. As a noun, a trust is the
relationship between two domains described in the previous sentence.
trusted domain: A domain that is trusted to make authentication decisions for
security principals in that domain.
trusted domain object (TDO): A collection of properties that define a trust
relationship with another domain, such as direction (outbound, inbound, or
both), trust attributes, name, and security identifier of the other domain. For
more information, see [MS-ADTS].
Unicode: A character encoding standard developed by the Unicode Consortium
that represents almost all of the written languages of the world. The Unicode
standard [UNICODE5.0.0/2007] provides three forms (UTF-8, UTF-16, and
UTF-32) and seven schemes (UTF-8, UTF-16, UTF-16 BE, UTF-16 LE, UTF-32,
UTF-32 LE, and UTF-32 BE).
Unicode string: A Unicode 8-bit string is an ordered sequence of 8-bit units, a
Unicode 16-bit string is an ordered sequence of 16-bit code units, and a
Unicode 32-bit string is an ordered sequence of 32-bit code units. In some
cases, it could be acceptable not to terminate with a terminating null
character. Unless otherwise specified, all Unicode strings follow the UTF-
16LE encoding scheme with no Byte Order Mark (BOM).
universally unique identifier (UUID): A 128-bit value. UUIDs can be used for
multiple purposes, from tagging objects with an extremely short lifetime, to
reliably identifying very persistent objects in cross-process communication
such as client and server interfaces, manager entry-point vectors, and RPC

Page | 145
 objects. UUIDs are highly likely to be unique. UUIDs are also known as
globally unique identifiers (GUIDs) and these terms are used
interchangeably in the Microsoft protocol technical documents (TDs).
Interchanging the usage of these terms does not imply or require a specific
algorithm or mechanism to generate the UUID. Specifically, the use of this
term does not imply or require that the algorithms described in [RFC4122] or
[C706] must be used for generating the UUID.
user principal name (UPN): A user account name (sometimes referred to as the
user logon name) and a domain name that identifies the domain in which the
user account is located. This is the standard usage for logging on to a
Windows domain. The format is: [email protected] (in the form of an
email address). In Active Directory, the userPrincipalName attribute of the
account object, as described in [MS-ADTS].
Windows Time Service (W32Time): A service that supports time
synchronization against network and hardware time sources. For more
information, see [WTSREF] and [MS-SNTP].
writability: The abstract feature capability representing the ability of a domain
controller (DC) to accept modifications and issue originating updates, with
respect to a given naming context (NC) replica.

10 References
Links to a document in the Microsoft Open Specifications library point to the
correct section in the most recently published version of the referenced
document. However, because individual documents in the library are not updated
at the same time, the section numbers in the documents may not match. You can
confirm the correct section numbering by checking the Errata.
[LDAP] Microsoft Corporation, "About Lightweight Directory Access Protocol",
http://msdn.microsoft.com/en-us/library/aa366075.aspx

[MS-ADA1] Microsoft Corporation, "Active Directory Schema Attributes A-L".

[MS-ADA2] Microsoft Corporation, "Active Directory Schema Attributes M".

Page | 146
[MS-ADA3] Microsoft Corporation, "Active Directory Schema Attributes N-Z".

[MS-ADCAP] Microsoft Corporation, "Active Directory Web Services: Custom

Action Protocol".

[MS-ADDM] Microsoft Corporation, "Active Directory Web Services: Data Model

and Common Elements".

[MS-ADLS] Microsoft Corporation, "Active Directory Lightweight Directory

Services Schema".

[MS-ADSC] Microsoft Corporation, "Active Directory Schema Classes".

[MS-ADTS] Microsoft Corporation, "Active Directory Technical Specification".

[MS-AUTHSOD] Microsoft Corporation, "Authentication Services Protocols

Overview".

[MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS) Protocol".

[MS-DRSR] Microsoft Corporation, "Directory Replication Service (DRS) Remote

Protocol".

[MS-DSSP] Microsoft Corporation, "Directory Services Setup Remote Protocol".

[MS-DTYP] Microsoft Corporation, "Windows Data Types".

[MS-GPOD] Microsoft Corporation, "Group Policy Protocols Overview".

[MS-LSAD] Microsoft Corporation, "Local Security Authority (Domain Policy)

Remote Protocol".

[MS-LSAT] Microsoft Corporation, "Local Security Authority (Translation Methods)

Remote Protocol".

[MS-MAIL] Microsoft Corporation, "Remote Mailslot Protocol".

[MS-NAPOD] Microsoft Corporation, "Network Access Protection Protocols

Overview".

[MS-NRPC] Microsoft Corporation, "Netlogon Remote Protocol".

Page | 147
[MS-RPCE] Microsoft Corporation, "Remote Procedure Call Protocol Extensions".

[MS-SAMR] Microsoft Corporation, "Security Account Manager (SAM) Remote

Protocol (Client-to-Server)".

[MS-SAMS] Microsoft Corporation, "Security Account Manager (SAM) Remote

Protocol (Server-to-Server)".

[MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Protocol

Versions 2 and 3".

[MS-SMB] Microsoft Corporation, "Server Message Block (SMB) Protocol".

[MS-SNTP] Microsoft Corporation, "Network Time Protocol (NTP) Authentication

Extensions".

[MS-SRPL] Microsoft Corporation, "Directory Replication Service (DRS) Protocol

Extensions for SMTP".

[MS-WPO] Microsoft Corporation, "Windows Protocols Overview".

[MS-WSDS] Microsoft Corporation, "WS-Enumeration: Directory Services Protocol

Extensions".

[MS-WSPELD] Microsoft Corporation, "WS-Transfer and WS-Enumeration Protocol

Extension for Lightweight Directory Access Protocol v3 Controls".

[MS-WSTIM] Microsoft Corporation, "WS-Transfer: Identity Management

Operations for Directory Access Extensions".

[MSDN-DomainTrees] Microsoft Corporation, "Domain Trees",

http://msdn.microsoft.com/en-
us/library/windows/desktop/ms675914(v=vs.85).aspx

[RFC1001] Network Working Group, "Protocol Standard for a NetBIOS Service on

a TCP/UDP Transport: Concepts and Methods", RFC 1001, March 1987,
http://www.ietf.org/rfc/rfc1001.txt

[RFC1002] Network Working Group, "Protocol Standard for a NetBIOS Service on

a TCP/UDP Transport: Detailed Specifications", STD 19, RFC 1002, March 1987,
http://www.rfc-editor.org/rfc/rfc1002.txt

Page | 148
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13,
RFC 1034, November 1987, http://www.ietf.org/rfc/rfc1034.txt

[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification",

STD 13, RFC 1035, November 1987, http://www.ietf.org/rfc/rfc1035.txt

[RFC1305] Mills, D. L., "Network Time Protocol (Version 3) Specification,

Implementation and Analysis", RFC 1305, March 1992,
http://www.ietf.org/rfc/rfc1305.txt

[RFC1769] Mills, D., "Simple Network Time Protocol (SNTP)", RFC 1769, March
1995, http://www.ietf.org/rfc/rfc1769.txt

[RFC1777] Yeong, W., Howes, T., and Kille, S., "Lightweight Directory Access
Protocol", RFC 1777, March 1995, http://www.ietf.org/rfc/rfc1777.txt

[RFC2052] Gulbrandsen, A. and Vixie, P., "A DNS RR for specifying the location of
services (DNS SRV)", RFC 2052, October 1996, http://www.ietf.org/rfc/rfc2052.txt

[RFC2136] Thomson, S., Rekhter Y. and Bound, J., "Dynamic Updates in the
Domain Name System (DNS UPDATE)", RFC 2136, April 1997,
http://www.ietf.org/rfc/rfc2136.txt

[RFC2246] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", RFC 2246,
January 1999, https://datatracker.ietf.org/doc/rfc2246/

[RFC2247] Kille, S., Wahl, M., Grimstad, A., et al., "Using Domains in LDAP/X.500
Distinguished Names", RFC 2247, January 1998,
http://www.ietf.org/rfc/rfc2247.txt

[RFC2251] Wahl, M., Howes, T., and Kille, S., "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997, http://www.ietf.org/rfc/rfc2251.txt

[RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, S., "Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997,
http://www.ietf.org/rfc/rfc2252.txt

[RFC2782] Gulbrandsen, A., Vixie, P., and Esibov, L., "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2782, February 2000,
http://www.ietf.org/rfc/rfc2782.txt

Page | 149
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001,
http://www.ietf.org/rfc/rfc2821.txt

[RFC3244] Swift, M., Trostle, J., and Brezak, J., "Microsoft Windows 2000 Kerberos
Change Password and Set Password Protocols", RFC 3244, February 2002,
http://www.ietf.org/rfc/rfc3244.txt

[RFC3377] Hodges, J. and Morgan, R., "Lightweight Directory Access Protocol (v3):
Technical Specification", RFC 3377, September 2002,
http://www.ietf.org/rfc/rfc3377.txt

[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and Souissi, M., "DNS Extensions
to Support IP version 6", RFC 3596, October 2003,
http://www.ietf.org/rfc/rfc3596.txt

[RFC3629] Yergeau, F., "UTF-8, A Transformation Format of ISO 10646", STD 63,
RFC 3629, November 2003, http://www.ietf.org/rfc/rfc3629.txt

[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., and Hall, R.,
"Generic Security Service Algorithm for Secret Key Transaction Authentication for
DNS (GSS-TSIG)", RFC 3645, October 2003, http://www.ietf.org/rfc/rfc3645.txt

[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5",
RFC 3961, February 2005, http://www.ietf.org/rfc/rfc3961.txt

[RFC4120] Neuman, C., Yu, T., Hartman, S., and Raeburn, K., "The Kerberos
Network Authentication Service (V5)", RFC 4120, July 2005, https://www.rfc-
editor.org/rfc/rfc4120.txt

[RFC4556] Zhu, L., and Tung, B., "Public Key Cryptography for Initial
Authentication in Kerberos", RFC 4556, June 2006,
http://www.ietf.org/rfc/rfc4556.txt

[WSAddressing] Box, D., et al., "Web Services Addressing (WS-Addressing)",

August 2004, http://www.w3.org/Submission/ws-addressing/

[WSENUM] Alexander, J., Box, D., Cabrera, L.F., et al., "Web Services Enumeration
(WS-Enumeration)", March 2006, http://www.w3.org/Submission/2006/SUBM-
WS-Enumeration-20060315/

Page | 150
[WXFR] Alexander, J., Box, D., Cabrera, L.F., et al., "Web Services Transfer (WS-
Transfer)", September 2006, http://www.w3.org/Submission/2006/SUBM-WS-
Transfer-20060927/

11 Functional Overview
The Active Directory protocols provide a centralized directory service with the
ability to integrate with the Windows domain security model. They are used for
the following purposes:
▪ For storage of data that is a good fit to the data model used by LDAP [LDAP]
and the other Active Directory Services protocols, namely, hierarchically
organized objects that consist of a collection of attributes.
▪ For storage of relatively static data that is expected to be read at a significantly
higher rate than it is updated.
▪ For use in scenarios where domain integration capabilities are required. When
deploying the Active Directory system to provide these capabilities, the AD DS
mode of operation is used.
▪ For use in scenarios where other systems that have a dependency on the
Active Directory system, such as Group Policy or Message Queuing, are to be
deployed. When deploying the Active Directory system in support of these
other systems, make sure to choose the appropriate mode of operation
(typically, AD DS) for the Active Directory system.
▪ As a directory service for use by applications, such as web portals, that store
information about their registered users. In scenarios where domain
integration capabilities are not required, the AD LDS mode of operation can be
a particularly good choice because it does not require support for protocols
such as [MS-SAMR] (SAMR), [MS-LSAD] (LSAD), and [MS-LSAT] (LSAT) that are
not used by the client application in these scenarios.
▪ For replication of objects. Active Directory is a distributed directory service
that stores objects that represent real-world entities such as users, computers,
services, and network resources. Objects in the directory are distributed
among all domain controllers in a forest. Directory replication protocols [MS-
DRSR] (DRSR), [MS-SRPL] (SRPL), [MS-SAMS] (SAMS) are used to replicate
directory objects between different domain controllers.

Page | 151
The Active Directory protocols are not used for the following purposes:
▪ As a replacement for a file system. Directory services such as the Active
Directory system are not intended for storing highly volatile data, and
emphasize read performance over write performance. They are also not
designed for storing large amounts of unstructured data, such as storing a
multimegabyte value in a single attribute of a directory object.
▪ As a means of passing transient messages between clients. The Active
Directory system is not intended to be a message-passing system. Applications
that require such a system are encouraged to investigate the use of a system
that is designed for that purpose.
There is no interoperability requirement that an implementation of the Active
Directory system support both the AD DS and AD LDS modes of operation.
Implementers are free to implement either or both modes of operation,
depending on their requirements for and intended use of the Active Directory
system.
12 Components and Capabilities
From an abstract point of view, the functionality provided by the Active Directory
protocols can be represented by the components shown in the following diagram.

Page | 152
Figure 3: Active Directory system components
13 Relevant Standards
The following standards are relevant to the Active Directory system.
Lightweight Directory Access Protocol (LDAP), as specified in [RFC2247]: The
Active Directory system conforms to LDAP version 3, as specified in [RFC3377].
Details of Active Directory's conformance are specified in [MS-ADTS] section
3.1.1.3.1, LDAP Conformance. The Active Directory system also supports LDAP
version 2 [RFC1777], although clients are encouraged to use LDAP version 3.
WS-Enumeration: The Active Directory system uses the protocol [WSENUM] (WS-
Enumeration) to query for directory objects. The system extends the standard
protocol with the extensions that are defined in [MS-WSDS] and [MS-WSPELD]. In
the Active Directory system, the WS-Enumeration protocol operates over the XML
data model described in [MS-ADDM].

Page | 153
WS-Transfer: The Active Directory system uses the protocol [WXFR] (WS-Transfer)
to create, modify, remove, and read directory objects. The system extends the
standard protocol with the extensions defined in [MS-WSTIM] and [MS-WSPELD].
As with WS-Enumeration, the WS-Transfer protocol operates over the XML data
model described in [MS-ADDM] in the Active Directory system.
This document uses and extends the following standards.
Encryption and Checksum Specifications for Kerberos 5, as specified in
[RFC3961]. This standard is used for encryption and checksum mechanisms.
Kerberos Authentication Protocol, as specified in [RFC4120]. This standard is
used for authentication.
Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), as
specified in [RFC4556]. This standard is used for initial authentication in Kerberos.
Simple Network Time Protocol (SNTP), as specified in [RFC1769]. This standard is
an adaptation of the Network Time Protocol (NTP) that is used to synchronize
computer clocks in the Internet. SNTP can be used when the ultimate
performance of the full NTP implementation described in [RFC1305] is not
required or justified.
Domain Names - Concepts and Facilities, as specified in [RFC1034]. This standard
is used for Domain Name System (DNS) and domain naming concepts.
Domain Names - Implementation and Specification, as specified in [RFC1035].
This standard is used for DNS and provides details of the domain system and
protocol.
DNS Extensions to Support IP Version 6, as specified in [RFC3596]. This standard
is used for DNS to support hosts running IP version 6 (IPv6).
UTF-8, A Transformation Format of ISO 10646, as specified in [RFC3629]. This
standard is used for string data type specification.
Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and
Methods, as specified in [RFC1001]. This standard is used for NetBIOS services.

Page | 154
Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed
Specifications, as specified in [RFC1002]. This standard is used for NetBIOS
services.
14 Protocol Relationships

Figure 4: Active Directory protocol grouping

As shown in the preceding diagram, the member protocols that make up the
Active Directory Services Protocol Groups can be divided into five functional
groups. Each group accomplishes an interrelated set of tasks. A client typically
uses protocols in the same group in conjunction with each other. The groups are
as follows:

Page | 155
▪ The core group contains protocols that are supported by all directory servers
in the Active Directory system, whether they run in AD DS or AD LDS mode.
This group includes LDAP, which is the primary protocol that is used to read
and write objects in the directory tree. The [MS-DSSP] (DSSP) protocol does
not perform operations against the directory tree, but is included in this group
because it is also present on all directory servers in the Active Directory
Services Protocols.
▪ The SAM group includes SAMR and SAMS. SAMR is used to perform account
maintenance and operates on the same directory tree as the core group of
protocols, but it provides access to only a subset of the objects in that tree,
and further, provides access to only a subset of the attributes on those
objects. SAMR is supported only when operating in AD DS mode. SAMS is used
to perform account maintenance and time-critical database changes between
Active Directory servers that are in the same domain.
▪ The LSA group contains the LSAD and LSAT protocols. Both protocols are
serviced by the same RPC interface and endpoint ([MS-LSAD] section 1.8,
Vendor-Extensible Fields, and [MS-LSAT] section 1.8, Vendor-Extensible Fields).
▪ The Web Services group consists of the WS-Transfer, WS-Enumeration, and
ADCAP protocols along with the [MS-WSDS] (WSDS), and [MS-WSPELD]
(WSPELD) protocol extensions. This protocol group is only supported on some
versions of the Active Directory Services. Much like the core group, these
protocols permit clients to read and write directory objects in the directory
tree, and to perform selected tasks against the tree. Unlike the core group, the
protocols in this group are based on SOAP rather than remote procedure call
(RPC) or block-structured transports.
▪ The Directory Replication group contains the DRSR and SRPL protocols. DRSR is
an RPC protocol that is used for management of replication and management
of data in Active Directory. SRPL is the extension to the DRS protocol for
transport over the Simple Mail Transfer Protocol (SMTP).
The following diagram shows the relationship among the protocols of the Active
Directory system.

Page | 156
Figure 5: Protocol relationships
15 Protocol Summary
The following tables provide a comprehensive list of the member protocols of the
Active Directory system. Section 2.8 provides details about which protocols or
protocol subsets are supported in the different modes of operation.
The protocols in the following table enable the core functionality of the Active
Directory system, including access to the directory tree, replication, name
translation, determination of group membership, and domain controller status.
These protocols are supported by all directory servers in the Active Directory

Page | 157
system, whether running in Active Directory Domain Services (AD DS) or Active
Directory Lightweight Directory Services (AD LDS) mode.

Short
Protocol name Description name
Active Directory Active Directory is a server for LDAP. [MS- [MS-ADTS]
extensions for ADTS] section 3.1.1.3 specifies the section
Lightweight extensions and variations of LDAP that are 3.1.1.3.1
Directory Access supported by Active Directory.
Protocol (LDAP), Note In a reference to LDAP without a
versions 2 and 3 version number, LDAP refers to both
versions 2 and 3.
Directory The Directory Replication Service (DRS) [MS-
Replication Service Remote Protocol. This protocol includes DRSR]
Remote Protocol the drsuapi and dsaop RPC interfaces.
(drsuapi) - Methods on these interfaces provide
Replication replication of directory information among
the domain controllers of an AD DS
domain. Methods on these interfaces also
provide a variety of functionality to clients,
such as converting names between
formats and retrieving information about
AD DS domain controllers.
This protocol also supports DC cloning
operations.<2>
SMTP Replication The Directory Replication Service (DRS) [MS-SRPL]
Protocol Extensions Protocol Extensions for SMTP. This
protocol provides Simple Mail Transfer
Protocol (SMTP) transport of replication
information as an alternative to RPC.
Directory Services The Directory Services Setup Remote [MS-DSSP]
Setup Remote Protocol, as defined in [MS-DSSP]. This
Protocol protocol can be used to retrieve
information about the state of a computer
in a domain or a non-domain workgroup.

Page | 158
The protocols in the following table enable account maintenance when the Active
Directory system is operating in AD DS mode. This includes the creation,
modification, retrieval, and deletion of users and groups.

Short
Protocol name Description name
Security Account The Security Account Manager (SAM) Remote [MS-
Manager (SAM) Protocol. Clients can use this protocol to perform SAMR]
Remote Protocol account maintenance, for example, to create and
(Client-to-Server) delete accounts. The capabilities of this protocol
are a subset of the capabilities of LDAP.
Security Account The Security Account Manager (SAM) Remote [MS-
Manager (SAM) Protocol. Domain controllers (DCs) use this SAMS]
Remote Protocol protocol to forward time-critical database
(Server-to- changes to the primary domain controller (PDC),
Server) and to forward time-critical database changes
from a read-only domain controller (RODC) to a
writable NC replica within the same domain
outside the normal replication protocol. This
protocol is used only between Active Directory
servers in the same domain.
The protocols in the following table allow clients to retrieve security policy
information and translate security identifiers (SIDs) that identity security
principals, such as users, to human-readable names.

Short
Protocol name Description name
Local Security The Local Security Authority (Domain Policy) [MS-
Authority (Domain Remote Protocol. Clients can use this protocol LSAD]
Policy) Remote to retrieve security policy information.
Protocol
Local Security The Local Security Authority (Translation [MS-
Authority Methods) Remote Protocol. Clients can use LSAT]
(Translation this protocol to translate security identifiers
Methods) Remote (SIDs) of security principals to human-
Protocol readable names, and vice versa.

Page | 159
The protocols in the following table enable Web services for the Active Directory
system that allow access to the directory tree and the management of Active
Directory account information and topologies.

Short
Protocol name Description name
Active Directory Web The Active Directory Web Services [MS-
Services Custom Custom Action Protocol. It is a SOAP- ADCAP]
Action Protocol based Web Services protocol for
managing account and topology
information.
WS-Transfer: Identity WS-Transfer: Identity Management [MS-
Management Operations for Directory Access WSTIM]
Operations for Extensions. This is a set of protocol
Directory Access extensions to WS-Transfer that allows
Extensions directory objects to be manipulated at
a finer level of granularity than
unextended WS-Transfer.
WS-Enumeration: Web The WS-Enumeration protocol. This [WSENUM]
Services Enumeration protocol allows directory objects to be
queried by using a SOAP-based Web
Services protocol.
WS-Transfer: Web The WS-Transfer protocol. This protocol [WXFR]
Services Transfer allows directory objects to be created,
removed, modified, and read by using a
SOAP-based Web Services protocol.
WS-Enumeration: The WS-Enumeration Directory Services [MS-WSDS]
Directory Services Protocol Extensions. This is a set of
Protocol Extensions protocol extensions to WS-Enumeration
that, among other things, allows a client
to request that query results be sorted.
It also specifies a query language that is
used by clients to specify which
directory objects are to be returned
from the query.

Page | 160
 Short
Protocol name Description name
WS-Transfer and WS- WS-Transfer and WS-Enumeration [MS-
Enumeration Protocol Protocol Extension for Lightweight WSPELD]
Extension for Directory Access Protocol v3 Controls.
Lightweight Directory This is a protocol extension to WS-
Access Protocol v3 Transfer and WS-Enumeration. It
Controls permits LDAP extended controls to be
attached to operations in the protocols
that it extends.
Active Directory Web The Active Directory Web Services: Data [MS-
Services: Data Model Model and Common Elements. ADDM]
and Common Although not a protocol itself, this
Elements defines an XML data model that is
shared by the other Web Service
protocols and protocol extensions, as
well as common protocol elements
referenced by the other documents.

16 Environment
Because domain interactions are distributed among many computers for
different, but related purposes, enumerating the dependencies of the Active
Directory protocols is complex. The following rough diagram serves as a very
high-level illustration of how the dependencies among components can be
visualized.

Page | 161
Figure 6: Dependencies among domain components
In this diagram, the dependencies of the system are symmetrical between the
domain client and the domain controller server. Both the domain client and the
domain controller server rely upon infrastructure servers, such as DNS, and
leverage those servers for locating each other (rendezvous). During this
rendezvous process, the domain controller server publishes its name and the
domain client locates the domain controller server through DNS. The details of
this rendezvous process are described in section 2.7.7.3.1.
In addition to service location, the rendezvous process between a domain client
and a domain controller server relies upon authentication and authorization
information. The domain controller server, for example, leverages the
authorization information that it contains for controlling access to its resources.
For more detailed information about authentication and authorization, see [MS-
AUTHSOD] and related documents.

17 Active Directory Protocols Dependencies

This section describes the dependencies that the Active Directory protocols have
on other entities. The Active Directory protocols require a durable storage system
to maintain the state of the directory and meet the transactional guarantees
specified in [MS-ADTS] section 3.1.1.5.1.4, Transactional Semantics. This storage
system has to provide a means of securing the contents of the storage system
from unauthorized access.
The Active Directory protocols also require a networking system that clients can
use to send requests to the directory server and to receive responses. This

Page | 162
networking system has to support the Transmission Control Protocol (TCP), User
Datagram Protocol (UDP), and Server Message Block (SMB) transports. This
networking system has to provide an accessible name resolution service through
a DNS service. The DNS service has to be capable of storing and resolving service
(SRV) resource records [RFC2782], CNAME and A resource records [RFC1034],
and AAAA resource records [RFC3596]. It is recommended that an
implementation of the Active Directory system uses dynamic updates ([RFC2136]
and [RFC3645]) to update DNS with the records, as described in [MS-ADTS]
section 6.3.2, DNS Record Registrations, but any alternative method that creates
the DNS records described there is permissible.<3> DNS can be used by clients of
the Active Directory system in order to locate directory servers by using the
algorithms described in [MS-ADTS] section 6.3, Publishing and Locating a Domain
Controller.
Several of the Active Directory protocols are RPC-based and therefore depend on
the availability of an RPC runtime that implements an RPC mechanism as
described in [MS-RPCE].
A system of domain interactions forms the framework that other systems
leverage in their environments. As such, this system requires comparatively little
in terms of services available for use because its purpose is to create a useful
environment for other scenarios. Services that the Active Directory protocols
require from their environment include the following:
▪ Network Infrastructure. This system of domain interactions requires that a
viable network system is available. This includes a networked environment
that supports TCP/IP and UDP/IP, as well as a name resolution system that is
available for use by both the domain controller server and domain members.
The name resolution system has to support DNS form if the domain is to
support Active Directory-style domain functionality, and NetBIOS form if the
domain is to support Windows NT 4.0-style domain functionality.
▪ Coexistence. Any given domain on a network has to be uniquely named. There
is no architectural limit to the number of domains that are possible on a
network.
Even at this relatively high level, the system of domain interactions is a complex
aggregation.

Page | 163
18 Dependencies on Active Directory Protocols
This section lists entities that depend on the interfaces provided by the Active
Directory protocols, as well as other entities that the Active Directory protocols
depend on. Other entities take dependencies on the Active Directory protocols,
and in particular on AD DS, not only by making use of the Active Directory
protocols' external interfaces, but also by sharing state with this system; that is,
there are overlapping abstract data models.
The Active Directory protocols depend on the Windows Authentication Services
[MS-AUTHSOD] to authenticate clients that are accessing the system. The system
controls access based on the identity of the client.
The following components have dependencies on the protocol interfaces
provided by the Active Directory system. All of these components apply to Active
Directory that is operating as AD DS. Note that while these components depend
on the Active Directory system, the Active Directory system does not in turn
depend on them. In other words, any of these components can be omitted from
the environment, and the Active Directory system will continue to function.
The Active Directory protocols influence the behavior of the following
components:
Print Services: The Print Services service can optionally publish information about
shared printers in the directory. Domain-joined clients discover shared
printers that are available to them by querying the directory for this
information.
Message Queuing: The Message Queuing service uses the directory service to
store information such as queue and system metadata.
Network Access Protection: The Network Access Protection (NAP) service [MS-
NAPOD] determines how machines can be examined for access to a network.
The machines need to be members of a domain to authenticate to the NAP
servers.
Group Policy: The Group Policy service [MS-GPOD] defines how domain clients
can retrieve group policy information from the domain controller, which is
based on the group memberships of a domain account and a domain
account's location in the LDAP directory structure.

Page | 164
Windows Server Update: This component specifies how different machines in a
domain can have different update policies for patch management, which relies
on domain interactions to specify the domain authorization information.
File Services: This component specifies how file servers present a unified view of
files and other resources, and rely upon [MS-AUTHSOD] and domain
interactions for authentication when the file server is part of a domain.
Infrastructure Service: The Infrastructure Service includes services such as name
resolution (DNS, WINS) and network maintenance services (routers). The
directory service uses such services to make domain controllers available to
their clients.
Authentication System: The authentication system [MS-AUTHSOD] defines how
other protocols take advantage of authentication protocols such as NTLM and
Kerberos to secure their communications, and also defines the authentication
services that support the client-to-server communication. The authentication
system depends on domain interactions to specify how those protocols are
used in a domain context to authenticate clients to servers when both are
members of a domain.
Several protocol groups leverage the domain controller as the source of identity
and authorization information for the domain. These include:
▪ Browser Services, which define how the browser service leverages the
directory service to browse and locate the shared resources in the domain
based on information that is associated with the accounts in the domain.
▪ Certificate Services, which specifies how the certificate authority leverages
the domain infrastructure to manage certificate distribution and enrollment,
and makes authorization decisions based on information that is associated
with the accounts in the domain.
▪ Rights Management, which determines how content can be protected against
offline access based on authorization information from the directory.
19 Assumptions and Preconditions
The following assumptions and preconditions have to be satisfied for the Active
Directory system to start to operate successfully:

Page | 165
▪ For AD DS, the server is configured (that is, "promoted") to act as an AD DS
domain controller. This is accomplished by having the server host the Active
Directory service in AD DS mode. When hosting an AD DS directory service,
the directory server registers (if not already registered) DNS and NetBIOS
records, as described in [MS-ADTS] sections 6.3.2 and 6.3.4, respectively, to
enable clients to locate the directory server. If an AD LDS directory service is
hosted on a directory server that is joined to an AD DS domain, the directory
server publishes itself by creating an object in AD DS, as described in [MS-
ADTS] section 6.3.8.
▪ When operating as AD DS, after the server has initialized the protocols that are
listed in section 2.4 and is prepared to process incoming requests for those
protocols, the directory server begins responding to LDAP and mailslot ping
requests in the manner described in [MS-ADTS] sections 6.3.3 and 6.3.5,
respectively.
▪ For AD DS, member clients assume basic network connectivity and the
availability of basic network infrastructure services, such as DNS. Prior to being
associated with a domain, there are no other notable preconditions for
member clients. After a client has been associated with a domain, it is under
the assumption that the domain controller also has an entry in its directory
that corresponds to the client. If this assumption is proven wrong, the system
(from the client's perspective) becomes unusable until the association is
reestablished.
▪ For AD LDS, the server is configured to host the Active Directory service that
operates in AD LDS mode.
▪ A network that provides transport for communications between the directory
server and its clients is available. As described in section 2.5, this network
supplies access to DNS and supports the TCP, UDP, and SMB transports.
▪ The transport protocol for that network is available and configured; for
example, the TCP transport is configured with a valid IP address.
▪ Support for all authentication mechanisms that are indicated in the technical
documents of the Active Directory system's member protocols are available.
▪ The durable storage system that is used to store the Active Directory system's
state is available to the Active Directory system.

Page | 166
▪ The directory contains at least the required directory objects and naming
contexts described in [MS-ADTS] section 6.1.
▪ The directory's schema contains at least the attribute and class schema
definitions described in [MS-ADA1], [MS-ADA2], [MS-ADA3], and [MS-ADSC]
(for AD DS) or [MS-ADLS] (for AD LDS) in order to be compliant with the
protocol described in [MS-ADTS]. However, Active Directory currently does not
make use of all the attributes and classes that are defined in the schema
definitions.
Upon startup, the Active Directory system initializes all of the protocols that are
listed in section 2.4 as described in the protocol documents for each listed
protocol and also begins servicing requests that are coming in on those protocols'
interfaces. There is no requirement that the protocols be initialized in a particular
sequence.
Because member clients treat all domain controller instances as equivalent, each
domain controller that operates as AD DS needs to ensure that it is synchronized
with its peer AD DS domain controllers, if any are supported in the
implementation, through implementation-specific means such as directory
replication.
20 Use Cases
The following use cases span the functionality of the Active Directory system.

Use case category Use cases

Object Create Directory Object - Client
Management Application (section 2.7.1.1)
Search for Directory Object - Client
Application (section 2.7.1.2)
Modify Directory Object - Client
Application (section 2.7.1.3)
Delete Directory Object - Client
Application (section 2.7.1.4)
Create Organizational Unit - Client
Application (section 2.7.1.5)
Cross-Domain Move - Client Application (section 2.7.1.6)

Page | 167
 Use case category Use cases
Identity Lifecycle Create a New Account - Client Application (section 2.7.2.1)
Management Reset an Existing Account's Password - Client
Application (section 2.7.2.2)
Change an Existing Account's Password (PDC) - Client
Application (section 2.7.2.3)
Change an Existing Account's Password (DC) - Client
Application (section 2.7.2.4)
Change User Account Password Against an RODC - Client
Application (section 2.7.2.5)
User Logon to Domain Services by using an RODC and
Updating the User LastLogonTimeStamp - Client
Application (section 2.7.2.6)
Query an Account's Group Membership - Client
Application (section 2.7.2.7)
Delete an Account - Client Application (section 2.7.2.8)
Create a Security Group - Client
Application (section 2.7.2.9)
Modify Group Member List - Client
Application (section 2.7.2.10)
Query for Members of a Group - Client
Application (section 2.7.2.11)
Schema Add a New Class to the Schema - Client
Management Application (section 2.7.3.1)
Add a New Attribute to the Schema - Client
Application (section 2.7.3.2)
Add an Attribute to a Class - Client
Application (section 2.7.3.3)
Name Translation Convert a SID to/from a Human-Readable Format - Client
Application (section 2.7.4.1)
Directory Replicate Changes within a Domain - Domain
Replication Controller (section 2.7.5.1)
Replicate Changes to a GC or a Partial Replica by using RPC
- Domain Controller (section 2.7.5.2)
Transferring a FSMO Role - Domain
Controller (section 2.7.5.3)

Page | 168
 Use case category Use cases
Trust Create a Trust - Domain Controller (section 2.7.6.1)
Management
Domain Services Join a Domain with a New Account - Domain
Client (section 2.7.7.1)
Unjoin from the Domain - Domain Client (section 2.7.7.2)
Locate a Domain Controller - Domain
Client (section 2.7.7.3.1)
Detailed descriptions for these use cases are provided in subsequent sections.

21 Object Management
The use cases in this category reflect the most fundamental of operations in the
Active Directory system, namely, the storage and retrieval of directory objects.
Client applications, which, in a general sense, are used to access and manipulate
data that is stored in the Active Directory system, perform object management
operations to store data in the directory service for their own use or to configure
and manipulate other systems that rely on data that is stored in the directory
service.
The lifecycle of a directory object begins with its creation. After the directory
object is created, clients can retrieve it by issuing a search to the directory
service. Clients can also modify attributes of the directory object. When an object
is no longer required, it can be deleted.
The following use case diagram shows the use cases for object management.

Page | 169
Figure 7: Use cases for object management

22 Create a Directory Object - Client Application

In this use case, an administrator wants to create a new directory object on an
existing application naming context (NC) to store information that could be used
by applications on the client. To achieve this, the administrator launches the
client application to interact with the Active Directory system. The client
application establishes a connection to the Active Directory system. The
administrator creates the directory object by using the client application.

Page | 170
Goal
Create a directory object on an application NC to store application-related data.
Context of Use
An administrator wants to create a new directory object in an existing application
NC.

Figure 8: Use case diagram for creating a directory object on an application NC

Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to create the object,
and relays the response to the administrator.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity so that the Active Directory system
can make access-control decisions.

Page | 171
▪ Directory server
The directory server is the supporting actor that receives the creation request
and creates the application directory object.
Stakeholders
▪ Administrator
The administrator is the one who initiates operations such as create, search,
modify, and delete on the application directory object. The administrator
primarily wants to receive information that the operations are successfully
completed or receive an error message if they failed.
▪ Applications
Applications on the client are the entities that store information in the
application directory for later retrieval and use in various operations.
▪ Application NC
The application NC is the naming context of the directory that contains the
application-specific directory objects.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has access to a directory server to which it can establish
a connection, if it is not already connected, and send the request.
▪ There already exists an object class in the Active Directory system schema that
corresponds to the directory object to be created under the application NC.
For a detailed description of schema extensions, see section 2.7.3.
▪ The Active Directory system hosts an application NC on which the client
application is configured to store its application data.
Main Success Scenario
1. Trigger: To initiate this activity, the administrator provides the name of the
directory object along with credentials as input to the client application. The
administrator then invokes the operation that creates the application directory
object.

Page | 172
2. The client application establishes a connection to the directory server.
Windows Authentication Services authenticates the client application by using
the supplied credentials ([MS-AUTHSOD] section 2).
3. The client application sends a request to the directory server to create a new
application directory object and specifies details for the new object.
4. The directory server verifies that the credentials that are supplied through the
client application have the necessary access-control rights to complete the
operation ([MS-ADTS] section 5.1.3).
5. The directory server creates an object under the application NC with the name
and other attributes that the client application supplies. The directory object is
also populated with attributes that are mandated by the server's processing
rules and constraints ([MS-ADTS] sections 3.1.1.5.1 and 3.1.1.5.2).
6. The directory server sends a response to the client application that the new
application directory object has been successfully created.
Postcondition
The new application directory object is created and ready for use.
Extensions
▪ If the credentials that are passed through the client application have
insufficient access-control rights to create the new application directory
object:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application that it
supplied credentials with insufficient access-control rights to create the new
application directory object.
▪ If the relative distinguished name (RDN) value (that is, the name of the
directory object to be created) supplied by the administrator is not unique
under the same parent container, as required by [MS-ADTS] section
3.1.1.5.2.2:
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client application that indicates
that the provided object name already exists.

Page | 173
▪ If the directory object creation request does not contain all the mandatory
attributes, as required in [MS-ADTS] section 3.1.1.2.4.5:
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client application that indicates
that the missing attribute is required in the request.
▪ If the directory object to be created under the application NC by the client
application is a security principal in AD DS:
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client application that indicates
that a security principal can be created only in a domain NC.

23 Search for a Directory Object - Client Application

In this use case, an administrator or user wants to inspect the attribute values for
a given set of directory objects in order to make informed decisions about the
Active Directory system. To achieve this task, the administrator or user launches
the client application to interact with the Active Directory system. The client
application establishes a connection to the Active Directory system. The
administrator or user then performs a search on the directory tree.
Goal
Retrieve information from one or more directory objects in the Active Directory
system.
Context of Use
An administrator or user wants to search for and retrieve the attribute values of
the existing directory object.

Page | 174
Figure 9: Use case diagram for searching for a directory object
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits search requests to the directory
on behalf of the user, and returns the results to the user.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's or user's identity. This is done so that access
control decisions can be made by the Active Directory system.
▪ Directory server
The directory server is the supporting actor that receives the search request
and performs the search of the application directory.
Stakeholders
▪ Administrator or user

Page | 175
 The administrator or user is the entity that initiates the search in the
application directory. The administrator or user primarily wants to obtain the
search results.
▪ Directory
The application directory is the directory that contains the application-specific
directory objects.
In this operation, the directory remains unchanged.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has access to a directory server to which it can establish
a connection, if it is not already connected, and send the request.
Main Success Scenario
1. Trigger: To initiate a search, the administrator or user provides the search
criteria for the directory objects that are of interest as input to the client
application, along with credentials. The administrator or user then invokes the
operation that searches for directory objects. The search criteria also specify
what information about each object is to be returned.
2. The client application establishes a connection to the directory server.
Windows Authentication Services authenticates the client application by using
the supplied credentials ([MS-AUTHSOD] section 2).
3. The client application sends a request to the directory server to search for the
directory objects, specifying the search criteria.
4. The directory server verifies that the credentials that are supplied through the
client application have the necessary access-control rights to complete the
operation ([MS-ADTS] section 5.1.3).
5. The directory server identifies all directory objects that match the criteria that
the client application supplies. From the set of directory objects that is
identified, the directory server extracts the information that the client
application requests.

Page | 176
6. The directory server sends a response to the client application that contains
the extracted information.
Postcondition
Information for the directory object is available to the client application.
Extensions
▪ If the search criteria that the client application supplies returns a result set
that is larger than the configured MaxPageSize ([MS-ADTS] section 3.1.1.3.4.6):
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client application that it has
exceeded the size limit for the request and returns all results up to the limit for
the result size.
▪ If the search criteria that the client application supplies potentially return
objects that are located on a different NC:
1-4. Same as Main Success Scenario.
5. Because the directory server that the client application is connected to does
not host the objects that the search criteria specify, the directory server
determines that another server or NC is better suited to process the search
request ([MS-ADTS] section 3.1.1.4.6).
6. The directory server sends a response to the client application that a referral
error has occurred.

24 Modify a Directory Object - Client Application

A common activity for an administrator is to modify objects. Timely updates on
these directory objects ensure that the data in the system is current, which
enables the Active Directory system to function correctly. To achieve this, the
administrator launches the client application to interact with the Active Directory
system. The client application establishes a connection to the Active Directory
system. The administrator uses the client application to modify an existing
directory object.
Goal
Modify a directory object in the Active Directory system.

Page | 177
Context of Use
An administrator wants to modify attributes of existing directory objects.

Figure 10: Use case diagram for modifying a directory object

Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the modification request, and
relays the response to the administrator.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity. This is done so that access control
decisions can be made by the Active Directory system.
▪ Directory server
The directory server is the supporting actor that receives the modification
request and modifies the directory object.

Page | 178
Stakeholders
▪ Administrator
The administrator initiates operations such as create, search, modify, and
delete on the application directory object. The administrator primarily wants
to receive information that the operations are successfully completed or
receive an error message if they failed.
▪ Directory
The directory is the entity that contains the object that is being modified.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has access to a directory server to which it can establish
a connection, if it is not already connected, and send the request.
▪ The directory object to be modified exists in the Active Directory system.
Main Success Scenario
1. Trigger: To initiate the modify operation, the administrator provides the name
of the directory object to modify as input to the client application, along with
credentials. The information provided by the administrator includes the
attribute(s) being modified on the object and the list of modifications to be
made to those attributes.
2. The client application establishes a connection to the directory server.
Windows Authentication Services authenticates the client application using
the supplied credentials ([MS-AUTHSOD] section 2).
3. The client application sends a modify request to the directory server to make
the appropriate modifications on the directory object.
4. The directory server verifies that the credentials that are supplied through the
client application have the necessary access-control rights to complete the
operation ([MS-ADTS] section 5.1.3).
5. The directory server modifies the object, as specified by the client application,
and makes any additional modifications that are mandated by the server's

Page | 179
 processing rules and constraints ([MS-ADTS] sections 3.1.1.5.1, 3.1.1.5.3, and
3.1.1.5.4).
6. The directory server sends a response to the client application that the
modifications were successfully completed.
Postconditions:
The directory object is modified.
Extensions
▪ There are multiple failure scenarios when the administrator modifies a
directory object in the Active Directory system. The operation has to be
validated against the server's processing rules and constraints, as described in
[MS-ADTS] sections 3.1.1.5.1 and 3.1.1.5.3.

25 Delete a Directory Object - Client Application

An administrator can perform maintenance on an Active Directory system by
removing objects that are no longer needed by the applications on the client. To
achieve this, an administrator launches the client application to interact with the
Active Directory system. The client application establishes a connection to the
Active Directory system. The administrator performs a delete operation on an
existing directory object (not a leaf object).
Goal
Delete a directory object from the Active Directory system.
Context of Use
An administrator wants to delete an existing directory object.

Page | 180
Figure 11: Use case diagram for deleting a directory object
Supporting Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to delete an object,
and relays the response to the administrator.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity. This is done so that access control
decisions can be made by the Active Directory system.
▪ Directory server
The directory server is the supporting actor that receives the deletion request
and deletes the directory object.
Stakeholders
▪ Administrator

Page | 181
 The administrator initiates operations on the application directory object such
as create, search, modify, and delete. The administrator primarily wants to
receive information that the operations are successfully completed or receive
an error message if they failed.
▪ Directory
The directory is the entity that contains the object being deleted.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has access to a directory server to which it can establish
a connection, if it is not already connected, and send the request.
▪ The directory object to be deleted exists in the Active Directory system.
Main Success Scenario
1. Trigger: The administrator initiates the delete operation by providing the
name of the directory object to delete to the Client Application with
credentials. The administrator then selects the directory object to delete and
submits the deletion request to the Active Directory system.
2. The client application establishes a connection to the directory server.
Windows Authentication Services authenticates the client application using
the supplied credentials ([MS-AUTHSOD] section 2).
3. The client application sends a delete request to the directory server to delete
the specified directory object.
4. The directory server verifies that the credentials supplied through the client
application have the necessary access-control rights to complete the operation
([MS-ADTS] section 5.1.3).
5. The directory server deletes the object that the client specified and makes any
additional modifications that are mandated by the server's processing rules
and constraints ([MS-ADTS] sections 3.1.1.5.1 and 3.1.1.5.5).
6. The directory server sends a response to the client application that the
deletion was successfully completed.

Page | 182
Postcondition
The directory object is no longer available.
Extensions
▪ If the client application attempted to delete a non-leaf directory object:
1-5. Same as Main Success Scenario
6. The directory server sends a response to the client application that it cannot
delete a non-leaf object ([MS-ADTS] section 3.1.1.5.5.5).
▪ If the client application attempted to delete a directory object that is owned
by the system ([MS-ADTS] section 3.1.1.5.5.3):
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client application that it cannot
perform the operation.

26 Create an Organizational Unit - Client Application

To streamline directory object management, an administrator can use
organizational units (OUs) to partition directory data. An organizational unit
represents the smallest unit to which an administrator can assign Group Policy
settings or delegate administrative authority. To achieve this, the administrator
launches the client application to interact with the Active Directory system. The
client application establishes a connection to the Active Directory system. The
administrator creates an organizational unit through the client application.
Goal
Create an organizational unit to facilitate partitioning of data in the Active
Directory system.
Context of Use
An administrator wants to create a different group to represent a specific set of
directory objects. On these objects, the administrator can apply a common policy.

Page | 183
Figure 12: Use case diagram for creating an organizational unit
Primary Actor: The primary actor is the client application.
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to create an
organizational unit, and relays the response to the administrator.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity. This is done so that access control
decisions can be made by the Active Directory system.
▪ Directory server
The directory server is the supporting actor that receives the creation request
and creates the organizational unit in the directory.
Stakeholders

Page | 184
▪ Administrator
The administrator initiates operations such as create, search, modify, and
delete on the application directory object. The administrator primarily wants
to receive information that the operations are successfully completed or
receive an error message if they failed.
▪ Group Policy
Group Policy allows managed configurations for users and computers.
The Active Directory system guarantees that, if possible, the new
organizational unit object is created, contains all the attribute values that the
client application set, and is ready for Group Policy assignments.
▪ Directory
The directory is the entity that will contain the object for the organizational
unit.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has access to a directory server to which it can establish
a connection, if it is not already connected, and send the request.
Main Success Scenario
1. Trigger: The administrator provides the name of the organizational unit as
input to the client application with credentials and invokes the operation that
creates the organizational unit.
2. The client application establishes a connection to the directory server.
Windows Authentication Services authenticates the client application by using
the supplied credentials ([MS-AUTHSOD] section 2).
3. The client application sends a request to the directory server to create a new
organizational unit and specifies the name for the new organizational unit.
4. The directory server verifies that the credentials supplied through the client
application have the necessary access-control rights to complete the operation
([MS-ADTS] section 5.1.3).

Page | 185
5. The directory server creates an object in the directory that represents the new
organizational unit with the name and other attributes that the client supplied.
The directory object is also populated with attributes that are mandated by
the server's processing rules and constraints ([MS-ADTS] sections 3.1.1.5.1 and
3.1.1.5.2).
6. The directory server sends a response to the client application that the new
organizational unit has been successfully created.
Postcondition
The organization unit is created and ready for use.
Extensions
▪ If the RDN value (that is, the name of the organizational unit to be created)
supplied through the client application is not unique under the same parent
container, as required by [MS-ADTS] section 3.1.1.5.2.2:
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client application that the
object name that was provided already exists.
▪ If the organizational unit creation request does not contain all mandatory
attributes, as required in [MS-ADTS] section 3.1.1.2.4.5:
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client application that the
missing attribute is required in the request.

27 Cross-Domain Move - Client Application

In this use case, cross-domain movement of an object is performed between two
domain controllers that are present in different domains.
Goal
To move an object from one domain to another domain.
Context of Use
To perform cross-domain movement when an object is required to be moved
from one domain to another domain. An administrator launches the client
application in order to perform the action.

Page | 186
Figure 13: Use case diagram for performing a cross-domain move
Actors
▪ Client application
The client application is the primary actor that initiates the cross-domain move
of a particular object.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity. This is done so that access control
decisions can be made by the Active Directory system.
▪ Domain Controller 1 (DC1)
DC1 is the supporting actor that is a domain controller in a domain.
▪ Domain Controller 2 (DC2)
DC2 is the supporting actor that is a domain controller in another domain.
Stakeholders

Page | 187
▪ Domain administrators and applications
Domain administrators and applications are the entities that move objects
from one domain to another.
Preconditions
▪ The environment, as described in section 2.5, is in place and the system-wide
preconditions, as described in section 2.6, are satisfied. The Active Directory
system completes initialization, as described in section 2.6.
▪ DC1 and DC2 are in different domains.
▪ The requester has permissions to perform a cross-domain move operation, as
described in [MS-ADTS] section 3.1.1.5.4.2.1.
Main Success Scenario
1. Trigger: An administrator triggers a request on the domain client to move an
object from DC1 to DC2.
2. The client application establishes a connection to DC1. Windows
Authentication Services authenticates the client application using the supplied
credentials ([MS-AUTHSOD] section 2).
3. The domain client sends a Modify DN request to DC1 for movement of the
object, as specified in [MS-ADTS] section 3.1.1.5.4.
4. DC1 sends an interdomain move request to DC2, as specified in [MS-ADTS]
section 3.1.1.5.4.2.3.
5. DC2 adds a new object to its replica.
6. DC1 creates a proxy object and deletes the original object.
Postcondition
An object is moved from one domain to the other.
Extensions
None.

Page | 188
28 Identity Lifecycle Management
The use cases in this category represent the management of accounts in the
Active Directory system. These accounts are used to gain access to the Active
Directory system. An account's lifecycle begins with its creation. After it is
created, an account can be used to access the system and perform other
operations based on the account's access-control rights. Accounts can be
modified to change the state or attributes of the account. When accounts are no
longer needed, they can be deleted. An account is a directory object, for
example, a user object, so these use cases represent a specialization of the use
cases in the Object Management category (section 2.7.1).
Note These use cases are applicable only to AD DS; they are not applicable to AD
LDS.
The following use case diagram shows the use cases of identity lifecycle
management.

Page | 189
Figure 14: Use cases for identity lifecycle management

29 Create a New Account - Client Application

In this use case, an administrator wants to create a new account in the directory
to allow a user to access directory resources. The administrator launches the
client application to create a new account. The client application establishes a
connection to the Active Directory system.

Page | 190
Goal
Create a new account in the directory.
Context of Use
An administrator wants to create a new account in the directory.

Figure 15: Use case diagram for creating a new account

Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the domain controller (DC), submits the request to create the
new account, and relays the response to the administrator.
▪ Windows Authentication Services

Page | 191
 Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity. This is done so that access-control
decisions can be made by the Active Directory system.
▪ DC
The DC is the supporting actor that receives the creation request and creates
the new account.
▪ RID Master DC
The RID Master DC is a supporting actor. It is the domain controller that is the
owner of the RID Master FSMO role for the domain.
Stakeholders
▪ Administrator
The administrator initiates operations such as create, reset, change, query for
group members, create a security group, modify the group member list, and
delete on the new account. The administrator primarily wants to receive
information that the operations are successfully completed or receive an error
message if they failed.
▪ Directory
The directory is the entity that contains the account being created.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to a directory server to which it can
establish a connection, if it is not already connected, and send the request.
Main Success Scenario
1. Trigger: The administrator launches the client application. To create a new
account, the administrator provides the account name for the new account
along with credentials as input to the client application.
2. The client application establishes a connection to the DC. Windows
Authentication Services uses the supplied credentials to authenticate the
client application ([MS-AUTHSOD] section 2).

Page | 192
3. The client application sends a request to the DC to create a new account and
specifies the account name for the new account.
4. The DC verifies that the credentials supplied through the client application
have the necessary access-control rights to complete the operation ([MS-
ADTS] section 5.1.3).
5. The DC validates the constraints on the new account name ([MS-SAMR]
sections 3.1.1.6 and 3.1.1.8.4).
6. The DC creates an object in the directory that represents the new account with
the account name that the client supplied. The directory object is additionally
populated with attributes that are mandated by the server's processing rules
and constraints ([MS-ADTS] sections 3.1.1.5.1 and 3.1.1.5.2 and [MS-SAMR]
sections 3.1.1.8 and 3.1.1.9).
7. The DC sends a response to the client application that the new account has
been successfully created.
Postcondition
The new account is created and ready for use.
Extensions
▪ If the credentials that are passed through the client application have
insufficient access-control rights to set the password on the account:
1-4. Same as Main Success Scenario.
5. The DC sends a response to the client application that the client application
has supplied credentials with insufficient access-control rights to set the
password on the account.
▪ If the account name that is supplied through the client application does not
satisfy the account name constraints that are outlined in [MS-SAMR] section
3.1.1.6:
1-5. Same as Main Success Scenario.
6. The DC sends a response to the client application that the supplied account
name does not meet the constraints.
▪ If the account name that is supplied through the client application is not
unique, as described in [MS-SAMR] section 3.1.1.8.4:

Page | 193
 1-5. Same as Main Success Scenario.
6. The DC sends a response to the client application that the supplied account
name is already in use by an existing account.
▪ If the DC has used all of the relative identifiers (RIDs) that were allocated to it
by RID Master FSMO role owner:
1-5. Same as Main Success Scenario. Then, after step 5, the DC sends a RID
allocation request to the RID Master DC according to the rules specified in
[MS-DRSR] section 4.1.10.4.3 to obtain a new RID range.
6-7. Same as main Success Scenario.

30 Reset an Existing Account's Password - Client Application

In this use case, a user has forgotten the password for his or her account and
contacts an administrator. The administrator wants to reset the account's
password to a known value so that they can communicate the new password to
the user. The administrator launches a client application to reset the password on
an existing account. The client application establishes a connection to the Active
Directory system.
Goal
Reset the password on an account to a known value.
Context of Use
A user has forgotten his or her password and wants to reset it to a new value.

Page | 194
Figure 16: Use case diagram for resetting the password of an existing account
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to reset the password,
and relays the response to the administrator.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity. This is done so that access control
decisions can be made by the Active Directory system.
▪ Directory server
The directory server is the supporting actor that receives the password-reset
request and performs the tasks that are associated with resetting a user's
password in the directory.
Stakeholders

Page | 195
▪ Administrator
The administrator initiates operations such as create, reset, change, query for
group members, create a security group, modify the group member list, and
delete on an account. The administrator primarily wants to receive
information that the operations are successfully completed or receive an error
message if they failed.
▪ User
The user is the person who needs to access directory resources.
For the user, the Active Directory system guarantees that, if possible, the
password for the user's account is reset.
▪ Directory
The directory is the entity that contains the user's existing account.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to a directory server to which it can
establish a connection, if it is not already connected, and send the request.
▪ The account for which the password change is performed exists.
Main Success Scenario
1. Trigger: The administrator provides the account name of the existing account
and the new password as input to the client application and invokes the
operation that resets the password of an account.
2. The client application establishes a connection to the directory server.
Windows Authentication Services uses the supplied credentials to
authenticate the client application ([MS-AUTHSOD] section 2).
3. The client application sends a request to the directory server to reset the
password of an existing account. This request includes the account name of
the account and the new password supplied by the administrator.

Page | 196
4. The directory server verifies that the credentials that are supplied through the
client application have the necessary access-control rights to complete the
operation. ([MS-ADTS] section 5.1.3).
5. The directory server verifies that the new password satisfies the password
policy, as described in [MS-SAMR] section 3.1.1.7.1.
6. The directory server updates the password of the existing account with the
new value that is supplied in the request. Additional attributes are updated as
mandated by the server's processing rules and constraints ([MS-ADTS] sections
3.1.1.5.1 and 3.1.1.5.3 and [MS-SAMR] section 3.1.1.8.7).
7. The directory server sends a response to the client application that the
password has been successfully updated.
Postcondition
The account's password is reset.
Extensions
▪ If the credentials that were passed through the client application have
insufficient access-control rights to set the password on the account:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application that the
client application has supplied credentials with insufficient access-control
rights to set the password on the account.
▪ If the password that was supplied through the client application does not
satisfy the password constraints described in [MS-SAMR] section 3.1.1.7.1:
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client that the supplied
password does not meet the constraints.

31 Change an Existing Account's Password (PDC) - Client Application

In this use case, a user whose account is present in an Active Directory domain
wants to change the existing password to a new value. The user launches a client
application to change the password on the user account. The client application
establishes a connection to the Active Directory system by connecting to a

Page | 197
domain controller that is the primary domain controller (PDC) FSMO role owner
for the domain.
Goal
Change the password on an account to a new value.
Context of Use
This use case is used when a client machine connects to the PDC for LDAP and
domain services and the user wants to change the password of the user account.

Figure 17: Use case diagram for changing the password of an existing account
(PDC)
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to change the
password, and relays the response to the user.
▪ Windows Authentication Services

Page | 198
 Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the user's identity. This is done so that access control decisions
can be made by the Active Directory system.
▪ Directory server
The directory server is the supporting actor that receives the password-change
request and performs the tasks that are associated with changing a user's
password in the directory. The directory server is the owner of the PDC FSMO
role for the domain.
Stakeholders
▪ User
The user initiates the password change on his or her existing account. The user
primarily wants to receive information that the password was successfully
changed or receive an error message if the password was not changed.
▪ Directory
The directory is the entity that contains the user's existing account.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to a directory server to which it can
establish a connection, if it is not already connected, and send the request.
▪ The account on which the password change is being performed exists.
Main Success Scenario
1. Trigger: The user provides the account name of the existing account, the
existing password for the account, and the new value for the password to the
client application, and then invokes the operation that changes the password
of the account.
2. The client application establishes a connection to the directory server.
Windows Authentication Services uses the supplied credentials to
authenticate the client application ([MS-AUTHSOD] section 2).

Page | 199
3. The client application sends a request to the directory server to change the
password of an existing account. This request includes the account name of
the account, the current password, and the new password that the user
supplies.
4. The directory server verifies that the credentials that are supplied through the
client application have the necessary access-control rights to complete the
operation ([MS-ADTS] section 5.1.3).
5. The directory server verifies that the current password that is supplied through
the client application matches the account's password that is stored in the
directory.
6. The directory server verifies that the new password satisfies the password
policy, as described in [MS-SAMR] section 3.1.1.7.1.
7. The directory server updates the password of the existing account with the
new value that is supplied in the request. Additional attributes are updated as
mandated by the server's processing rules and constraints ([MS-ADTS] sections
3.1.1.5.1 and 3.1.1.5.3 and [MS-SAMR] section 3.1.1.8.7).
8. The directory server sends a response to the client application that the
password has been successfully updated.
Postcondition
The account's password is changed.
Extensions:
▪ If the credentials that are passed through the client application have
insufficient access-control rights to set the password on the account:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application that it
supplied credentials with insufficient access-control rights to set the password
on the account.
▪ If the current password that the user supplies does not match the password
that is stored in the directory:
1-5. Same as Main Success Scenario.

Page | 200
 6. The directory server sends a response to the client application that the
supplied password is incorrect.
▪ If the new password that the user supplies does not satisfy the password
constraints described in [MS-SAMR] section 3.1.1.7.1:
1-6. Same as Main Success Scenario.
7. The directory server sends a response to the client application that the
supplied password does not meet the constraints.

32 Change an Existing Account's Password (DC) - Client Application

In this use case, a user whose account is present in an Active Directory domain
wants to change the existing password to a new value. The user starts a client
application to change the password on the account. The client application
establishes a connection to the Active Directory system by connecting to a DC
that is not the owner of the PDC FSMO role for the domain. This use case
highlights the communication between the DC and the PDC in the domain.
Goal
Change the password on an account to a new value.
Context of use
The user wants to change the password on the user account.

Page | 201
Figure 18: Use case diagram for changing the password of an existing account
(DC)
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to change the
password, and relays the response to the user.
▪ Windows Authentication Services

Page | 202
 Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the user's identity so that the Active Directory system can make
access-control decisions.
▪ DC
A domain controller that is not the owner of the PDC FSMO role for the
domain. It is the supporting actor that receives the password-change request,
performs the tasks that are associated with changing a user's password in the
directory, and sends a password update request to the PDC.
▪ PDC
The primary domain controller of the domain. It is the supporting actor that
receives the password update request from the DC and updates the user-
password details in its directory database. The PDC is the owner of PDC FSMO
role for the domain.
Stakeholders
▪ User
The user initiates the password change on his or her existing account. The user
primarily wants to receive information that the password was successfully
changed or receive an error message if the password was not changed.
▪ Directory
The directory is the entity that contains the user's existing account.
Preconditions
▪ The system-wide preconditions described in section 2.6 are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to a DC to which it can establish a
connection, if it is not already connected, and send the request.
▪ The DC has connectivity to the PDC to which it establishes a secure channel
and sends the password update request.
▪ The account on which the password is to be changed exists.
Main Success Scenario

Page | 203
1. Trigger: The user provides the account name of the existing account, the
existing password for the account, and the new value for the password to the
client application and invokes the operation that changes the password of the
account.
2. The client application establishes a connection to the DC. Windows
Authentication Services uses the supplied credentials to authenticate the
client application, as described in [MS-AUTHSOD] section 2.
3. The client application sends a request to the DC to change the password of the
given account. This request includes the account name, the current password,
and the new password supplied by the user.
4. An access check is performed on the DC to ensure that the user has the access
rights to complete the operation, as described in [MS-ADTS] section 5.1.3.
5. The DC verifies that the current password that is supplied through the client
application matches the account's password that is stored in the directory.
6. The DC verifies that the new password satisfies the password policy, as
described in [MS-SAMR] section 3.1.1.7.1.
7. The DC updates the password of the existing account with the new value that
is supplied in the request. Additional attributes are updated as mandated by
the server's processing rules and constraints ([MS-ADTS] sections 3.1.1.5.1 and
3.1.1.5.3 and [MS-SAMR] section 3.1.1.8.7).
8. The DC establishes a secure channel with the PDC according to the processing
rules and constraints specified in [MS-NRPC] sections 3.1.1 and 3.1.4.3 and
[MS-ADTS] section 6.1.6.9.2.
9. The DC sends a password update request to the PDC according to the
processing rules and constraints specified in [MS-SAMS] section 3.3.5.4.
10.The PDC sends a response to the DC indicating that the password has been
successfully updated.
11.The DC sends a response to the client application that the password has been
successfully updated.
Postconditions

Page | 204
The account's password is changed at the DC, and it is also updated for the PDC
FSMO role owner of the domain.

33 Change User Account Password Against an RODC - Client Application

In this use case, a user whose account is present in an Active Directory domain
wants to change the existing password to a new value. The user starts a client
application to change the password on the user account. The client application
establishes a connection to the Active Directory system via a read-only domain
controller (RODC) to update the password.
Goal
Change the password on an account to a new value.
Context of use
This use case is used when a client machine connects to an RODC for LDAP and
domain services, and the user wants to change the password of the user account.

Page | 205
Figure 19: Use case diagram for changing the password of an existing account
(RODC)
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to change the
password, and relays the response to the user.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the user's identity so that the Active Directory system can make
access-control decisions.
▪ RODC

Page | 206
 A read-only domain controller that contains a read-only replica of the naming
context (NC) that contains the user account. The RODC is the supporting actor
that receives the password-change request and performs the tasks associated
with changing a user's password in the directory. The RODC forwards the
password update request to the DC.
▪ DC
A domain controller that contains a writable replica of the NC that contains
the user account. The DC is the supporting actor that receives the password
update request from the RODC and updates the user password details in its
directory database. The DC contains a writable replica of the domain NC in
which the user account is present.
Stakeholders
▪ User
The user initiates the password change on his or her existing account. The user
primarily wants to know that the password was successfully changed or
receive an error message if the password was not changed.
▪ Directory
The directory is the entity that contains the user's existing account.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to an RODC to which it can establish a
connection (if it is not already connected) and send the request.
▪ The RODC has connectivity to a DC to which it can establish a secure channel
and send the password update request.
▪ The account on which the password is to be changed exists.
Main Success Scenario
1. Trigger: The user provides the account name of the existing account, the
existing password for the account, and the new value for the password to the

Page | 207
 client application, and then invokes the operation that changes the password
of the account.
2. The client application establishes a connection to the RODC. Windows
Authentication Services uses the supplied credentials to authenticate the
client application, as described in [MS-AUTHSOD] section 2.
3. The client application sends a request to the RODC to change the password of
an existing account according to rules specified in one of the following
references:
1. [MS-NRPC] sections 3.5.4.4.6 and 3.5.4.4.5
2. [MS-SAMR] sections 3.1.5.10.2 and 3.1.5.10.3
4. The RODC processes the request according to the following rules.
1. If the client application sends the request in step 3 according to the rules
specified in [MS-NRPC], the RODC forwards the request to the DC according
to the processing rules specified in [MS-SAMS] section 3.2.4.4.
2. If the client application sends the request in step 3 according to the rules
specified in [MS-SAMR], the RODC forwards the request to the DC
according to the processing rules specified in [MS-SAMS] section 3.2.4.5.
5. The DC processes the request from the RODC according to the rules that are
specified in the appropriate section of [MS-SAMS], as indicated in step 4, and
sends a response.
6. On receiving the success response from the DC, the RODC sends that response
to the client application.
Postconditions
The account's password is changed, and it is updated in the writable NC replica of
the DC.

34 User Logon to Domain Services by Using an RODC and Updating the User
LastLogonTimeStamp - Client Application
In this use case, a user successfully logs on to a domain by using an RODC, after
which the associated last-logon time value is updated in the lastLogonTimeStamp
attribute of the user account.

Page | 208
Goal
When the user successfully logs on, the lastLogonTimeStamp attribute of the user
account is updated in the directory.
Context of Use
This use case is used by an RODC to communicate the user's latest
lastLogonTimeStamp to the DC whenever the user logs on to the domain. The
lastLogonTimeStamp attribute represents the time when the user successfully
logged on to the domain. This use case is used in scenarios where the client
application is connecting to an RODC for directory services.

Figure 20: Use case diagram for a last-logon time value update by using an RODC
Actors
▪ Client application
The client application is the primary actor. The user is trying to log on to the
domain by using the client application. It is the entity that initiates
authentication operations to access a resource in the directory.
▪ RODC
The RODC is a read-only domain controller. It is the supporting actor to which
the client application is connected in order to authenticate the user.

Page | 209
▪ DC
The DC is a domain controller in the domain. It is the supporting actor that
contains a writable replica of the naming context in which the user account is
present.
Stakeholders
▪ User
The user is the person whose account is being updated with a last-logon time
value.
▪ Directory
The directory is the entity that contains user accounts and logon details of the
user.
Preconditions
▪ The system-wide preconditions described in section 2.6 are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to an RODC to which it can establish a
connection (if it is not already connected) and send the request.
▪ The account that the user uses for the logon is present in the directory.
▪ The RODC is configured to allow caching of the account credentials of a user.
Main Success Scenario
1. Trigger: The user enters the credentials needed to log on to the client.
2. The client application establishes a connection to the RODC. Windows
Authentication Services that is present in the RODC uses the supplied
credentials to authenticate the user ([MS-AUTHSOD] section 2).
3. The RODC verifies that the credentials supplied by the client application have
the necessary access-control rights to complete the operation ([MS-ADTS]
section 5.1.3).
4. If the user is successfully authenticated, the RODC sends a success response to
the client application.

Page | 210
5. On successful verification of step 3, the RODC sends a
LogonTimeStampUpdatesForward request ([MS-SAMS] section 3.2.4.6) to the
DC.
6. The DC updates the lastLogonTimeStamp attribute of the user account and
sends a response.
Postcondition
The user account's lastLogonTimeStamp attribute is updated to reflect the user's
last logon time.

35 Query an Account's Group Membership - Client Application

In this use case, an administrator wants to display an account's group
membership in order to determine the account's access rights. The administrator
launches a client application to query the group membership of a specified
account. The client application establishes a connection to the Active Directory
system.
Goal
Retrieve an account's group membership.
Context of Use
An administrator wants to retrieve or use group membership of a directory
object.

Page | 211
Figure 21: Use case diagram for querying the group membership of an account
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to obtain group
membership, and relays the response to the administrator.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity so that the Active Directory system
can make access-control decisions.
▪ Directory server
The directory server is the supporting actor that receives the request for
group-membership information and gathers the information for the requestor.
Stakeholders
▪ Administrator

Page | 212
 The administrator initiates operations such as create, reset, change, query
group members, create security group, modify group member list, and delete
on an account. The administrator primarily wants to receive information that
the operations are successfully completed or receive an error message if they
failed.
▪ Directory
The directory is the entity that contains and maintains group membership.
In this operation, the directory is left unchanged.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to a directory server to which it can
establish a connection, if it is not already connected, and send the request.
▪ The account for which group membership is being requested exists.
Main Success Scenario
1. Trigger: The administrator provides the account name of the account to query
as input to the client application with credentials and invokes the operation
that queries the group membership of an account.
2. The client application establishes a connection to the directory server.
Windows Authentication Services use the supplied credentials to authenticate
the client application ([MS-AUTHSOD] section 2).
3. The client application sends a request to the directory server to retrieve the
group membership of the account.
4. The directory server verifies that the credentials that are supplied through the
client application have the necessary access-control rights to complete the
operation ([MS-ADTS] section 5.1.3).
5. The directory server sends a response to the client application that contains
the group membership of the specified account.
Postcondition

Page | 213
Group-membership information for the account is available to the client
application.
Extensions
▪ If the credentials that are supplied through the client application have
insufficient access-control rights to retrieve the group membership of the
account:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application. Group-
membership information is not returned to the client application.

36 Delete an Account - Client Application

In this use case, an administrator wants to delete an account from the directory
to prevent its further use. The administrator launches a client application to
delete an account. The client application establishes a connection to the Active
Directory system.
Goal
Delete an account in the directory.
Context of Use
An administrator wants to delete an account from the directory to prevent its
further use.

Page | 214
Figure 22: Use case diagram for deleting an account
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to delete an account,
and relays the response to the administrator.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity so that the Active Directory system
can make access-control decisions.
▪ Directory server
The directory server is the supporting actor that receives the deletion request
and deletes the account from the directory.
Stakeholders
▪ Administrator

Page | 215
 The administrator initiates operations such as create, reset, change, query for
group members, create a security group, modify the group member list, and
delete on an account. The administrator primarily wants to receive
information that the operations are successfully completed or receive an error
message if they failed.
▪ Directory
The directory is the entity that contains the account being deleted.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to a directory server to which it can
establish a connection, if it is not already connected, and send the request.
▪ The account that is being deleted exists.
Main Success Scenario
1. Trigger: The administrator provides the account name of the account to be
deleted as input to the client application with credentials and invokes the
operation that deletes an account.
2. The client application establishes a connection to the directory server.
Windows Authentication Services authenticates the client application using
the supplied credentials ([MS-AUTHSOD] section 2).
3. The client application sends a request to the directory server to delete the
account.
4. The directory server verifies that the credentials that are supplied through the
client application have the necessary access-control rights to complete the
operation ([MS-ADTS] section 5.1.3).
5. The directory server deletes the object in the directory that represents the
account with the account name that the client supplies. Additional processing
tasks that are mandated by the server's processing rules and constraints might
occur ([MS-ADTS] sections 3.1.1.5.1 and 3.1.1.5.3).

Page | 216
6. The directory server sends a response to the client application indicating that
the account has been successfully deleted.
Postcondition
The account is no longer available.
Extensions
▪ If the credentials that are supplied through the client application have
insufficient access-control rights to delete the account:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application that the
supplied credentials have insufficient access-control rights to delete the
account.

37 Create a Security Group - Client Application

In this use case, an administrator wants to create a security group to be used for
access-control decisions. The administrator launches a client application to create
the new security group. The client application establishes a connection to the
Active Directory system.
Goal
Create a new security group in the directory.
Context of Use
An administrator wants to create a security group to be used for access-control
decisions.

Page | 217
Figure 23: Use case diagram for creating a security group
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to create the security
group, and relays the response to the administrator.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity so that the Active Directory system
can make access-control decisions.
▪ Directory server
The directory server is the supporting actor that receives the creation request
and creates the security group.
Stakeholders
▪ Administrator

Page | 218
 The administrator initiates operations such as create, reset, change, query for
group members, create a security group, modify the group member list, and
delete on an account. The administrator primarily wants to receive
information that the operations are successfully completed or receive an error
message if they failed.
▪ Directory
The directory is the entity that contains the security group being created.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to a directory server to which it can
establish a connection, if it is not already connected, and send the request.
Main Success Scenario
1. Trigger: The administrator provides the group name for the new security
group as input to the client application, along with credentials, and invokes
the operation that creates a new security group.
2. The client application establishes a connection to the directory server.
Windows Authentication Services authenticates the client application by using
the supplied credentials ([MS-AUTHSOD] section 2).
3. The client application sends a request to the directory server to create a new
security group and specifies the group name for the new group.
4. The directory server verifies that the credentials that are supplied through the
client application have the necessary access-control rights to complete the
operation ([MS-ADTS] section 5.1.3).
5. The directory server validates the constraints on the new group name, as
described in [MS-SAMR] sections 3.1.1.6 and 3.1.1.8.4.
6. The directory server creates an object in the directory that represents the new
security group with the group name supplied by the client. The directory
object is additionally populated with attributes that are mandated by the
server's processing rules and constraints ([MS-ADTS] sections 3.1.1.5.1 and
3.1.1.5.2).

Page | 219
7. The directory server sends a response to the client application that the new
security group has been successfully created.
Postcondition
The new security group is created and ready for use.
Extensions
▪ If the credentials that are supplied through the client application have
insufficient access-control rights to create the new security group:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application that the
supplied credentials have insufficient access-control rights to create the new
security group.
▪ If the group name that the administrator supplies does not satisfy the group
name constraints, as described in [MS-SAMR] section 3.1.1.6:
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client application that the
specified group name does not meet the constraints.
▪ If the group name that is supplied through the client application is not unique,
as described in [MS-SAMR] section 3.1.1.8.4:
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client application that the
specified group name is already in use by an existing group.

38 Modify Group Member List - Client Application

In this use case, an existing security group is used to control access to directory
resources. An administrator wants to modify the member list of that group so
that a new account can access the controlled resources. The administrator starts
a client application to modify the member list for an existing group. The client
application establishes a connection to the Active Directory system.
Goal
Modify the member list of an existing group.
Context of Use

Page | 220
An administrator wants to add or delete members to a security group.

Figure 24: Use case diagram for modifying the member list of a group
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to modify the member
list of a group, and relays the response to the administrator.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity so that the Active Directory system
can make access-control decisions.
▪ Directory server
The directory server is the supporting actor that receives the request and
modifies the list.
Stakeholders

Page | 221
▪ Administrator
The administrator initiates operations on an account such as create, reset,
change, query for group members, create a security group, modify the group
member list, and delete. The administrator primarily wants to know that the
operations are successfully completed or receive an error message if they
failed.
▪ Directory
The directory is the entity that contains the list being modified.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to a directory server to which it can
establish a connection (if it is not already connected) and send the request.
▪ The security group that is being modified exists.
Main Success Scenario
1. Trigger: The administrator provides the group name for the group to be
modified and the updates for the group's member list, along with credentials,
as input to the client application, and invokes the operation that modifies the
member list of a group.
2. The client application establishes a connection to the directory server.
Windows Authentication Services uses the supplied credentials to authenticate
the client application ([MS-AUTHSOD] section 2).
3. The client application sends a request to the directory server to modify the
member list of the specified group. The updates for the member list are
included in the request.
4. The directory server verifies that the credentials supplied through the client
application have the necessary access-control rights to complete the operation
([MS-ADTS] section 5.1.3).
5. The directory server verifies that the new member list satisfies the constraints
described in [MS-SAMR] section 3.1.1.8.9.

Page | 222
6. The directory object that represents the group is modified with the new
member list. Additional processing might occur, as described in [MS-ADTS]
sections 3.1.1.5.1 and 3.1.1.5.3, and [MS-SAMR] section 3.1.1.8.9.
7. The directory server sends a response to the client application that the
member list has been modified.
Postcondition
The group's member list is modified.
Extensions
▪ If the credentials supplied through the client application have insufficient
access-control rights to modify the member list of the group:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application that the
supplied credentials have insufficient access-control rights to modify the
member list of the group.
▪ If the member list supplied through the client application does not satisfy the
constraints ([MS-SAMR] section 3.1.1.8.9):
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client application that the
specified member list does not meet the constraints.

39 Query for Members of a Group - Client Application

In this use case, an administrator wants to view the members of a group to better
determine which users have certain access-control rights. The administrator starts
a client application to query for the membership of a specified group. The client
application establishes a connection to the Active Directory system.
Goal
Retrieve the member list of a group.
Context of Use
An administrator wants to view the members of a group to better determine
which users have certain access-control rights.

Page | 223
Figure 25: Use case diagram for querying for the members of a group
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to retrieve a group's
member list, and relays the response to the administrator.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity so that the Active Directory system
can make access-control decisions.
▪ Directory server
The directory server is the supporting actor that receives the request for a
group's member list and gathers the information for the requestor.
Stakeholders
▪ Administrator

Page | 224
 The administrator initiates operations on an account such as create, reset,
change, query for group members, create a security group, modify the group
member list, and delete. The administrator primarily wants to receive
information confirming that the operations are successfully completed or
receive an error message if they failed.
▪ Directory
The directory is the entity that contains and maintains group membership
information.
In this operation, the directory remains unchanged.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to a directory server to which it can
establish a connection (if it is not already connected) and send the request.
▪ The group for which information is being sought exists.
Main Success Scenario
1. Trigger: The administrator provides the group name of the group to be queried
as input to the client application with credentials and invokes the operation
that queries a group's member list.
2. The client application establishes a connection to the directory server.
Windows Authentication Services uses the supplied credentials to authenticate
the client application ([MS-AUTHSOD] section 2).
3. The client application sends a request to the directory server to retrieve the
member list of the group.
4. The directory server verifies that the credentials that are supplied through the
client application have the necessary access-control rights to complete the
operation ([MS-ADTS] section 5.1.3).
5. The directory server sends a response to the client application that contains
the member list for the specified group.
Postcondition

Page | 225
The member list of the group is available to the client application.
Extensions
▪ If the credentials that are supplied through the client application have
insufficient access-control rights to retrieve the member list of the group:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application. The member
list of the group is not returned to the client application.

40 Schema Management
When the set of classes and attributes in the base Active Directory schema does
not meet the requirements of the applications, the administrator can extend the
schema by adding a new class to the schema, by adding a new attribute to the
schema, or by adding an attribute to an existing class. Schema classes and
attributes are objects that are stored in Active Directory. Adding a new class to
the schema is equivalent to creating a new object of the classSchema class ([MS-
ADTS] section 3.1.1.2.4.8); adding a new attribute to the schema is equivalent to
creating a new object of the attributeSchema class ([MS-ADTS] section 3.1.1.2.3);
adding an attribute to an existing class is done by modifying the corresponding
classSchema object, which modifies the class definition to contain the attribute.
After a new class or attribute is successfully added to the schema, users can
create the objects of the newly defined or extended schema class.
The following diagram illustrates the use cases of schema management.

Page | 226
Figure 26: Use cases for schema management

41 Add a New Class to the Schema - Client Application

In this use case, the administrator realizes that the set of classes in the base
Active Directory schema does not meet the requirements of an application on the
client. The administrator extends the schema by adding a new class to the
schema; that is, by creating a new object of the classSchema class. After the new
class is successfully added to the schema, the administrator can create objects of
the newly defined class.
Goal
The client application adds a new class to the schema of the Active Directory
system.
Context of Use
When the set of classes in the base Active Directory schema does not meet the
requirements of a client application, the administrator can extend the schema by
adding new objects of the classSchema class.

Page | 227
Figure 27: Use case diagram for adding a new class to the Active Directory
schema
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to add a new class,
and relays the response to the administrator.
▪ Windows Authentication Services
The Windows Authentication Services [MS-AUTHSOD] is the supporting actor
that authenticates the administrator's identity so that the Active Directory
system can make access-control decisions.
▪ Directory server
The directory server is the supporting actor that receives the request and adds
the new class.
Stakeholders

Page | 228
▪ Administrator
The administrator initiates the addition of a new class to the schema. The
administrator primarily wants to receive information that the class was
successfully added or receive an error message if it was not added.
▪ Directory
The directory is the entity that contains the additional class.
Preconditions
▪ The system-wide preconditions described in section 2.6 are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to a directory server to which it can
establish a connection, if it is not already connected, and send the request.
Main Success Scenario
1. Trigger: The administrator provides the mandatory attributes ([MS-ADTS]
section 3.1.1.2) for the new class, along with credentials, as input to the client
application, and then invokes the operation that adds a new class to the
schema.
2. The client application establishes a connection to the directory server that
owns the Schema Master FSMO role ([MS-ADTS] section 3.1.1.5.1.8). Windows
Authentication Services uses the supplied credentials to authenticate the
client application ([MS-AUTHSOD] section 2).
3. The client application sends a request to the directory server to create a new
class, specifying the values of the attributes that are present on the
classSchema object for the new class.
4. The directory server verifies that the credentials that are supplied through the
client application have the necessary access-control rights to complete the
operation ([MS-ADTS] section 3.1.1.2.5).
5. The directory server verifies that it owns the Schema Master FSMO role ([MS-
ADTS] section 3.1.1.2.5).
6. The directory server validates the constraints on the new class attributes, as
specified in [MS-ADTS] section 3.1.1.2.5.

Page | 229
7. The directory server creates an object in the directory that represents the new
class with the attributes supplied by the client application. The directory
object is additionally populated with attributes that are mandated by the
server's processing rules and constraints ([MS-ADTS] sections 3.1.1.2.5,
3.1.1.5.1, and 3.1.1.5.2.)
8. The directory server sends a response to the client application indicating that
the new class has been successfully added to the schema.
Postcondition
The new object of class classSchema is created and ready for use.
Extensions
▪ If the credentials that are supplied through the client application have
insufficient access-control rights to add the new schema class:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application indicating
that the supplied credentials have insufficient access-control rights to add the
new class to the schema.
▪ If the directory server to which the client application connects does not own
the Schema Master FSMO role ([MS-ADTS] section 3.1.1.2.5):
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client application with a
referral to the directory server that does own the Schema Master FSMO role.
▪ If the class name that is supplied through the client application is not unique:
1-6. Same as Main Success Scenario.
7. The directory server sends a response to the client application that the
object name to be created is already in use.
▪ If the attributes that the client application provides do not meet consistency
checks ([MS-ADTS] section 3.1.1.2.5.1.1):
1-6. Same as Main Success Scenario.
7. The directory server sends a response to the client application that it cannot
perform the operation.

Page | 230
42 Add a New Attribute to the Schema - Client Application
In this use case, an administrator realizes that the set of attributes in the base
Active Directory schema does not meet the requirements of an application on the
client. To extend the schema, the administrator adds a new attribute to the
schema; that is, the administrator creates an object of class attributeSchema.
After the new attribute is successfully added to the schema, the administrator can
then add the attribute to a class and create objects of that class with the new
attribute.
Goal
The client application adds a new attribute to the schema of the Active Directory
system.
Context of Use
When the set of attributes in the base Active Directory schema does not meet the
requirements of a client application.

Figure 28: Use case diagram for adding a new attribute to the Active Directory
schema

Page | 231
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to add a new
attribute, and relays the response to the administrator.
▪ Windows Authentication Services
The Windows Authentication Services [MS-AUTHSOD] is the supporting actor
that authenticates the administrator's identity so that the Active Directory
system can make access-control decisions.
▪ Directory server
The directory server is the supporting actor that receives the request and adds
the new attribute.
Stakeholders
▪ Administrator
The administrator initiates the addition of a new attribute to the schema. The
administrator primarily wants to receive information that the attribute was
successfully added or receive an error message if it was not added.
▪ Directory
The directory is the entity that contains the additional attribute.
Preconditions
▪ The system-wide preconditions described in section 2.6 are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to a directory server to which it can
establish a connection, if it is not already connected, and send the request.
Main Success Scenario
1. Trigger: The administrator provides the mandatory attributes ([MS-ADTS]
section 3.1.1.2) for the new object, along with credentials, as input to the
client application, and then invokes the operation that adds a new attribute to
the schema.

Page | 232
2. The client application establishes a connection to the directory server that
owns the Schema Master FSMO role ([MS-ADTS] section 3.1.1.5.1.8). Windows
Authentication Services uses the supplied credentials to authenticate the
client application ([MS-AUTHSOD] section 2).
3. The administrator provides the required information for the new schema
attribute to the client application.
4. The client application sends a request to the directory server to create a new
attribute (an object of class attributeSchema), specifying the values of the
attributes that are present on the attributeSchema object.
5. The directory server verifies that the credentials that are supplied through the
client application have the necessary access-control rights to complete the
operation ([MS-ADTS] section 3.1.1.2.5).
6. The directory server verifies that it owns the Schema Master FSMO role ([MS-
ADTS] section 3.1.1.2.5).
7. The directory server validates the constraints on the new attributeSchema
object attributes, as described in ([MS-ADTS] section 3.1.1.2.5).
8. The directory server creates an object of class attributeSchema in the directory
that represents the new attribute with the values of the attributes that the
client application supplied. The directory object is additionally populated with
attributes that are mandated by the server's processing rules and constraints
([MS-ADTS] sections 3.1.1.2.5, 3.1.1.5.1, and 3.1.1.5.2).
9. The directory server sends a response to the client application that the new
attribute has been successfully added to the schema.
Postconditions
The new object of class attributeSchema is created and ready for use.
Extensions
▪ If the credentials that are supplied through the client application have
insufficient access-control rights to add the new attribute to the schema:
1-5. Same as Main Success Scenario.

Page | 233
 6. The directory server sends a response to the client application that the
supplied credentials have insufficient access-control rights to add the new
attribute to the schema.
▪ If the directory server to which the client application connects does not own
the Schema Master FSMO role ([MS-ADTS] section 3.1.1.2.5):
1-6. Same as Main Success Scenario.
7. The directory server sends a response to the client application with a
referral to the directory server that does own the Schema Master FSMO role.
▪ If the attribute name supplied through the client application is not unique:
1-7. Same as Main Success Scenario.
8. The directory server sends a response to the client application that the
object name to be created is already in use.
▪ If the attributes that the client application provides do not meet the
consistency checks ([MS-ADTS] section 3.1.1.2.5.1.1):
1-7. Same as Main Success Scenario.
8. The directory server sends a response to the client application that it cannot
perform the operation.

43 Add an Attribute to a Class - Client Application

In this use case, an existing class in the base Active Directory schema lacks an
attribute that an application on the client requires. The administrator extends the
schema by adding an attribute to the class. After the attribute is successfully
added to the class, the administrator can create objects of the extended class
with the newly added attribute.
Goal
The client application adds an attribute to a class.
Context of Use
A class in the base Active Directory schema lacks an attribute that the client
application requires.

Page | 234
Figure 29: Use case diagram for adding an attribute to an existing class
Actors
▪ Client application
The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request to add an attribute to
a class, and relays the response to the administrator.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity so that the Active Directory system
can make access-control decisions.
▪ Directory server
The directory server is the supporting actor that receives the request and adds
the attribute to the class.
Stakeholders
▪ Administrator

Page | 235
 The administrator initiates the addition of an attribute to a class in the
schema. The administrator primarily wants to receive information that the
attribute was successfully added to the class or receive an error message if it
was not added.
▪ Directory
The directory is the entity that contains the attribute and the class.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The client application has connectivity to a directory server to which it can
establish a connection, if it is not already connected, and send the request.
▪ The attribute and the class exist in the directory schema.
Main Success Scenario
1. Trigger: The administrator provides the attribute name and the class name as
input to the client application, along with credentials, and then invokes the
operation that adds an attribute to a class.
2. The client application establishes a connection to the directory server that
owns the Schema Master FSMO role ([MS-ADTS] section 3.1.1.5.1.8). Windows
Authentication Services authenticates the client application that is using the
supplied credentials ([MS-AUTHSOD] section 2).
3. The client application sends a request to the directory server to add an
attribute to a class in the directory schema and specifies the attribute name
and the class name for this operation.
4. The directory server verifies that the credentials that are supplied through the
client application have the necessary access-control rights to complete the
operation ([MS-ADTS] section 3.1.1.2.5).
5. The directory server verifies that it owns the Schema Master FSMO role ([MS-
ADTS] section 3.1.1.2.5).
6. The directory server validates the constraints on the attribute and the class, as
described in ([MS-ADTS] section 3.1.1.2.5).

Page | 236
7. The directory server adds the attribute to the class.
8. The directory server sends a response to the client application indicating that
the attribute has been successfully added to the class.
Postcondition
The class has been updated with the specified attribute.
Extensions
▪ If the credentials supplied through the client application have insufficient
access-control rights to modify the class:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application indicating
that the supplied credentials have insufficient access-control rights to add the
attribute to the class.
▪ If the directory server to which the client application connects does not own
the Schema Master FSMO role ([MS-ADTS] section 3.1.1.2.5):
1-5. Same as Main Success Scenario.
6. The directory server sends a response to the client application with a
referral to the directory server that does own the Schema Master FSMO role.
▪ If the attribute to be added or the class to be modified is not defined in the
schema:
1-6. Same as Main Success Scenario.
7. The directory server sends a response to the client application indicating
that the attribute or the class is not defined in the schema.
▪ If the Active Directory schema has the attribute to be added already defined in
the class:
1-6. Same as Main Success Scenario.
7. The directory server sends a response to the client application indicating
that the value to be added already exists.
▪ If the attributes that the client application provides do not meet the
constraints ([MS-ADTS] section 3.1.1.2.5):
1-6. Same as Main Success Scenario.

Page | 237
 7. The directory server sends a response to the client application indicating
that it cannot perform the operation.

44 Name Translation
The use case in this category represents name translation between a directory
object's security identifier (SID) and human-readable names of the security
principals in the access control entries (ACEs) that secure the object. Name
translation can be used in such tasks as determining how an object is secured in
the directory or modifying the way in which it is secured.
The following use case diagram illustrates the use case of name translation.

Figure 30: Use case for name translation

45 Convert a SID to/from a Human-Readable Format - Client Application

Note This use case is applicable only to AD DS; it is not applicable to AD LDS.
This use case describes the translation between the machine-readable and
human-readable forms of names.
When an administrator wants to investigate and maintain the security of a
directory object, translation between the machine-readable and human-readable
forms of names might be required. This translation allows the administrator, via a
client application, to secure access to a directory object without the requirement
to understand machine-readable names. The client application displays the
human-readable names of the security principals in the access control entries
(ACEs) that secure the object, which have been translated from SIDs. The

Page | 238
administrator specifies human-readable names of security principals when
securing the object, which are translated to SIDs.
Goal
Translate an object's SID to or from another format or type of name.
Context of Use
An IT administrator uses a client application to secure access to a directory object.
The application displays the human-readable names of the security principals in
the ACEs that secure the object. The administrator specifies human-readable
names of security principals when securing the object.

Figure 31: Use case diagram for converting a SID to or from a human-readable
format
Actors
▪ Client application

Page | 239
 The client application is the primary actor. It is the entity that prepares the
connection to the directory server, submits the request for name translation,
and returns the result to the administrator.
▪ Windows Authentication Services
Windows Authentication Services [MS-AUTHSOD] is the supporting actor that
authenticates the administrator's identity so that the Active Directory system
can make access-control decisions.
▪ Directory server
The directory server is the supporting actor that receives the translation
request and performs the actual translation.
Stakeholders
▪ Administrator
The administrator performs security actions that trigger the requirement for a
name translation. The administrator primarily wants to read and provide
human-readable names and does not want to understand machine-readable
names.
▪ Directory
The directory is the entity that contains the objects being considered by the
administrator.
Preconditions
▪ The system-wide preconditions, as described in section 2.6, are satisfied. The
Active Directory system completes initialization, as described in section 2.6.
▪ The application has network connectivity to a directory server that meets the
requirements described in section 2.5 to which it can establish a connection, if
it is not already connected, and send the request.
Main Success Scenario
1. Trigger: Following an administrator action, the client application has to display
human-readable names. These names correspond to the SIDs in the access
control lists (ACLs) that secure the object with which the administrator is
interacting. Alternatively, the administrator provides a human-readable name

Page | 240
 to the client application, along with credentials, in order to set an ACL on an
object. To perform the requested action, the client application has to retrieve
the SID of the object that corresponds to that name.
2. The client application establishes a connection to the directory server.
Windows Authentication Services authenticates the client application using
the supplied credentials ([MS-AUTHSOD] section 2).
3. The client application sends a request to the directory server to perform name
translation between the SID and the human-readable name of directory
objects of interest to the administrator.
4. The directory server identifies the directory objects for which name translation
has to be performed.
5. From the set of directory objects so identified, the directory server obtains
their names in the requested name format.
6. The directory server sends a response to the client that contains the names in
the requested format.
Postcondition
The translated information is available to the client application.
Extensions
▪ The SID or the name that is supplied through the client application is
misformatted, as described in [MS-DTYP] section 2.4.2.3 and [MS-LSAT] section
3.1.4.5, respectively:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application indicating
that an invalid parameter was used in the request, as described in [MS-LSAT]
sections 3.1.4.5 and 3.1.4.9.
▪ No object exists in the directory with the SID or the name provided:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application indicating
that no object exists with the SID or the name provided.
▪ Not all SIDs in the request could be translated to names:

Page | 241
 1-4. Same as Main Success Scenario.
5. The Directory Server sends a response to the client application indicating
that only some of the SIDs were translated to names.
▪ Not all names in the request could be translated to SIDs:
1-4. Same as Main Success Scenario.
5. The directory server sends a response to the client application indicating
that only some of the names were translated to SIDs.
▪ The client does not have necessary permissions to read the object whose SID
or name was supplied:
1-3. Same as Main Success Scenario.
4. The directory server sends a response to the client application indicating
that it has insufficient access-control rights to perform the name translation.

46 Directory Replication
The use cases in this category represent replication of directory data that is
maintained by the Active Directory system. Domain and forest data have to be
replicated among disparate physical storage devices to maintain the integrity of
the abstract logical structure of the directory. Replication can happen at various
levels within a directory and under varying circumstances. Consider the following
examples:
▪ If copies of domain data, or replicas, exist on multiple servers within the
domain, that is, if there are multiple domain controllers (DCs) within the
domain, new objects and modifications to existing objects are replicated to all
of the domain's DCs by using normal replication cycles.
▪ A forest typically consists of multiple domains, each of which is maintained by
one or more domain controllers. Some of the data that is stored in the
directory is considered to be forest-wide data, which is replicated to all of the
domain controllers in the forest.
▪ Some of the values that are stored in the directory, such as user password and
account status, are of such a nature that propagation of changes in these
values is time-critical. Replication of these values has to happen outside of
normal replication cycles to allow for rapid propagation of the changes
throughout the directory.

Page | 242
The following use case diagram shows the use cases of directory replication that
are described in this document.

Figure 32: Use cases for directory replication

47 Replicate Changes Within a Domain - Domain Controller

In this use case, a domain is maintained by three domain controllers; that is,
copies of the domain data, or replicas, exist on three domain controllers within
the domain: Domain Controller 1 (DC1), Domain Controller 2 (DC2), and Domain
Controller 3 (DC3). Changes to the data have been implemented on DC1; that is,
DC1 has originating updates, and those changes need to be replicated to DC2 and
DC3 by using a normal, intra-site replication cycle. This replication topology
between DC1, DC2, and DC3 is formed by the Knowledge Consistency Checker
(KCC) based on administrator-assigned costs, as described in section 1 and [MS-
ADTS] section 6.2.
Goal
Replicate originating updates that occurred on one domain controller to the other
domain controllers in the domain.
Context of use

Page | 243
Changes need to be replicated within a domain to keep data consistent among
domain controllers that store the same directory partitions. This scenario works in
a replication topology built by the KCC, as described in section 1 and specified in
[MS-ADTS] section 6.2.

Figure 33: Use case diagram for replicating changes in domain data
Actors
▪ Domain Controller 1 (DC1)
DC1 is the primary actor and has originating updates to its domain data.
▪ Domain Controller 2 (DC2)
DC2 is a supporting actor that has not yet received the originating updates that
were applied to DC1. DC2 is a replication partner of DC1.
▪ Domain Controller 3 (DC3)
DC3 is a supporting actor that has not yet received the originating updates that
were applied to DC1. DC3 is a replication partner of DC2.
Stakeholders

Page | 244
▪ Domain administrators and applications
Domain administrators and applications are the entities that change attribute
values in domain data.
▪ Domain users
Domain users are the people who depend on the information that is stored in
the directory.
For all of these entities, the Active Directory system propagates all changes to
domain data to all domain controllers in the domain so that a consistent view of
the directory is maintained for all clients, regardless of which domain controller
they communicate with.
Preconditions
▪ The environment described in section 2.5 is in place, and the system-wide
preconditions described in section 2.6 are satisfied. The Active Directory
system completes initialization, as described in section 2.6.
▪ The KCC has created the replication topology of the domain; that is, the
physical connections among the domain controllers of the domain that are
used for replication traffic.
Main Success Scenario
Note This Main Success Scenario has no dependency on replication requests
between DC1 to DC2 and DC2 to DC3. The order in this scenario has been chosen
to show how the changes are replicated from DC1 to DC2 and DC3. This scenario
covers scheduled replication, which is described in section 1 and [MS-ADTS]
section 3.1.1.1.14.
1. Trigger: A domain administrator changes an attribute's value for an object in
the domain data; the change is manifested as an originating update on DC1.
2. DC2 identifies its replication partner as DC1.
3. DC1 and DC2 perform mutual authentication by using Kerberos.
4. DC2 sends a request to DC1 periodically to obtain the new value.
5. DC2 applies the change to its replica.

Page | 245
6. DC3 then identifies its replication partner as DC2.
7. DC2 and DC3 perform mutual authentication by using Kerberos.
8. DC3 sends a request to DC2 periodically to obtain the new value.
9. DC3 applies the change to its replica.
Postcondition
The change to the attribute's value is replicated throughout the domain.
Extensions
None.

48 Replicate Changes to a GC or a Partial Replica by Using RPC - Domain

Controller
In this use case, replication of changes is performed periodically between a
domain controller that is a full replica and a global catalog (GC) or a partial
replica in another domain by using RPC.
Goal
Replicate changes to a GC or partial replica.
Context of use
Changes have to be replicated between two domain controllers, where one is a
full replica and the other is a GC or a partial replica in another domain. This
scenario works in a replication topology that was built by the KCC, as described in
section 1 and [MS-ADTS] section 6.2.

Page | 246
Figure 34: Use case diagram for replicating changes in a full replica to a GC or a
partial replica
Actors
▪ Domain Controller 1 (GC)
Domain Controller 1, or DC1, is the primary actor that has not yet received the
originating updates that were applied to DC2. DC1 is a GC or partial replica
and a replication partner of DC2.
▪ Domain Controller 2 (DC2)
DC2 is the supporting actor that has originating updates to its domain data.
Stakeholders
▪ Domain administrators and applications
Domain administrators and applications are the entities that change attribute
values in domain data.
Preconditions
▪ The environment described in section 2.5 is in place and the system-wide
preconditions described in section 2.6 are satisfied. The Active Directory
system completes initialization, as described in section 2.6.

Page | 247
▪ The KCC has created the replication topology of the domain; that is, the
physical connections among the domain controllers of the domain that are
used for replication traffic.
▪ DC1 and DC2 are in different domains.
▪ DC1 has a partial replica of the domain in which DC2 resides.
Main Success Scenario
1. Trigger: A domain administrator changes an attribute's value for an object in
the domain data. The change is manifested as an originating update on DC2.
2. Depending on the replication interval calculated by the KCC ([MS-ADTS]
section 6.2), DC1 sends a request to DC2 to obtain new values of only the
attributes of the objects that are present in the DC1 partial replica.
3. DC2 responds to DC1 with the new values.
4. DC1 applies the changes to its replica.
Postcondition
Replication changes to the attributes that are present in the partial replica are
updated to the new values that are present in the full replica.
Extensions
None.
Variation
Replicate changes to a GC or a partial replica by using SMTP
All the details in the preceding scenario are the same except that there are
additional preconditions as follows:
▪ DC1 and DC2 are in different sites ([MS-SRPL] section 1.3).
▪ The domain controllers require the ability to send and receive SMTP messages
using any SMTP mail transfer agent, as specified in [RFC2821].
▪ There are additional conditions that the configurations of the domain
controllers have to meet before the DRS Protocol Extensions for SMTP can be

Page | 248
 used to replicate state between the domain controllers, as described in [MS-
SRPL] sections 1.5 and 3.1.3.

49 Transferring a FSMO Role - Domain Controller

This use case describes the transfer of a FSMO role of one domain controller to
another domain controller.
Goal
Transfer a FSMO role that one domain controller owns to another domain
controller.
Context of Use
To transfer a FSMO role when a domain controller is being demoted or a domain
administrator initiates the transfer of FSMO roles.

Figure 35: Use case diagram for transferring a FSMO role

Actors
▪ Domain Controller 1 (DC1)
DC1 is the primary actor that is shutting down or that an administrator is
demoting.
▪ Domain Controller 2 (DC2)
DC2 is the supporting actor to which the FSMO role is being transferred.

Page | 249
Stakeholders
▪ Domain administrators and applications
Domain administrators and applications are the entities that trigger the
transfer of FSMO roles.
Preconditions
▪ The environment described in section 2.5 is in place, and the system-wide
preconditions described in section 2.6 are satisfied. The Active Directory
system completes initialization, as described in section 2.6.
▪ DC1 is the owner of the FSMO role being transferred to DC2.
Main Success Scenario
1. Trigger: Transfer of the FSMO role is triggered when DC1 is demoted or when
the domain administrator initiates the transfer.
2. DC1 identifies the new FSMO role owner to be DC2, either arbitrarily in the
case of demotion, or because of the input of the administrator.
3. DC1 and DC2 perform mutual authentication by using Kerberos.
4. DC1 sends a rootDSE modify message ([MS-ADTS] section 3.1.1.3.3) to DC2
requesting that DC2 assume ownership of the FSMO role.
5. DC2 determines the current owner of the FSMO role, which in this case is DC1,
and invokes an extended operation request ([MS-DRSR] section 4.1.10.4.3)
against DC1 to request transfer of the FSMO role ownership.
6. DC1 transfers its FSMO role to DC2 through the transfer request.
Postcondition
The FSMO role is transferred to another domain controller.
Extensions
None.

Page | 250
50 Trust Management
These use cases describe the creation of trust relationships between domains or
forests, along with trust validation. A domain trust is created by creating a trusted
domain object (TDO), as specified in [MS-ADTS] section 6.1.6. These TDOs are
managed and created as specified in [MS-LSAD] section 3.1.4.7. The Netlogon
Remote Protocol ([MS-NRPC] (NRPC)) validates or manages domain trusts, as
specified in [MS-NRPC] section 3.5.4.7.

Figure 36: Use cases for trust management

51 Create a Trust - Domain Controller

In this use case, a trust is created between two domains or forests.
Goal
Create a trust between domains or forests in order to grant access to resources.
Context of Use
Access to resources is needed between certain domains or forests.

Page | 251
Figure 37: Use case diagram for creating a trust between domains or forests
Actors
▪ Domain Controller 1 (DC1)
DC1 is the primary actor that is in a domain.
▪ Domain Controller 2 (DC2)
DC2 is the supporting actor that is in a different domain. It can be in the same
forest or in a different forest.
Stakeholders
▪ Users
Users are people or other entities that belong to one domain who need to
access directory resources in the other domain.
Preconditions
▪ The environment described in section 2.5 is in place and the system-wide
preconditions described in section 2.6 are satisfied. The Active Directory
system completes initialization, as described in section 2.6.
▪ DC1 and DC2 are in different domains but can be in the same forest or
different forests.
Main Success Scenario

Page | 252
1. Trigger: An application triggers this scenario when it creates a trust between
domain controllers that belong to different domains.
2. DC1 and DC2 use Kerberos to perform mutual authentication.
3. DC1 sends a request to create a trusted domain object (TDO) to DC2.
4. The TDO is created in DC2.
Postcondition
The trust is created between the two domains.
Extensions
None.

52 Domain Services
The use cases in this category pertain to the interaction between domain clients
and those servers that service requests from the domain client to participate in
domain activities. The relevant domain activities include the following: locating a
domain controller, joining a domain, and unjoining from a domain.
The following use case diagram shows the use cases that pertain to domain-join
activities.

Figure 38: Use cases for domain services

Page | 253
53 Join a Domain with a New Account - Domain Client
This use case describes the general case of how to join a domain with a new
account. A new account can be created in the domain by using either SAMR or
LDAP. See sections 3.1.2 and 3.1.3 for details.

Figure 39: Join a domain by creating a new account

Goal
Join a domain client to a domain by creating a new account for the domain client
in the domain.
Context of Use
The domain-client administrator invokes this task to enable the domain client to
access the services and resources in a domain and to grant domain members
access to the domain client.
Actors
▪ Domain client

Page | 254
 The domain client is the primary actor. It is the entity that locates and
connects to the domain controller and is joined to the domain.
▪ Domain controller
The domain controller is the supporting actor that advertises its capabilities,
responds to domain-join inquiries, and ultimately joins the domain client to
the domain.
▪ Domain administrator
The domain administrator is the supporting actor that enables the domain
client, by using the credentials of the domain administrator, to open a secure
connection to the domain controller.
Stakeholders
▪ End user
The end user wants to join a domain client to a domain so that he or she can
access resources within the domain.
The end user primarily wants to receive information that the domain client
was joined to the domain.
▪ Client administrator
The client administrator initiates the domain-join process on the domain
client.
The client administrator primarily wants to receive information that the
domain client was successfully joined to the domain and to receive an error
message if it was not joined.
Preconditions
The credentials of an administrator of the domain who can create machine
accounts in the domain are available to the client administrator.
Main Success Scenario
1. Trigger: The client administrator triggers this use case to join the client
computer to a domain.
2. The domain client uses the Locate a Domain Controller use case to locate a
domain controller (see section 2.7.7.3.1).

Page | 255
3. The domain client uses the domain administrator's supplied credentials to
open a secure connection to the domain controller.
4. The domain client retrieves domain information.
5. The domain client uses the domain administrator's credentials to set up an
account for itself in the domain.
6. The domain client determines the trusted domains.
7. The domain client updates the client account in the domain.
8. The domain client updates the local client state.
9. The domain client reinitializes local protocols.
Postcondition
The domain client is joined to the domain.
Extensions
None.
Variation - Join a Domain with a new account that is created via LDAP
All details are identical to those of the main success scenario except for steps 3-5,
which are replaced with the following steps:
3. The domain client uses the domain administrator's credentials to connect to
the LDAP server on the domain controller and performs a bind to establish a
secure LDAP connection.
4. The domain client retrieves domain information.
5. The domain client uses LDAP to create an account in the domain for itself.

54 Unjoin from the Domain - Domain Client

In this use case, a client administrator wants to unjoin a domain client from the
domain that it is currently part of, usually to repurpose or decommission the
client computer.
Goal
Unjoin a domain client from the domain.

Page | 256
Context of Use
The domain-client administrator invokes this task to enable the domain client to
unjoin from the domain so that the members of the domain do not access its
resources.

Figure 40: Use case diagram to unjoin a domain client from the domain
Actors
▪ Domain client
The domain client is the primary actor. It is the entity that locates and
connects to the domain controller and unjoins from the domain. If the unjoin
task fails, the local state of the domain client is unchanged.
▪ Domain controller
The domain controller is the supporting actor that advertises its capabilities,
responds to domain-unjoin inquiries, and services the request from the
domain client to disable the domain account.
Stakeholders
▪ Client administrator
The client administrator initiates the domain-unjoin process on the domain
client.

Page | 257
 The primary interest of the client administrator is that the state of the
computer object on the domain controller is updated to reflect that the
domain client has unjoined from the domain.
▪ Client computer
The client computer is the computer on which the domain client runs before
the domain-unjoin task is initiated.
The primary interest of the client computer is that the machine local state of
the domain client is updated to reflect that the client has unjoined from the
domain.
Preconditions
▪ The client computer has successfully completed the domain join task, as
described in preceding sections, and is still part of the domain.
Main Success Scenario
1. Trigger: The client administrator triggers this use case to unjoin the client
computer from the domain.
2. The domain client uses the Locate a Domain Controller use case to locate a
domain controller. For more information, see section 2.7.7.3.1.
3. The domain client uses the credentials of the domain administrator to
establish an SMB/CIFS connection to the domain controller ([MS-SMB2], [MS-
SMB], or [MS-CIFS]).
4. The domain client uses the SAMR protocol to disable the machine account on
the domain controller [MS-SAMR].
5. The (former) domain client updates its local state.
6. The (former) domain client closes connections.
7. The (former) domain client reinitializes local protocols.
Postcondition
The domain client is no longer joined to the domain.
Extensions
None.

Page | 258
55 Supporting Use Cases

56 Locate a Domain Controller - Domain Client

This use case describes the task of locating a domain controller. When an
application on the client needs to access resources in a domain, locating a
domain controller is the first step in the process.
This use case is important for other use cases and examples in which the domain
client is not yet joined to the domain and the Netlogon Remote Protocol is
therefore not initialized. For more information, see the preceding use cases about
domain services and section 3.1.
Goal
To locate a domain controller to perform domain-oriented actions.
Context of Use
Any domain client that requires access to directory resources needs to
authenticate itself to the directory. For authentication, domain clients need to be
connected to one of the domain controllers that is reachable. To locate a
reachable domain controller, domain clients perform this use case.

Page | 259
Figure 41: Use case diagram for locating a domain controller
Actors
▪ Domain client
The domain client is the primary actor. It is the entity that locates and queries
the domain controller and that will eventually be joined to the domain.
▪ Domain controller
The domain controller is the supporting actor that registers its capabilities,
responds to inquiries about those capabilities, and ultimately joins the domain
client to the domain.
▪ DNS Infrastructure
The DNS Infrastructure is a supporting actor that maintains information about
domain controllers and sends that information to the domain client.
▪ NetBIOS Infrastructure
The NetBIOS Infrastructure is a supporting actor that maintains information
about domain controllers and sends that information to the domain client.

Page | 260
Stakeholders
▪ End user
The end user wants to join a domain client to a domain so that he or she can
access resources in the domain.
The end user primarily wants to receive information that a domain controller
can be located so that the domain client can be joined to the domain or to
receive an error message if the domain client cannot be joined. If a domain
controller cannot be located, the local state of the domain client is left
unchanged.
▪ Applications
Applications enable the end user to access resources within the domain.
Applications can also use domain resources autonomously.
The primary interest of an application is that a domain controller that meets
the required capabilities is located and that information about the domain
controller is provided to the domain client so that the domain client can be
joined to the domain. By having the domain client joined to the domain, the
application can use domain resources to perform the tasks that the end user,
the application itself, or other applications on the domain client initiated.
Preconditions
To locate a domain controller requires that at least one of the infrastructures,
NetBIOS or DNS, is available to discover domain controllers that can satisfy the
requested capabilities.
Main Success Scenario
In this scenario, the fully qualified domain name (FQDN) (2) of the domain in
which the Domain Controller is to be located is available to the domain client.
1. Trigger: This use case is triggered by operations such as joining a computer to
a domain in order to locate a domain controller.
2. The domain client uses the FQDN to query the DNS Infrastructure for the
service (SRV) resource records of certain types of domain controllers, as
described in [MS-ADTS] section 6.3.6.1.

Page | 261
3. The DNS Infrastructure provides one or more SRV resource records of domain
controllers that are of the specified type to the domain client.
4. The domain client uses the DNS Infrastructure to resolve the names of the
domain controllers in order to obtain the IP addresses. It then contacts the
domain controllers via an LDAP Ping ([MS-ADTS] section 6.3.3) to determine
"liveness" and to confirm that the requested capabilities are present.
5. At least one domain controller that satisfies the domain client's requirements
responds to the domain client's ping.
6. A domain controller is chosen for use in other tasks; for example to join a
domain.
Postcondition
A domain controller is located.
Extensions
None.
Variation - Locate a Domain Controller by using NetBIOS
In this scenario, only the NetBIOS domain name of the domain is available.
Domain controllers in the domain have created a mailslot with a registered
NetBIOS group name, as described in [MS-MAIL] section 3.1.4.1 and [MS-ADTS]
section 6.3.5.
1. The domain client queries the NetBIOS Infrastructure for NetBIOS group
names that contain a list of domain controllers.
2. The NetBIOS Infrastructure provides the NetBIOS group names.
3. Using the NetBIOS group names, the domain client contacts the candidate
domain controllers via a MAILSLOT ping ([MS-ADTS] section 6.3.5), which is
sent to a NetBIOS group name ([MS-MAIL] section 3.1.4.1) that has been
registered by domain controllers ([MS-ADTS] section 6.3.5).
4. At least one domain controller that satisfies the client's requirements responds
to the domain client's ping.
5. A domain controller is chosen for use in other tasks; for example, to join a
domain.

Page | 262
57 Versioning, Capability Negotiation, and Extensibility
There are two distinct modes of operation of the Active Directory system: Active
Directory Domain Services (AD DS) and Active Directory Lightweight Directory
Services (AD LDS). Additionally, some versions of AD DS and AD LDS include
support for Web Services protocols. A summary of the different modes along with
the protocols (or protocol subsets) and directory schemas supported by each is
provided in the table later in this section. Information about which versions of AD
DS and AD LDS support Web Services protocols is given in the following product
behavior note.<4>. The Technical Documents for the individual protocols specify
additional versioning information; that is, not all versions of the Active Directory
system support every method of a protocol that is listed in the table.
Modes and Protocols Supported

Protocols Protocols of which a subset is Schemas

Mode supported supported implemented
AD DS [MS-DSSP] DRSR: All methods of the dsaop [MS-ADA1]
(without (DSSP) RPC interface are supported. All [MS-ADA2]
Web [LDAP] (LDAP) methods of the drsuapi interface [MS-ADA3]
Services) [MS-LSAD] are supported except for the [MS-ADSC]
(LSAD) following:
[MS-LSAT] (LSAT) IDL_DRSInitDemotion
[MS-SAMR] IDL_DRSFinishDemotion
(SAMR)
AD DS [MS-ADCAP] DRSR: All methods of the dsaop [MS-ADA1]
(with (ADCAP) RPC interface are supported. All [MS-ADA2]
Web [MS-DSSP] methods of the drsuapi interface [MS-ADA3]
Services) (DSSP) are supported except for the [MS-ADSC]
[LDAP] (LDAP) following:
[MS-LSAD] IDL_DRSInitDemotion
(LSAD) IDL_DRSFinishDemotion
[MS-LSAT] (LSAT)
[MS-SAMR]
(SAMR)
[WSENUM] (WS-
Enumeration)

Page | 263
 Protocols Protocols of which a subset is Schemas
Mode supported supported implemented
[WXFR] (WS-
Transfer)
Protocol
Extensions [MS-
WSTIM] (IMDA)
[MS-WSDS]
(WSDS)
[MS-WSPELD]
(WSPELD)
AD LDS [LDAP] (LDAP) DRSR: All methods of the [MS-ADLS]
(without drsuapi RPC interface are
Web supported except for the
Services) following:
IDL_DRSAddSidHistory
IDL_DRSDomainControllerInfo
IDL_DRSRemoveDsDomain
IDL_DRSGetNT4ChangeLog
IDL_DRSGetMemberships
IDL_DRSInterDomainMove
IDL_DRSGetMemberships2
IDL_DRSQuerySitesByCost
IDL_DRSWriteSpn
No methods of the dsaop RPC
interface are supported.
DSSP: Supported in the same
manner as any member server
or stand-alone server on which
the Active Directory system is
not running.
AD LDS [LDAP] (LDAP) ADCAP: All methods of the [MS-ADLS]
(with [WSENUM] (WS- AccountManagement port type
Web Enumeration) are supported. The following
Services) [WXFR] (WS- methods of the
Transfer) TopologyManagement port type
are supported:

Page | 264
 Protocols Protocols of which a subset is Schemas
Mode supported supported implemented
Protocol MoveADOperationMasterRole
Extensions ChangeOptionalFeature
[MS-WSTIM] DRSR: All methods of the
(IMDA) drsuapi RPC interface are
[MS-WSDS] supported except for the
(WSDS) following:
[MS-WSPELD] IDL_DRSAddSidHistory
(WSPELD) IDL_DRSDomainControllerInfo
IDL_DRSRemoveDsDomain
IDL_DRSGetNT4ChangeLog
IDL_DRSGetMemberships
IDL_DRSInterDomainMove
IDL_DRSGetMemberships2
IDL_DRSQuerySitesByCost
IDL_DRSWriteSpn
No methods of the dsaop
interface are supported.
DSSP: Supported in the same
manner as any member server
or stand-alone server on which
the Active Directory system is
not running.
The state model, constraints, processing rules, and so on, in [MS-ADTS] apply to
both AD DS and AD LDS, except as otherwise noted in [MS-ADTS]. [MS-ADDM]
applies to the Web Services-enabled versions of both AD DS and AD LDS.
58 Error Handling
There are several potential failure scenarios for the Active Directory system.
"Failure", in this context, does not refer to an error returned by a member
protocol due to an invalid or not permitted request (for example, a request to
modify a directory object when the requestor does not have the necessary
permissions to do so). Such errors are part of the normal processing behavior of
the system. Instead, "failure" in this context refers to conditions that can prevent
the system from successfully servicing requests made by a client that uses the
member protocols.

Page | 265
These failure scenarios are the following:
▪ Transient unavailability of durable storage, without loss or corruption of data
▪ Permanent unavailability of durable storage
▪ Corruption of data on the durable storage
▪ Unavailability of networking
▪ Unavailability of DNS
▪ Failures while joining or unjoining a domain
Additionally, individual member protocols can have their own failure scenarios.
Such scenarios are documented in the protocols' Technical Documents and are
not repeated here.
The Active Directory system does not define any error handling requirements
beyond those that are described in the Technical Documents of the protocols that
the system supports, as listed in section 2.4, and in the failure scenarios described
in the sections that follow.
Various kinds of errors might occur that affect the system. More precisely, an
error condition might affect one or more protocols supported by the system. Such
error conditions and the resulting protocol semantics are described in the
corresponding protocol Technical Documents. The system does not constrain the
types of errors that can be received through the member protocols.

59 Transient Unavailability of Durable Storage

As described in section 2.6, the Active Directory system requires access to
durable storage. The system has to be able to read from and write to this storage.
This storage is used to store all persisted state, including the directory tree, in the
Active Directory system.
It is possible that while operating, a directory server might temporarily lose
access to its durable storage. The state that is stored on the durable storage is
intact and uncorrupted, but the directory server cannot access it; for example, the
disk could have become unplugged, or the disk controller could have failed. In
such a case, the directory server does not permit any request to succeed that

Page | 266
requires altering the persisted state of the directory. The directory server can
permit a request that requires retrieving state to succeed if that request can be
completely and accurately answered by using only the state that the directory
server has available to it while the durable storage is unavailable. For example, as
a performance optimization, an implementation can choose to cache some state
in memory, provided that doing so does not violate any transactional guarantees
of the member protocols. An implementation could (but is not required to) use
such cached state to respond to any requests that require retrieving state,
provided the cached state is sufficient to completely and accurately respond to
the request.
When rejecting a request while in this scenario, the member protocol is permitted
to use any suitable error code that indicates that the directory server cannot
process the request. The system does not constrain the protocol's choice of error
code.
A implementation of the system is permitted, but not required, to monitor the
durable storage system to determine if the storage becomes available again and
to automatically resume normal servicing of requests. Alternatively, an
implementation of the system can require administrative action to recover from
such a scenario; for example, to require a restart of the directory server.
Because the state that is stored on the durable storage was not altered while the
storage was offline, and the directory server rejected any requests that would
have required a modification of the state during that period, after the durable
system becomes available and the system resumes normal servicing of requests,
the abstract data of the system's protocols is in the same state as immediately
prior to the storage becoming unavailable.

60 Permanent Unavailability of Durable Storage

The preceding failure scenario dealt with the case of a transient unavailability of
the durable storage. However, it is also possible that the durable storage on
which the system's state is stored becomes permanently unavailable; for
example, due to a nonrepairable hardware failure in the disk media. In this case,
all of the state that is stored in the storage system is lost.

Page | 267
As in the case of a transient unavailability of the storage system, the directory
server does not permit any request to succeed that requires altering the persisted
state of the directory. The directory server can permit a request to succeed that
requires retrieving state if that request can be completely and accurately
answered by using only the state that the directory server has available to it while
durable storage is unavailable.
When rejecting a request while in this scenario, the member protocol is permitted
to use any suitable error code that indicates that the directory server cannot
process the request. The system does not constrain the protocol's choice of error
code.
Because the system generally does not have any means to determine on its own
whether the storage system is temporarily or permanently unavailable, the key
difference between this scenario and the previous scenario is that recovery in this
scenario typically requires administrative intervention.
After making any necessary repairs or replacements of the storage system to
return it to service, the administrator restores the state of the directory server
from the most recent backup copy. The means of backing up and restoring such
state is implementation-specific.
After the backup is restored, the state of the directory server is as it was at the
time the backup was taken. Further, any changes to the state that were replicated
to one or more replica directory servers in the directory service subsequent to
the time the backup was taken can be regained after the restore through
replication.

61 Data Corruption
While a durable storage system does everything possible to protect the integrity
of the data that is stored on it, data corruption nonetheless remains a possibility
even in the best maintained storage system. Such corruption could occur while
the storage system is online, or it could occur during a transient outage of the
storage system.
In such a case, the directory server detects such data corruption. An
implementation is permitted to use any means of detection that it has at its
disposal. The directory server does not permit any protocol requests that require

Page | 268
access to the corrupted data to succeed. When rejecting a request while in this
scenario, the member protocol is permitted to use any suitable error code that
indicates that the directory server cannot process the request. The system does
not constrain the protocol's choice of error code.
After data corruption has been detected, recovery proceeds in a manner similar
to the case where the durable storage has become permanently unavailable.
Essentially, data that cannot be trusted is treated in the same manner as no data
at all.

62 Unavailability of Networking
A functional networking system is vital to the ability of clients to communicate
with the directory server. If the networking system becomes unavailable, clients
cannot send any new requests to the directory server, and they cannot receive
any responses to outstanding requests. A functional networking system is also
vital to the ability of directory servers to replicate directory data among
themselves. This situation could cause a temporary loss of system coherency if
segments of the network that are part of the same domain cannot communicate
with each other but clients and domain controllers within the segments can still
communicate.
Networking could become unavailable due to a hardware failure, such as the
failure of a network switch or router, or a software problem, such as
misconfiguration of a routing table.
When the directory server is in this state, it cannot respond to any requests that
clients attempt to send to it, and directory servers cannot respond to replication
requests. As such, it is beneficial for clients and directory servers to enforce a
time-out on any requests that they send so that they do not stop responding
indefinitely while they wait for a response.
After the network becomes available again and communications are restored
between the client(s) and the directory server and among directory servers,
individual directory servers resume processing requests in accord with the
behavior described in the Technical Documents. The loss of networking does not
in itself cause any change in the state of the abstract data of the system's
protocols.

Page | 269
63 Unavailability of DNS
DNS can be used by clients of the Active Directory system in order to locate
directory servers by using the algorithms described in [MS-ADTS] section 6.3. If
DNS ceases to be available (for example, by failure of the DNS servers), any clients
that use those location algorithms will be unable to find a directory server to send
their requests to. This will not affect any connections that clients already have to
the directory server. Additionally, clients are permitted to use other means to
locate a directory server (for example, by prompting the user to enter the IP
address of a directory server) or to store and reuse the address of a previously
located directory server. Such clients will also not be immediately affected by the
loss of DNS.
After DNS is restored to normal operating behavior, clients that depend on the
location algorithms of [MS-ADTS] section 6.3 can once again locate directory
servers.

64 Failures while Joining or Unjoining a Domain

Several of the examples in this document describe domain-join tasks that are
completed through a series of actions that affect necessary state changes such
that the client is joined to the domain (see section 3.1). These changes include
those that are local to the client and those that occur in the domain (that is, those
that create or modify a computer account object on a domain controller (DC)). In
general, failure of any one particular action causes failure of the associated task.
Exceptions to this principle are specified where necessary; for example, failed
updates to the SNTP protocol [MS-SNTP] during join or unjoin processing are
ignored.
Although unlikely, the domain-join tasks that are described in this document
might fail when making local (client) state changes. Such failures can occur due to
reasons such as resource starvation. The tasks do not attempt to remedy these
failure conditions; the only recourse is for the task caller to re-execute the task.
When communicating with a remote machine such as a domain controller, some
obvious potential failure conditions include lack of network connectivity, or
insufficient security privileges to create or modify a computer account object. The
domain-join tasks that are described in this document do not attempt to remedy

Page | 270
these failure conditions; the only recourse is for the task caller to re-execute the
task. When a task is re-executed, no assumptions are made about the state of a
computer-account object in the domain.
All domain-join tasks that are described in this document make reasonable efforts
in the face of failure to restore local client state to the original starting state. If
those efforts fail, administrator intervention (outside the scope of the task) might
be necessary. Similarly, if a task successfully creates or modifies a computer
account object in the domain but then fails in a later step, the task makes
reasonable efforts to either disable or delete the computer account object.
Failure to disable or delete the computer account object in that case might
require domain administrator intervention (outside the scope of the task) to apply
the changes manually.
65 Coherency Requirements
Coherency requirements exist for shared state between the protocols that
comprise the Active Directory system. As a general requirement, when multiple
protocols share state and one of the protocols performs an operation on that
shared state that is specified as atomic in that protocol's Technical Documents,
other protocols that share that state have to honor the atomicity of that
transaction. They must not attempt to perform operations on the uncommitted
transaction or expose the uncommitted transaction to the client's view. For
example, because SAMR and LDAP share state, the SAMR protocol methods to
retrieve information about users can be used to view users that are created by
LDAP as well as by SAMR. Because the creation of a directory object via LDAP is
specified as an atomic transaction ([MS-ADTS] section 3.1.1.5.1.3), a user that is in
the process of being created by LDAP must not be visible via SAMR until the
atomic transaction is committed.
The system exposes the same view of the shared state via all the protocols that
share that state. This means that all committed changes to the shared state are
visible (subject to access-control restrictions) through all protocols that share that
state, and no uncommitted changes are visible through any of the protocols that
share that state. This does not require that all state be visible through all
protocols, but rather that if a piece of state is specified as being visible through

Page | 271
two or more protocols, then that state has to be the same when viewed through
any of those protocols (subject to access-control restrictions).
State is shared transitively. If one abstract data model has a field that shares state
with a field in a second abstract data model, and a third abstract data model also
shares state with that field in the second model, then transitively the first and
third abstract data models share state.
66 Security
This section documents system-wide security issues that are not otherwise
described in the Technical Documents (TDs) for the member protocols. It does not
duplicate what is already in the protocol TDs unless there is some unique aspect
that applies to the system as a whole.
Security is vital to the Active Directory system. As a central repository of account
information for the domain, a compromise of the system could, in turn, permit
the compromise of other systems that are dependent on the Active Directory
system for authentication. If a hostile party can create an account in the
directory, or gain access to an existing account, they might be granted access to
systems to which they should not have access. If they can modify configuration
information stored in the directory by other systems, such as the Group Policy
system [MS-GPOD], they can exert control over the behavior of those systems.
The directory can also contain sensitive information to which read access should
be restricted.
In addition, interaction with a domain controller includes certain constraints that
affect the security of a distributed system and the domain as a whole. Because
the domain controller serves as the root of trust for the entire domain, and
potentially additional domains that are based on trust relationships, great
attention has to be paid to the correctness of the implementation of all the
member protocols. Any security flaw in the implementation could compromise
the entire domain. When beginning any interaction with the domain controller,
the domain client is in a tenuous state. It needs to establish a connection and
authenticate in such a way that prevents attackers from manipulating the
messages that are exchanged between the client and the domain controller.
It is crucial, therefore, that an implementation of the Active Directory system be
resilient to attack. Such an implementation has to be designed and written with

Page | 272
the expectation that it will be subject to hostile network traffic from an adversary
that is intent on compromising it.
To mitigate these threats, the system contains a set of security mechanisms to
restrict access to information that is stored in the directory. The system's
protocols use these mechanisms to restrict access to only those users who are
authorized to have it. Such access restrictions can be specified not only at the
level of individual directory objects but also at the level of individual attributes
on a directory object. The system also provides a means to secure the network
traffic in the system against eavesdropping and tampering.
The following sections describe in more detail the security mechanisms and
conditions in the Active Directory system.

67 Security Elements
Directory objects are protected by security descriptors that contain access
control lists (ACLs) that grant or deny permissions to security principals, either
directly or through group membership, to read, update, or otherwise manipulate
the object, as described in [MS-ADTS] section 5.1.3. However, it is the decision of
the individual protocol what access checks to enforce when accessing the
directory. That is, while some protocols enforce the authorization checks
described in [MS-ADTS], other protocols substitute their own access checks, as
described in that individual protocol's Technical Document.
In the Active Directory system, the following protocols perform access checks, as
described in [MS-ADTS] section 5.1.3:
▪ LDAP [LDAP]
▪ WS-Transfer [WXFR]
▪ WS-Enumeration [WSENUM]
▪ ADCAP [MS-ADCAP]
The following protocols substitute, in full or in part, a different access check
methodology, as described in the protocol's Technical Document:
▪ DRSR [MS-DRSR]

Page | 273
▪ SAMR [MS-SAMR]
▪ SAMS [MS-SAMS]
▪ LSAD [MS-LSAD]
▪ LSAT [MS-LSAT]
▪ DSSP [MS-DSSP]
When performing an access check, the identity of the requestor, represented as a
security identifier (SID), is used to compare the permissions that are required to
perform a given operation to the permissions that are granted to that identity, in
accord with the access check rules of the protocol in use. Each protocol specifies a
means by which a requestor can prove (authenticate) its identity to the directory
service so that the identity can be used in subsequent access check decisions.
Each protocol's means of authentication is described in the corresponding
protocol document, except that for WS-Transfer, WS-Enumeration, and ADCAP, it
is instead described in [MS-ADDM] section 2.1.
The protocols provide mechanisms to digitally sign requests and responses to
protect them from tampering while they are transferred over the network and to
encrypt the traffic to prevent eavesdropping. For more information, see section
2.11.2.

68 Communications Security
The Active Directory system relies on messages that are passed across the
network between the client and the directory service and from one directory
service server to another. The system does not require this network to be fully
trusted and allows for the possibility that a hostile party might be able to
intercept such messages while they are transferred. Most of the protocols in the
Active Directory system are designed to protect against two key attacks from such
an attacker:
▪ Eavesdropping on the messages to gain information that the attacker is not
intended to have.
▪ Altering request or response messages to cause the directory service or client,
respectively, to take action based on information supplied by the attacker.

Page | 274
To protect against these attacks, the system uses transport- and message-level
security features to protect traffic between the clients and the directory service,
and between directory service servers. Transport-level security protects the entire
transport, effectively creating a protected "tunnel" between machines through
which the messages are sent, protecting the confidentially and integrity of the
messages sent through the tunnel. Message-level security encrypts and/or
digitally signs each individual message to provide confidentially and integrity of
the message, respectively.
There is no single transport- or message-level mechanism that is used throughout
all the protocols that comprise the Active Directory system. The following table
summarizes the mechanisms that are used in each protocol. It includes a
reference to the relevant section of the protocol Technical Documents for more
information.

Page | 275
Figure 42: Message flow for provisioning a user account by using the SAMR
protocol
Sequence of Events
The following sequence diagram depicts the message flow that is associated with
this example.

Page | 276
Figure 43: Message flow for changing a user account's password

Page | 277
Figure 44: Message flow to change a user account's password

Page | 278
Figure 45: User lastLogonTimeStamp update message flow

Page | 279
Figure 46: Message flow for determining the group membership of a user
Sequence of Events
The following sequence diagram shows the message flow that is associated with
this example.

Page | 280
Figure 47: Message flow for deleting a user account

Page | 281
Figure 48: Communication flow for obtaining a list of user accounts by using the
Web Services protocols

Page | 282
Figure 49: Message flow for obtaining a list of user accounts using LDAP

Page | 283
Figure 50: Communication flow to manage groups and their memberships

Page | 284
Figure 51: Message flow to delete a security group

Figure 52: Message flow for extending the schema by adding an attribute

Page | 285
Figure 53: Message flow for extending the schema by adding an attribute to a
class

Page | 286
Figure 54: Message flow for partitioning directory data

Page | 287
Figure 55: Message flow for storing application data in the directory
Sequence of Events
The following sequence diagram shows the message flow that is associated with
this example.

Page | 288
Figure 56: Message flow to manage access control on a directory object

Note Some client and server implementations use a different set of messages
at this point in the exchange, as shown in the following sequence diagram
fragment. <9>

Figure 57: Partial, previous message flow to manage access control on a

directory object

Page | 289
Figure 58: Message flow to raise the domain functional level

Page | 290
Figure 59: Message flow for replication changes within a domain

Page | 291
Figure 60: Message flow for transferring FSMO roles

69 Example 22: Replicate Changes to a GC or a Partial Replica by Using SMTP

This example describes how replication is performed between a full replica
domain controller (DC1) and a partial replica domain controller (DC2) by using the
SMTP transport.

Page | 292
This example covers the use case in section 2.7.5.2, Replicate Changes to a GC or
a Partial Replica Using RPC - Domain Controller, specifically, the SMTP variation.
Prerequisites
The general requirements described in section 2.6, Assumptions and
Preconditions.
The Active Directory system meets all preconditions described in the variation of
section 2.7.5.2.
Initial State
DC1 has originating updates that have not yet been replicated to DC2.
Final State
The originating updates on DC1 are replicated to DC2.
Sequence of events
The following sequence diagram shows the message flow that is associated with
this example.

Figure 61: Message flow to replicate changes to a GC or a partial replica

1. DC1 sends an SRV query request to the Domain Name System (DNS) server to
obtain the IP address of DC2.

Page | 293
What about Microsoft LAPS?

There is also Microsoft's own Local Administrator Password Solution (LAPS).

LAPS is free. You can get technical support when using LAPS, and it comes with
a GUI client for admins as well as a PowerShell module.

However, note that LAPS 1) stores passwords in plaintext in the Active Directory
database, using AD permissions to restrict access to the passwords, 2) requires
an update to the Active Directory schema, 3) requires a Group Policy client-side
extension to be installed (an MSI package) on all managed hosts, 4) is not for
stand-alone servers or workstations because of the Active Directory and Group
Policy components, 5) can only be used to manage one local user account on
each machine, no more, 6) we don't have access to the C++ source code of the
LAPS client-side extension if we need to customize it, and 7) though the LAPS
tools themselves encrypt passwords while in transit over the network, admins
must take care to use network encryption when using other tools when reading
the passwords out of AD, e.g., a third-party utility might use LDAP in plaintext by
default (this has nothing to do with LAPS per se, it's only something to be aware
of).

The solution presented below never stores or transmits passwords in plaintext,

not even temporarily, does not require an Active Directory schema update (or AD
for that matter), does not require a Group Policy extension, works on stand-alone
computers, can manage any number of local user accounts, you have access to
the PowerShell source code for inspection or customization (it's in the public
domain), and it works with any SMB server, including Samba and TrueNAS.

However, the solution does require, at a minimum, PowerShell to be on every

managed host, and it scales best in an Active Directory environment with Group
Policy. You will also need a digital certificate, either self-signed or from a PKI,
but this is a good thing because it uses the public key from the certificate for
encryption.

If the choice is between LAPS and doing nothing, then LAPS is far better than
nothing. The PowerShell solution here is better though.

Page | 294
Solution

A trusted administrator should obtain or create a certificate and private key, then
export that certificate to a .CER file into a shared folder (\\server\share\cert.cer).
Any certificate from any source will do, but a 2048-bit or larger RSA public key
from one's own PKI is preferred.

Copy the Update-PasswordArchive.ps1 script into that shared folder

(\\server\share).

Using Group Policy, SCCM, a third-party EMS, schtasks.exe or some other

technique, create a scheduled job on every computer that runs once per week (or
every night) under Local System context which executes the following
command:
powershell.exe \\server\share\Update-PasswordArchive.ps1 -CertificateFilePath
\\server\share\cert.cer
-PasswordArchivePath \\server\share -LocalUsername Administrator

This resets the password on the local Administrator account (or whatever
account is specified at the command line) with a 15-25 character, random
complex password. The password is encrypted in memory with the public key of
the certificate (cert.cer) and saved to an archive file to the specified share
(\\server\share).

When a password for a computer (for example, laptop47) needs to be recovered,

the trusted administrator should run the following PowerShell script on the
administrator's local workstation:
Recover-PasswordArchive.ps1 -PasswordArchivePath \\server\share -Computername
laptop47 -Username administrator

This downloads the necessary encrypted files, decrypts them locally in memory
using the private key of the administrator, then outputs the plaintext password
within PowerShell. The password can then be piped into other commands to
open an RDP session, copy files, execute another command, etc.

Requirements

Page | 295
PowerShell 2.0 or later must be installed on both the computer with the local
user account whose password is to be reset and also on the administrators'
computers who will recover these passwords in plaintext.

The Update-PasswordArchive.ps1 script, which resets the password, must run

with administrative or Local System privileges.

The private key for the certificate cannot be managed by a Cryptography Next
Generation (CNG) key storage provider, such as the Microsoft Software Key
Storage Provider or Enhanced Cryptographic Provider.

Also, the certificate you use must have the "Key Encipherment" purpose in the
"Key Usage" list in the properties of that certificate (see the Details tab). You get
this when the template for the certificate on the Certification Authority (CA) has
"Encryption" listed as an allowed purpose in the properties of that template (see
the Request Handling tab in the properties of the certificate template).

Note that the scripts are not compatible with FIPS Mode being enabled in
Windows.

Testing Example

From the SEC505 zip file, copy the Day3\UpdatePasswords folder to your hard
drive.

In File Explorer, double-click the "Password-is-password.pfx" file to import the

test certificate and private key into your current user store (accept all the
defaults). The password is "password".

Open PowerShell with administrative privileges and run this command to reset
the password on the Guest account:
.\Update-PasswordArchive.ps1 -LocalUserName Guest -CertificateFilePath
.\PublicKeyCert.cer

Do a "dir" listing and you will see a new file with a very long name, similar to the
following:
MYCOMPUTER+Guest+635108515647128197+F5FF0247B0CF6A8D2EBA4A141CB095F3

Page | 296
If you open the file in Notepad or a hex editor, you'll see that it has been
encrypted with the public key in the PublicKeyCert.cer file. The private key for
this public key has already been imported into your local user certificate store,
hence, you can use your private key to extract the password from the encrypted
file. Unless hackers have stolen your private key, they will not be able to decrypt
the file and obtain the password inside it.

To obtain the plaintext password, run this command:

.\Recover-PasswordArchive.ps1 -ComputerName $env:computername -UserName Guest

The output is an object with the plaintext password and other properties, similar
to this:
ComputerName : MYCOMPUTER

FilePath : MYCOMPUTER+Guest+635108515647128197+F5FF024E83D2EBA4A141CB095F3

UserName : Guest

TimeStamp : 7/31/2021 7:12:44 AM

Thumbprint : F5FF0247B0CF6A81148CE83D2EBA4A141CB095F3

Valid : True

Password : TheRandomComplexPassword

The password property can now be piped into other commands or copied into
the wetware clipboard through your retina.

To see the full help for this script, run:

get-help -full .\Update-PasswordArchive.ps1
Notes

The password is never sent over the network in plaintext, never saved to disk in
plaintext, and never exposed as a command-line argument, either when
resetting the password or when recovering it later. The new password is
generated randomly in the memory of the PowerShell process running on the
computer where the password is reset. The process runs for less than a second
as Local System as a background process.

Page | 297
Different certificates can be used at different times, as long as their private keys
are available to the administrator. When recovering a password, the correct
certificate and private key will be used automatically, even if multiple
certificates are in use. A smart card can be used too. The script has been
successfully tested with the Common Access Card (CAC) used by the U.S. military
and DoD. It also works with YubiKeys.

If the shared folder is not accessible to the computer when the scheduled job
runs, the password is not reset. The script first tests access to the shared folder
before resetting the password.

If multiple administrators must be able to recover the plaintext passwords,

export the relevant certificate and private key to a PFX file and import it into
each administrator's local profile. Because this is not a certificate used to
uniquely identify a person or device (non-repudiation is not an intended feature),
everyone on the help desk could have a copy of its private key.

To delegate authority to different administrators over different computers, then

simply use different public/private key pairs. When using Group Policy to create
the scheduled job on the machines in an organizational unit, for example, any
certificate can be specified, and this does not have to be the same certificate
used for all machines in a domain. The corresponding private keys can be shared
with whatever subset of administrators is desired. If the private key is on a smart
card, that card can be physically protected from unauthorized admins.

The password update script writes to the local Application event log on the
machine where it runs (Source: PasswordArchive, Event ID: 9013). When the
password is used to log into the computer, this can also be logged if the
appropriate audit policies are enabled. The SEC505 zip file includes another
script (SendTo-SysLog.ps1) if you'd like to modify the update script to also send
a syslog message whenever the script runs.

The script can only be used to reset the passwords of local accounts, not domain
accounts in Active Directory, though it could be modified for this purpose.

Threats

Page | 298
Keep the private key for the certificate used to encrypt the password archive
files secure, such as on a smart card. This is the most important factor. Do not
use the sample keys provided here for anything other than testing.

If the private key for the certificate is compromised, create a new key pair,
replace the certificate file (.CER) in the shared folder, and immediately remotely
trigger the scheduled job on all machines using PowerShell remoting, Group
Policy, schtasks.exe or some other tool. Once all passwords have been changed,
the fact that the old private key has been compromised does not mean any
current passwords are known.

Use an RSA public key at least 2048 bits in size. The public key encrypts the
random 256-bit Rijndael key in each file which is used to encrypt the password
in that file. Each archive file has a different Rijndael key. RSA and Rijndael are
used for backwards compatibility (using AES explicitly requires .NET Framework
3.5 or later). Rijndael was selected by NIST for the AES cipher.

Prevent modification of the Update-PasswordArchive.ps1 script itself by digitally

signing the script, enforcing script signature requirements, and using restrictive
NTFS permissions. Only allow NTFS read access to the script to those identities
(computer accounts) which need to run it. Use NTFS auditing to track changes to
the script.

Attackers may try to corrupt the existing password archive files to prevent access
to current passwords. Each archive file contains an encrypted SHA256 hash of
the username, computer name, and password in that file in order to detect bit-
flipping attacks; the hash is checked whenever a password is recovered.

To deter file deletion, it's best to store the certificate and archive files in a
shared folder whose NTFS permissions only allow the client computer accounts
the following permissions:

Principal: Domain Computers

Apply to: This folder, subfolders and files
Allow: Full Control
Deny: Delete subfolders and files
Deny: Delete
Deny: Change permissions

Page | 299
Deny: Take ownership
Deny: Create folders/append data

Principal: Domain Computers

Apply to: Files only
Deny: Create files/write data

The trusted administrators can be granted Full Control to the archive files,
certificates, and scripts as needed of course. The above permissions are for just
for Domain Computers.

An attacker might try to generate millions of spoofed archive files and add them
to the shared folder. This is possible because the script and public key would be
accessible to the attacker too. NTFS auditing on the share can log which
computer(s) added the spoofed files and when. The archive files might be
digitally signed, but with what key? We must assume the attacker can extract
any signing keys from kernel memory on the computers that have already been
compromised. Realistically, though, a DoS attack in which millions of new
archive files are created would likely be of low value for the attacker since it
would be easy to detect, easy to log the name or IP of the machine creating the
new files, easy to use timestamps in the shared folder to identify post-attack
files, nightly backups of the archive files can be retained for months, and the
DoS attack would not allow the hacker to expand the hacker's existing control
over new machines. Besides, the benefit to us of managing local administrative
account passwords correctly far exceeds the potential negative of this sort of
DoS attack.

IPsec permissions that limit access to the SMB ports of the file server is
recommended, but not for the encryption, but for restricting access to the SMB
ports (TCP 139/445) based on group memberhips, e.g., domain computer,
administrators, help desk personnel, etc.

Tips

The output of the Recover-PasswordArchive.ps1 script can be piped into other

scripts to automate other tasks which require the plaintext password, such as
executing commands, doing WMI queries, opening an RDP session, or
immediately resetting the password again when finished.

Page | 300
When recovering a password, you can pipe the password into Set-Clipboard or
the built-in clip.exe utility to put the password into the clipboard, like this:
\\controller\password-archives\Recover-PasswordArchive.ps1 -
PasswordArchivePath \controller\password-archives -ComputerName laptop47 -
UserName Administrator | Select-Object -ExpandProperty password | clip.exe

What prevents an endless accumulation of encrypted password archive files in

the shared folder? The CleanUp-PasswordArchives.ps1 script will remove older
or obsolete archive files which are no longer needed. Run this script as a
scheduled job once per month. See the help in that script for its command-line
parameters to customize what it deletes, e.g., by default it keeps the last five
password archive files for each computer and username combination, but this
can be changed.

To optimize the performance of the Recover-PasswordArchive.ps1 script when

there are more than 100,000 files in the folder containing the password archives,
disable 8.3 file name generation and strip all current 8.3 names on the volume
containing that folder. Search the Internet on "fsutil.exe 8dot3name" to see how.

To maximize fault tolerance and scalability, use Distributed File System

(DFS) shared folders across two or more servers, and back up the folder at least
weekly. You can also use SMB with TrueNAS, Ceph or Gluster. With Group Policy
or Intune management of the scheduled jobs, the solution can scale to large
networks.

The solution works on stand-alone computers as well, but the scheduled task,
shared folder, and permissions will need to handled appropriately; for example,
a wrapper script will likely be needed to automate the creation of the scheduled
task and the copying of the encrypted password file to some kind of archival
server, perhaps via SSH.

You can also perform an immediate password update with commands like these,
but wrapped in a function or placed in another script:
Copy-Item -Path .PublicKeyCert.cer -Destination \\laptop47\c$

Invoke-Command -ComputerName laptop47 -filepath .\Update-PasswordArchive.ps1

-argumentlist "C:\publickeycert.cer","Administrator","c:"

Page | 301
Copy-Item -Path \\laptop47\c$\laptop47+Administrator+* -Destination
C:\LocalFolder

Remove-Item -Path \\laptop47\c$\PublicKeyCert.cer

Remove-Item -Path \\laptop47\c$\laptop47+Administrator+*

The above Invoke-Command can be done by specifying UNC paths instead, but
this requires delegation of credentials to the remote computer, which is not
ideal for limiting token abuse attacks, so the certificate and archive files should
be copied back-and-forth manually. Besides, wrapped in a function or script with
some error-handling code, all these steps would be hidden from us anyway.

Each password archive file name includes a ticks timestamp number. To

manually convert the ticks timestamp in the file name (e.g.,
635093865618276588) to a human-readable date and time in PowerShell, run
this command:
[DateTime][Int64] 635093865618276588

If all the password archive files are moved to another volume, it would be
convenient to reset the NTFS LastWriteTime property of the archive files to
match the ticks timestamp in the archive file names themselves, such as with
this command:
dir *+*+* | foreach { $_.LastWriteTime = [DateTime][Int64] $(($_.Name -split
'+')[2]) }

If you would prefer a non-PowerShell commercial product to manage admin

passwords, here are few to consider:

Page | 302
 • Synergix
• ManageEngine Password Manager Pro
• Cyber-Ark Privileged Identity/Session Management
• Lieberman Software Password Manager
• Thycotic Secret Server
• PasswordCourier Password Management
• NetWrix Privileged Account Manager
• AutoCipher

Remote Server Administration Tools for Windows 10

Important! Selecting a language below will dynamically change the complete page
content to that language.
Select Language:
[Control]

DownloadDirectX End-User Runtime Web Installer

IMPORTANT: Starting with Windows 10 October 2018 Update, RSAT is included as
a set of "Features on Demand" in Windows 10 itself. See "Install Instructions"
below for details, and "Additional Information" for recommendations and
troubleshooting. RSAT lets IT admins manage Windows Server roles and features
from a Windows 10 PC.
Details
Note: There are multiple files available for this download. Once you click on the
"Download" button, you will be prompted to select the files you need.
Version:
1803 1.0
File Name:
WindowsTH-KB2693643-x64.msu
WindowsTH-KB2693643-x86.msu
Date Published:
1/11/2022
File Size:
61.1 MB

Page | 303
 39.2 MB
Remote Server Administration Tools for Windows 10 includes Server Manager,
Microsoft Management Console (MMC) snap-ins, consoles, Windows PowerShell
cmdlets and providers, and command-line tools for managing roles and features
that run on Windows Server.

IMPORTANT: Starting with Windows 10 October 2018 Update, add RSAT tools
right from Windows 10. Just go to "Manage optional features" in Settings and
click "Add a feature" to see the list of available RSAT tools.

The downloadable packages above can still be used to install RSAT on Windows
10 version 1607.

System Requirements
Supported Operating System
Windows 10
**Remote Server Administration Tools for Windows 10 can be installed ONLY on
computers that are running the full release of Windows 10 Professional,
Windows 10 Enterprise, or Windows 10 Education.** Remote Server
Administration Tools cannot be installed on Windows RT, computers with an
Advanced RISC Machine (ARM) architecture, or other system-on-chip devices.

Remote Server Administration Tools for Windows 10 runs on both x86- and x64-
based editions of the full release of Windows 10, Professional, Enterprise or
Education editions. Download and install the version that matches the
architecture of the computer on which you plan to install the administration
tools. If you are not sure whether your computer is x86- or x64-based, see How to
determine whether a computer is running a 32-bit version or 64-bit version of the
Windows operating system.

Remote Server Administration Tools for Windows 10 is available in the following

languages: cs-CZ, de-DE, en-US, es-ES, fr-FR, hu-HU, it-IT, ja-JP, ko-KR, nl-NL, pl-PL,
pt-BR, pt-PT, ru-RU, sv-SE, tr-TR, zh-CN, and zh-TW. If the system UI language of
your Windows 10 operating system does not match any of the available RSAT
languages, you must first install a Windows 10 Language Pack for a language that
is supported by RSAT, and then try installing Remote Server Administration Tools
for Windows 10 again.

Page | 304
IMPORTANT: Remove all older versions of Administration Tools Pack or Remote
Server Administration Tools—including older prerelease versions, and releases of
the tools for different languages or locales—from the computer before you install
Remote Server Administration Tools for Windows 10. Only one copy at a time of
Remote Server Administration Tools can be installed on a computer. If you have
upgraded to Windows 10 from an older release of Windows, you will need to
install Remote Server Administration Tools for Windows 10 on the computer; no
earlier releases of Remote Server Administration Tools are still installed on a
computer that you have upgraded to Windows 10.

Remote Server Administration Tools for Windows 10 includes support for remote
management of computers that are running Windows Server. It can be installed
on Windows 10, but it cannot be installed on Windows Server.

Earlier releases of Remote Server Administration Tools (such as those for

Windows 8.1) are not available--nor do they run--on Windows 10.

Server Manager is included with Remote Server Administration Tools for

Windows 10; GUI-based tools that are part of this release of Remote Server
Administration Tools can be opened by using commands on the Tools menu of the
Server Manager console. To use Server Manager to access and manage remote
servers that are running Windows Server 2008, Windows Server 2008 R2,
Windows Server 2012, or Windows Server 2012 R2, you must install several
updates on the older operating systems. For more information about
requirements for using Server Manager to manage remote servers, see Manage
multiple, remote servers with Server Manager.
Install Instructions
•
NOTE: Please refer to the "Additional Information" section below for
troubleshooting and known issue.

----------

To install specific RSAT tools on Windows 10 October 2018 Update or later

Starting with Windows 10 October 2018 Update, RSAT is included as a set of

Page | 305
"Features on Demand" right from Windows 10. Do not download an RSAT
package from this page. Instead, just go to "Manage optional features" in Settings
and click "Add a feature" to see the list of available RSAT tools. Select and install
the specific RSAT tools you need. To see installation progress, click the Back
button to view status on the "Manage optional features" page.

See the list of RSAT tools available via Features on Demand. In addition to
installing via the graphical Settings app, you can also install specific RSAT tools via
command line or automation using DISM /Add-Capability.

One benefit of Features on Demand is that installed features persist across

Windows 10 version upgrades!

To uninstall specific RSAT tools on Windows 10 October 2018 Update or later

On Windows 10, open the Settings app, go to "Manage optional features", select
and uninstall the specific RSAT tools you wish to remove. Note that in some cases,
you will need to manually uninstall dependencies. Specifically, if RSAT tool A is
needed by RSAT tool B, then choosing to uninstall RSAT tool A will fail if RSAT tool
B is still installed. In this case, uninstall RSAT tool B first, and then uninstall RSAT
tool A. Also note that in some cases, uninstalling an RSAT tool may appear to
succeed even though the tool is still installed. In this case, restarting the PC will
complete the removal of the tool.

See the list of RSAT tools including dependencies. In addition to uninstalling via
the graphical Settings app, you can also uninstall specific RSAT tools via command
line or automation using DISM /Remove-Capability.

Page | 306
+41 43 508 3472
Fra Lightweight Directory Access Protocol
From Wikipedia, the free encyclopedia

Lightweight Directory Access Protocol

Communication protocol

Purpose Directory service

Based on X.500

OSI layer Application layer

Port(s) 389 (ldap), 636 (ldaps)

RFC(s) RFC 4510, RFC 4511

The Lightweight Directory Access Protocol (LDAP /ˈɛldæp/) is an open, vendor-

neutral, industry standard application protocol for accessing and maintaining
distributed directory information services over an Internet Protocol (IP)
network.[1] Directory services play an important role in developing intranet and
Internet applications by allowing the sharing of information about users, systems,
networks, services, and applications throughout the network.[2] As examples,
directory services may provide any organized set of records, often with a
hierarchical structure, such as a corporate email directory. Similarly, a telephone
directory is a list of subscribers with an address and a phone number.

Page | 307
LDAP is specified in a series of Internet Engineering Task Force (IETF) Standard
Track publications called Request for Comments (RFCs), using the description
language ASN.1. The latest specification is Version 3, published as RFC 4511[3] (a
road map to the technical specifications is provided by RFC4510).
A common use of LDAP is to provide a central place to store usernames and
passwords. This allows many different applications and services to connect to the
LDAP server to validate users.[4]
LDAP is based on a simpler subset of the standards contained within
the X.500 standard. Because of this relationship, LDAP is sometimes called X.500-
lite.[5]

Contents

• 1History
• 2Protocol overview
• 3Directory structure
• 4Operations
o 4.1Add
o 4.2Bind (authenticate)
o 4.3Delete
o 4.4Search and compare
o 4.5Modify
o 4.6Modify DN
o 4.7Extended operations
▪ 4.7.1StartTLS
o 4.8Abandon
o 4.9Unbind
• 5URI scheme
• 6Schema
• 7Variations
• 8Other data models
• 9Usage
• 10See also
• 11References

Page | 308
 o 11.1Sources
• 12Further reading
• 13External links

History
Telecommunication companies' understanding of directory requirements were
well developed after some 70 years of producing and managing telephone
directories. These companies introduced the concept of directory services
to information technology and computer networking, their input culminating in
the comprehensive X.500 specification,[6] a suite of protocols produced by
the International Telecommunication Union (ITU) in the 1980s.
X.500 directory services were traditionally accessed via the X.500 Directory Access
Protocol (DAP), which required the Open Systems Interconnection (OSI) protocol
stack. LDAP was originally intended to be a lightweight alternative protocol for
accessing X.500 directory services through the simpler (and now
widespread) TCP/IP protocol stack. This model of directory access was borrowed
from the DIXIE and Directory Assistance Service protocols.
The protocol was originally created[7] by Tim Howes of the University of
Michigan, Steve Kille of Isode Limited, Colin Robbins of Nexor and Wengyik
Yeong of Performance Systems International, circa 1993, as a
successor[8] to DIXIE and DAS. Mark Wahl of Critical Angle Inc., Tim Howes, and
Steve Kille started work in 1996 on a new version of LDAP, LDAPv3, under the
aegis of the Internet Engineering Task Force (IETF). LDAPv3, first published in
1997, superseded LDAPv2 and added support for extensibility, integrated
the Simple Authentication and Security Layer, and better aligned the protocol to
the 1993 edition of X.500. Further development of the LDAPv3 specifications
themselves and of numerous extensions adding features to LDAPv3 has come
through the IETF.
In the early engineering stages of LDAP, it was known as Lightweight Directory
Browsing Protocol, or LDBP. It was renamed with the expansion of the scope of
the protocol beyond directory browsing and searching, to include directory
update functions. It was given its Lightweight name because it was not as network
intensive as its DAP predecessor and thus was more easily implemented over the
Internet due to its relatively modest bandwidth usage.
LDAP has influenced subsequent Internet protocols, including later versions of
X.500, XML Enabled Directory (XED), Directory Service Markup

Page | 309
Language (DSML), Service Provisioning Markup Language (SPML), and the Service
Location Protocol (SLP). It is also used as the basis for Microsoft's Active Directory.

Protocol overview[edit]
A client starts an LDAP session by connecting to an LDAP server, called a Directory
System Agent (DSA), by default on TCP and UDP port 389, or on port 636
for LDAPS (LDAP over TLS/SSL, see below).[9] The client then sends an operation
request to the server, and a server sends responses in return. With some
exceptions, the client does not need to wait for a response before sending the
next request, and the server may send the responses in any order. All information
is transmitted using Basic Encoding Rules (BER).
The client may request the following operations:

• StartTLS – use the LDAPv3 Transport Layer Security (TLS) extension for a
secure connection
• Bind – authenticate and specify LDAP protocol version
• Search – search for and/or retrieve directory entries
• Compare – test if a named entry contains a given attribute value
• Add a new entry
• Delete an entry
• Modify an entry
• Modify Distinguished Name (DN) – move or rename an entry
• Abandon – abort a previous request
• Extended Operation – generic operation used to define other operations
• Unbind – close the connection (not the inverse of Bind)
In addition the server may send "Unsolicited Notifications" that are not responses
to any request, e.g. before the connection is timed out.
A common alternative method of securing LDAP communication is using
an SSL tunnel. The default port for LDAP over SSL is 636. The use of LDAP over SSL
was common in LDAP Version 2 (LDAPv2) but it was never standardized in any
formal specification. This usage has been deprecated along with LDAPv2, which
was officially retired in 2003.[10]

Page | 310
Directory structure
The protocol provides an interface with directories that follow the 1993 edition of
the X.500 model:

• An entry consists of a set of attributes.

• An attribute has a name (an attribute type or attribute description) and
one or more values. The attributes are defined in a schema (see below).
• Each entry has a unique identifier: its Distinguished Name (DN). This
consists of its Relative Distinguished Name (RDN), constructed from
some attribute(s) in the entry, followed by the parent entry's DN. Think
of the DN as the full file path and the RDN as its relative filename in its
parent folder (e.g. if /foo/bar/myfile.txt were the DN,
then myfile.txt would be the RDN).
A DN may change over the lifetime of the entry, for instance, when entries are
moved within a tree. To reliably and unambiguously identify entries, a UUID might
be provided in the set of the entry's operational attributes.
An entry can look like this when represented in LDAP Data Interchange
Format (LDIF), a plain text format (as opposed a binary protocol such as LDAP
itself):

dn: cn=John Doe,dc=example,dc=com

cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: [email protected]
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

" dn " is the distinguished name of the entry; it is neither an attribute nor a part of
the entry. " cn=John Doe " is the entry's RDN (Relative Distinguished Name), and

Page | 311
" dc=example,dc=com " is the DN of the parent entry, where " dc " denotes
'Domain Component'. The other lines show the attributes in the entry. Attribute
names are typically mnemonic strings, like " cn " for common name, " dc " for
domain component, " mail " for e-mail address, and " sn " for surname.
A server holds a subtree starting from a specific entry, e.g. " dc=example,dc=com "
and its children. Servers may also hold references to other servers, so an attempt
to access " ou=department,dc=example,dc=com " could return
a referral or continuation reference to a server that holds that part of the
directory tree. The client can then contact the other server. Some servers also
support chaining, which means the server contacts the other server and returns
the results to the client.
LDAP rarely defines any ordering: The server may return the values of an
attribute, the attributes in an entry, and the entries found by a search operation
in any order. This follows from the formal definitions - an entry is defined as
a set of attributes, and an attribute is a set of values, and sets need not be
ordered.

Operations
Add
The ADD operation inserts a new entry into the directory-server database.[11] If
the distinguished name in the add request already exists in the directory, then the
server will not add a duplicate entry but will set the result code in the add result
to decimal 68, "entryAlreadyExists".[12]

• LDAP-compliant servers will never dereference the distinguished name

transmitted in the add request when attempting to locate the entry,
that is, distinguished names are never de-aliased.
• LDAP-compliant servers will ensure that the distinguished name and all
attributes conform to naming standards.
• The entry to be added must not exist, and the immediate superior must
exist.

dn: uid=user,ou=people,dc=example,dc=com
changetype: add
objectClass:top
objectClass:person

Page | 312
uid: user
sn: last-name
cn: common-name
userPassword: password

In the above example, uid=user,ou=people,dc=example,dc=com must not exist,

and ou=people,dc=example,dc=com must exist.
Bind (authenticate)
When an LDAP session is created, that is, when an LDAP client connects to the
server, the authentication state of the session is set to anonymous. The BIND
operation establishes the authentication state for a session.
Simple BIND and SASL PLAIN can send the user's DN and password in plaintext, so
the connections utilizing either Simple or SASL PLAIN should be encrypted
using Transport Layer Security (TLS). The server typically checks the password
against the userPassword attribute in the named entry. Anonymous BIND (with
empty DN and password) resets the connection to anonymous state.
SASL (Simple Authentication and Security Layer) BIND provides authentication
services through a wide range of mechanisms, e.g. Kerberos or the client
certificate sent with TLS.[13]
BIND also sets the LDAP protocol version by sending a version number in the form
of an integer. If the client requests a version that the server does not support, the
server must set the result code in the BIND response to the code for a protocol
error. Normally clients should use LDAPv3, which is the default in the protocol but
not always in LDAP libraries.
BIND had to be the first operation in a session in LDAPv2, but is not required as of
LDAPv3. In LDAPv3, each successful BIND request changes the authentication
state of the session and each unsuccessful BIND request resets the authentication
state of the session.
Delete
To delete an entry, an LDAP client transmits a properly formed delete request to
the server.[14]

• A delete request must contain the distinguished name of the entry to be

deleted

Page | 313
 • Request controls may also be attached to the delete request
• Servers do not dereference aliases when processing a delete request
• Only leaf entries (entries with no subordinates) may be deleted by a
delete request. Some servers support an operational
attribute hasSubordinates whose value indicates whether an entry has
any subordinate entries, and some servers support an operational
attribute numSubordinates [15] indicating the number of entries
subordinate to the entry containing the numSubordinates attribute.
• Some servers support the subtree delete request control permitting
deletion of the DN and all objects subordinate to the DN, subject to
access controls. Delete requests are subject to access controls, that is,
whether a connection with a given authentication state will be
permitted to delete a given entry is governed by server-specific access
control mechanisms.
Search and compare
The Search operation is used to both search for and read entries. Its parameters
are:
baseObject
The name of the base object entry (or possibly the root) relative to which
the search is to be performed.
scope
What elements below the baseObject to search. This can
be BaseObject (search just the named entry, typically used to read one
entry), singleLevel (entries immediately below the base DN),
or wholeSubtree (the entire subtree starting at the base DN).
filter
Criteria to use in selecting elements within scope. For example, the
filter (&(objectClass=person)(|(givenName=John)(mail=john*))) will select
"persons" (elements of objectClass person ) where the matching rules
for givenName and mail determine whether the values for those
attributes match the filter assertion. Note that a common misconception is
that LDAP data is case-sensitive, whereas in fact matching rules and
ordering rules determine matching, comparisons, and relative value

Page | 314
 relationships. If the example filters were required to match the case of the
attribute value, an extensible match filter must be used, for
example, (&(objectClass=person)(|(givenName:caseExactMatch:=John)(ma
il:caseExactSubstringsMatch:=john*)))
derefAliases
Whether and how to follow alias entries (entries that refer to other
entries),
attributes
Which attributes to return in result entries.
sizeLimit, timeLimit
Maximum number of entries to return, and maximum time to allow search
to run. These values, however, cannot override any restrictions the server
places on size limit and time limit.
typesOnly
Return attribute types only, not attribute values.
The server returns the matching entries and potentially
continuation references. These may be returned in any
order. The final result will include the result code.
The Compare operation takes a DN, an attribute name
and an attribute value, and checks if the named entry
contains that attribute with that value.
Modify[edit]
The MODIFY operation is used by LDAP clients to request
that the LDAP server make changes to existing
entries.[16] Attempts to modify entries that do not exist
will fail. MODIFY requests are subject to access controls as
implemented by the server.
The MODIFY operation requires that the distinguished
name (DN) of the entry be specified, and a sequence of
changes. Each change in the sequence must be one of:

• add (add a new value, which must not already

exist in the attribute)
• delete (delete an existing value)

Page | 315
 • replace (replace an existing value with a new
value)
LDIF example of adding a value to an attribute:

dn: dc=example,dc=com
changetype: modify
add: cn
cn: the-new-cn-value-to-be-added
-

To replace the value of an existing attribute, use

the replace keyword. If the attribute is multi-valued, the
client must specify the value of the attribute to update.
To delete an attribute from an entry, use the
keyword delete and the changetype designator modify . If
the attribute is multi-valued, the client must specify the
value of the attribute to delete.
There is also a Modify-Increment extension[17] which
allows an incrementable attribute value to be
incremented by a specified amount. The following
example using LDIF increments employeeNumber by 5 :

dn: uid=user.0,ou=people,dc=example,dc=com
changetype: modify
increment: employeeNumber
employeeNumber: 5
-

When LDAP servers are in a replicated topology, LDAP

clients should consider using the post-read control to
verify updates instead of a search after an update.[18] The
post-read control is designed so that applications need
not issue a search request after an update – it is bad form
to retrieve an entry for the sole purpose of checking that
an update worked because of the replication eventual

Page | 316
 consistency model. An LDAP client should not assume that
it connects to the same directory server for each request
because architects may have placed load-balancers or
LDAP proxies or both between LDAP clients and servers.
Modify DN[edit]
Modify DN (move/rename entry) takes the new RDN
(Relative Distinguished Name), optionally the new
parent's DN, and a flag that indicates whether to delete
the value(s) in the entry that match the old RDN. The
server may support renaming of entire directory subtrees.
An update operation is atomic: Other operations will see
either the new entry or the old one. On the other hand,
LDAP does not define transactions of multiple operations:
If you read an entry and then modify it, another client
may have updated the entry in the meantime. Servers
may implement extensions[19] that support this, though.
Extended operations[edit]
The Extended Operation is a generic LDAP operation that
can define new operations that were not part of the
original protocol specification. StartTLS is one of the most
significant extensions. Other examples include Cancel and
Password Modify.
StartTLS[edit]
The StartTLS operation establishes Transport Layer
Security (the descendant of SSL) on the connection. It can
provide data confidentiality (to protect data from being
observed by third parties) and/or data integrity protection
(which protects the data from tampering). During TLS
negotiation the server sends its X.509 certificate to prove
its identity. The client may also send a certificate to prove
its identity. After doing so, the client may then
use SASL/EXTERNAL. By using the SASL/EXTERNAL, the
client requests the server derive its identity from
credentials provided at a lower level (such as TLS). Though
technically the server may use any identity information

Page | 317
 established at any lower level, typically the server will use
the identity information established by TLS.
Servers also often support the non-standard "LDAPS"
("Secure LDAP", commonly known as "LDAP over SSL")
protocol on a separate port, by default 636. LDAPS differs
from LDAP in two ways: 1) upon connect, the client and
server establish TLS before any LDAP messages are
transferred (without a StartTLS operation) and 2) the
LDAPS connection must be closed upon TLS closure.
Some "LDAPS" client libraries only encrypt
communication; they do not check the host name against
the name in the supplied certificate.[20]
Abandon[edit]
The Abandon operation requests that the server abort an
operation named by a message ID. The server need not
honor the request. Neither Abandon nor a successfully
abandoned operation send a response. A similar Cancel
extended operation does send responses, but not all
implementations support this.
Unbind[edit]
The Unbind operation abandons any outstanding
operations and closes the connection. It has no response.
The name is of historical origin, and is not the opposite of
the Bind operation.[21]
Clients can abort a session by simply closing the
connection, but they should use Unbind.[22] Unbind allows
the server to gracefully close the connection and free
resources that it would otherwise keep for some time
until discovering the client had abandoned the
connection. It also instructs the server to cancel
operations that can be canceled, and to not send
responses for operations that cannot be canceled.[23]

Page | 318
 URI scheme[edit]
An LDAP uniform resource identifier (URI) scheme exists,
which clients support in varying degrees, and servers
return in referrals and continuation references (see RFC
4516):

ldap://host:port/DN?attributes?scope?filter?extensions

Most of the components described below are optional.

• host is the FQDN or IP address of the LDAP

server to search.
• port is the network port (default port 389) of the
LDAP server.
• DN is the distinguished name to use as the
search base.
• attributes is a comma-separated list of attributes
to retrieve.
• scope specifies the search scope and can be
"base" (the default), "one" or "sub".
• filter is a search filter. For
example, (objectClass=*) as defined in RFC
4515.
• extensions are extensions to the LDAP URL
format.
For example,
" ldap://ldap.example.com/cn=John%20Doe,dc=example,
dc=com " refers to all user attributes in John Doe's entry
in ldap.example.com , while
" ldap:///dc=example,dc=com??sub?(givenName=John) "
searches for the entry in the default server (note the triple
slash, omitting the host, and the double question mark,
omitting the attributes). As in other URLs, special
characters must be percent-encoded.

Page | 319
 There is a similar non-standard ldaps URI scheme for
LDAP over SSL. This should not be confused with LDAP
with TLS, which is achieved using the StartTLS operation
using the standard ldap scheme.

Schema
The contents of the entries in a subtree are governed by
a directory schema, a set of definitions and constraints
concerning the structure of the directory information tree
(DIT).
The schema of a Directory Server defines a set of rules
that govern the kinds of information that the server can
hold. It has a number of elements, including:

• Attribute Syntaxes—Provide information about

the kind of information that can be stored in an
attribute.
• Matching Rules—Provide information about
how to make comparisons against attribute
values.
• Matching Rule Uses—Indicate which attribute
types may be used in conjunction with a
particular matching rule.
• Attribute Types—Define an object
identifier (OID) and a set of names that may
refer to a given attribute, and associates that
attribute with a syntax and set of matching
rules.
• Object Classes—Define named collections of
attributes and classify them into sets of required
and optional attributes.
• Name Forms—Define rules for the set of
attributes that should be included in the RDN for
an entry.

Page | 320
 • Content Rules—Define additional constraints
about the object classes and attributes that may
be used in conjunction with an entry.
• Structure Rule—Define rules that govern the
kinds of subordinate entries that a given entry
may have.
Attributes are the elements responsible for storing
information in a directory, and the schema defines the
rules for which attributes may be used in an entry, the
kinds of values that those attributes may have, and how
clients may interact with those values.
Clients may learn about the schema elements that the
server supports by retrieving an appropriate subschema
subentry.
The schema defines object classes. Each entry must have
an objectClass attribute, containing named classes defined
in the schema. The schema definition of the classes of an
entry defines what kind of object the entry may represent
- e.g. a person, organization or domain. The object class
definitions also define the list of attributes that must
contain values and the list of attributes which may contain
values.
For example, an entry representing a person might belong
to the classes "top" and "person". Membership in the
"person" class would require the entry to contain the "sn"
and "cn" attributes, and allow the entry also to contain
"userPassword", "telephoneNumber", and other
attributes. Since entries may have multiple ObjectClasses
values, each entry has a complex of optional and
mandatory attribute sets formed from the union of the
object classes it represents. ObjectClasses can be
inherited, and a single entry can have multiple
ObjectClasses values that define the available and
required attributes of the entry itself. A parallel to the
schema of an objectClass is a class definition and

Page | 321
 an instance in Object-oriented programming, representing
LDAP objectClass and LDAP entry, respectively.
Directory servers may publish the directory schema
controlling an entry at a base DN given by the entry's
subschemaSubentry operational attribute. (An operational
attribute describes operation of the directory rather than
user information and is only returned from a search when
it is explicitly requested.)
Server administrators can add additional schema entries
in addition to the provided schema elements. A schema
for representing individual people within organizations is
termed a white pages schema.

Variations
A lot of the server operation is left to the implementor or
administrator to decide. Accordingly, servers may be set
up to support a wide variety of scenarios.
For example, data storage in the server is not specified -
the server may use flat files, databases, or just be a
gateway to some other server. Access control is not
standardized, though there has been work on it and there
are commonly used models. Users' passwords may be
stored in their entries or elsewhere. The server may
refuse to perform operations when it wishes, and impose
various limits.
Most parts of LDAP are extensible. Examples: One can
define new operations. Controls may modify requests and
responses, e.g. to request sorted search results. New
search scopes and Bind methods can be defined.
Attributes can have options that may modify their
semantics.

Other data models

As LDAP has gained momentum, vendors have provided it
as an access protocol to other services. The
implementation then recasts the data to mimic the

Page | 322
 LDAP/X.500 model, but how closely this model is followed
varies. For example, there is software to
access SQL databases through LDAP, even though LDAP
does not readily lend itself to this.[24] X.500 servers may
support LDAP as well.
Similarly, data previously held in other types of data
stores are sometimes moved to LDAP directories. For
example, Unix user and group information can be stored
in LDAP and accessed via PAM and NSS modules. LDAP is
often used by other services for authentication and/or
authorization (what actions a given already-authenticated
user can do on what service). For example in Active
Directory Kerberos is used in the authentication step,
while LDAP is used in the authorization step.
An example of such data model is the GLUE
Schema,[25] which is used in a distributed information
system based on LDAP that enable users, applications and
services to discover which services exist in a Grid
infrastructure and further information about their
structure and state.

Usage
An LDAP server may return referrals to other servers for
requests that it cannot fulfill itself. This requires a naming
structure for LDAP entries so one can find a server holding
a given distinguished name (DN), a concept defined in the
X.500 Directory and also used in LDAP. Another way of
locating LDAP servers for an organization is a DNS server
record (SRV).
An organization with the domain example.org may use the
top level LDAP DN dc=example, dc=org (where dc means
domain component). If the LDAP server is also named
ldap.example.org, the organization's top level LDAP URL
becomes ldap://ldap.example.org/dc=example,dc=org .

Page | 323
 Primarily two common styles of naming are used in both
X.500 [2008] and LDAPv3. These are documented in the
ITU specifications and IETF RFCs. The original form takes
the top level object as the country object, such
as c=US , c=FR . The domain component model uses the
model described above. An example of country based
naming could be l=Locality, ou=Some Organizational Unit,
o=Some Organization, c=FR , or in the US: cn=Common
Name, l=Locality, ou=Some Organizational Unit, o=Some
Organization, st=CA, c=US .

See also

• Ambiguous name resolution

• CCSO Nameserver
• Federated Naming Service
• Hesiod (name service)
• Hierarchical database model
• Key server (cryptographic)
• LDAP Application Program Interface
• List of LDAP software
• Simple Authentication and Security Layer (SASL)

References

1. ^ "Network Working Group RFC 4511"

. IETF.org. 2006-06-01. Retrieved 2014-04-

04.

2. ^ "Directory Services LDAP"

. Oracle.com. Retrieved 2014-04-04.

3. ^ What is LDAP?

. Gracion.com. Retrieved on 2013-07-17.

Page | 324
 4. ^ "Introduction to OpenLDAP Directory
Services"

. OpenLDAP. Retrieved 1 February 2016.

5. ^ "LDAP - Lightweight Directory Access

Protocol"

. Webopedia.com. 4 December 1996.

Retrieved 2014-04-05.

6. ^ The X.500 series - ITU-T Rec. X.500 to X.521

7. ^ Howes, Tim. "The Lightweight Directory
Access Protocol: X.500 Lite"

(PDF). Retrieved 26 December 2012.

8. ^ "Pre-History of LDAP"

. Cyber Matters. 2013-04-09. Retrieved 5

October 2014.

9. ^ "Service Name and Transport Protocol Port

Number Registry"

. IANA. Retrieved 24 March 2021.

10.^ RFC3494
11.^ Add section of RFC4511
12.^ LDAP result codes
13.^ SASL Mechanisms at IANA
14.^ RFC4511: delete request
15.^ Boreham Draft (numSubordinates)
16.^ Modify Section of RFC4511
17.^ Zeilenga, K. LDAP Modify-Increment
Extension

. doi:10.17487/RFC4525

Page | 325
 . RFC 4525

18.^ Zeilenga, K. Lightweight Directory Access

Protocol (LDAP) Read Entry Controls

. IETF. doi:10.17487/RFC4527

. RFC 4527

19.^ INTERNET-DRAFT LDAP Transactions draft-

zeilenga-ldap-txn-15.txt
20.^ Shibboleth Security alert 20120227
21.^ Tools.ietf.org
22.^ Tools.ietf.org
23.^ Tools.ietf.org
24.^ Openldap.org
25.^ Open Grid Forum : Project Home
Sources

• ITU-T Rec. X.680, "Abstract Syntax Notation One

(ASN.1) - Specification of Basic Notation", 1994
• Basic encoding rules (BER) - ITU-T Rec. X.690,
"Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules",
1994
• RFC 3641

- Generic String Encoding Rules (GSER) for

ASN.1 Types

• RFC 4346

- The TLS Protocol Version 1.1

Page | 326
 • RFC 4422

- Simple Authentication and Security Layer

(SASL)

• SASL mechanisms registered at IANA

Further reading

• Arkills, B (2003). LDAP Directories Explained: An

Introduction and Analysis

. Addison-Wesley Professional. ISBN 978-0-201-

78792-4.

• Carter, G (2003). LDAP System Administration

. O'Reilly Media. ISBN 978-1-56592-491-8.

• Donley, C (2002). LDAP Programming,

Management, and Integration. Manning
Publications. ISBN 978-1-930110-40-3.
• Howes, T; Smith, M; Good, G
(2003). Understanding and Deploying LDAP
Directory Services

. Addison-Wesley Professional. ISBN 978-0-672-

32316-4.

• Rhoton, J (1999). Programmer's Guide to

Internet Mail: SMTP, POP, IMAP, and LDAP.
Elsevier. ISBN 978-1-55558-212-8.
• Voglmaier, R (2003). The ABCs of LDAP: How to
Install, Run, and Administer LDAP Services.
Auerbach Publications. ISBN 978-0-8493-1346-2.

Page | 327
 External links

• List of public LDAP Servers (2013): "Ldapwiki:

Public LDAP Servers"
nce:
Spain:
Germany:
Netherlands:
Hong Kong:
Sweden:
Italy:
Switzerland:

Glossary of AD terms

replica: A variable containing a set of objects.

attribute: An identifier for a value or set of values. See also attribute in the
Glossary (section 1.1).
object: A set of attributes, each with its associated values. Two attributes of an
object have special significance:
▪ Identifying attribute: A designated single-valued attribute appears on every
object. The value of this attribute identifies the object. For the set of
objects in a replica, the values of the identifying attribute are distinct.
▪ Parent-identifying attribute: A designated single-valued attribute appears
on every object. The value of this attribute identifies the object's parent.
That is, this attribute contains the value of the parent's identifying attribute
or a reserved value identifying no object (for more information, see section
3.1.1.1.3). For the set of objects in a replica, the values of this parent-
identifying attribute define an oriented tree with objects as vertices and
child-parent references as directed arcs, with the child as an arc's initial
vertex and the parent as an arc's final vertex.

Page | 328
 Note that an object is a value, not a variable; a replica is a variable. The
process of adding, modifying, or deleting an object in a replica replaces the
entire value of the replica with a new value.
As the term "replica" suggests, it is often the case that two replicas contain
"the same objects". In this usage, objects in two replicas are considered "the
same" if they have the same value of the identifying attribute and if there is a
process in place (that is, replication) to converge the values of the remaining
attributes. When the members of a set of replicas are considered to be the
same, it is common to say "an object" as a shorthand way of referring to the
set of corresponding objects in the replicas.
object class: A set of restrictions on the construction and update of objects. An
object class must be specified when an object is created. An object class
specifies a set of must-have attributes (every object of the class must have at
least one value of each) and may-have attributes (every object of the class may
have a value of each). An object class also specifies a set of possible superiors
(the parent object of an object of the class must have one of these classes). An
object class is defined by a classSchema object.
parent object: See "object", above.
child object, children: An object that is not the root of its oriented tree. The
children of an object O is the set of all objects whose parent object is O.
See section 3.1.1.1.3 for the particular use made of these definitions in this
specification.
70 Glossary
This document uses the following terms:
88 object class: An object class as specified in the X.500 directory specification
([X501] section 8.4.3). An 88 object class can be instantiated as a new object,
like a structural object class, and on an existing object, like an auxiliary
object class.
abstract object class: An object class whose only function is to be the basis of
inheritance by other object classes, thereby simplifying their definition.
access check: A verification to determine whether a specific access type is
allowed by checking a security context against a security descriptor.

Page | 329
 access control entry (ACE): An entry in an access control list (ACL) that contains
a set of user rights and a security identifier (SID) that identifies a principal
for whom the rights are allowed, denied, or audited.
access control list (ACL): A list of access control entries (ACEs) that collectively
describe the security rules for authorizing access to some resource; for
example, an object or set of objects.
access mask: A 32-bit value present in an access control entry (ACE) that
specifies the allowed or denied rights to manipulate an object.
account domain: A domain, identified by a security identifier (SID), that is the
SID namespace for which a given machine is authoritative. The account
domain is the same as the primary domain for a domain controller (DC) and
is its default domain. For a machine that is joined to a domain, the account
domain is the SID namespace defined by the local Security Accounts
Manager [MS-SAMR].
ACID: A term that refers to the four properties that any database system must
achieve in order to be considered transactional: Atomicity, Consistency,
Isolation, and Durability [GRAY].
active: A state of an attributeSchema or classSchema object that represents
part of the schema. It is possible to instantiate an active attribute or an
active class. The opposite term is defunct.

Active Directory: The Windows implementation of a general-

purpose directory service, which uses LDAP as its primary access
protocol.
Active Directory stores information about a variety of objects in the network
such as user accounts, computer accounts, groups, and all related credential
information used by Kerberos [MS-KILE]. Active Directory is either deployed
as Active Directory Domain Services (AD DS) or Active Directory Lightweight
Directory Services (AD LDS), which are both described in [MS-ADOD]: Active
Directory Protocols Overview.
Active Directory Domain Services (AD DS): A directory service (DS)
implemented by a domain controller (DC). The DS provides a data store for

Page | 330
 objects that is distributed across multiple DCs. The DCs interoperate as peers
to ensure that a local change to an object replicates correctly across DCs. AD
DS is a deployment of Active Directory [MS-ADTS].
Active Directory Lightweight Directory Services (AD LDS): A directory service
(DS) implemented by a domain controller (DC). AD LDS is a deployment of
Active Directory [MS-ADTS]. The most significant difference between AD LDS
and Active Directory Domain Services (AD DS) is that AD LDS does not host
domain naming contexts (domain NCs). A server can host multiple AD LDS
DCs. Each DC is an independent AD LDS instance, with its own independent
state. AD LDS can be run as an operating system DS or as a directory service
provided by a standalone application (ADAM).
Advanced Encryption Standard (AES): A block cipher that supersedes the Data
Encryption Standard (DES). AES can be used to protect electronic data. The
AES algorithm can be used to encrypt (encipher) and decrypt (decipher)
information. Encryption converts data to an unintelligible form called
ciphertext; decrypting the ciphertext converts the data back into its original
form, called plaintext. AES is used in symmetric-key cryptography, meaning
that the same key is used for the encryption and decryption operations. It is
also a block cipher, meaning that it operates on fixed-size blocks of plaintext
and ciphertext, and requires the size of the plaintext as well as the ciphertext
to be an exact multiple of this block size. AES is also known as the Rijndael
symmetric encryption algorithm [FIPS197].
ambiguous name resolution (ANR): A search algorithm that permits a client to
search multiple naming-related attributes on objects by way of a single
clause of the form "(anr=value)" in a Lightweight Directory Access Protocol
(LDAP) search filter. This permits a client to query for an object when the
client possesses some identifying material related to the object but does not
know which attribute of the object contains that identifying material.
application naming context (application NC): A specific type of naming context
(NC), or an instance of that type, that supports only full replicas (no partial
replicas). An application NC cannot contain security principal objects in
Active Directory Domain Services (AD DS), but can contain security principal
objects in Active Lightweight Directory Services (AD LDS). A forest can have

Page | 331
 zero or more application NCs in either AD DS or AD LDS. An application NC
can contain dynamic objects. Application NCs do not appear in the global
catalog (GC). The root of an application NC is an object of class domainDNS.
ASN.1: Abstract Syntax Notation One. ASN.1 is used to describe Kerberos
datagrams as a sequence of components, sent in messages. ASN.1 is
described in the following specifications: [ITUX660] for general procedures;
[ITUX680] for syntax specification, and [ITUX690] for the Basic Encoding
Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding
Rules (DER) encoding rules.
attribute: An identifier for a single or multivalued data element that is
associated with a directory object. An object consists of its attributes and
their values. For example, cn (common name), street (street address), and
mail (email addresses) can all be attributes of a user object. An attribute's
schema, including the syntax of its values, is defined in an attributeSchema
object.
attribute syntax: Specifies the format and range of permissible values of an
attribute. The syntax of an attribute is defined by several attributes on the
attributeSchema object, as specified in [MS-ADTS] section 3.1.1.2. Attribute
syntaxes supported by Active Directory include Boolean, Enumeration,
Integer, LargeInteger, String(UTC-Time), Object(DS-DN), and String(Unicode).
AttributeStamp: The type of a stamp attached to an attribute.
authentication: The act of proving an identity to a server while providing key
material that binds the identity to subsequent communications.
authorization: The secure computation of roles and accesses granted to an
identity.
auxiliary object class: An object class that cannot be instantiated in the
directory but can be either added to, or removed from, an existing object to
make its attributes available for use on that object; or associated with an
abstract or structural object class to add its attributes to that abstract or
structural object class.

Page | 332
 back link attribute: A constructed attribute whose values include object
references (for example, an attribute of syntax Object(DS-DN)). The back link
values are derived from the values of a related attribute, a forward link
attribute, on other objects. If f is the forward link attribute, one back link
value exists on object o for each object r that contains a value of o for
attribute f. The relationship between the forward link attributes and back
link attributes is expressed using the linkId attribute on the attributeSchema
objects representing the two attributes. The forward link's linkId is an even
number, and the back link's linkId is the forward link's linkId plus one. For
more information, see [MS-ADTS] section 3.1.1.1.6.
back link value: The value of a back link attribute.
backup domain controller (BDC): A domain controller (DC) that receives a copy
of the domain directory database from the primary domain controller (PDC).
This copy is synchronized periodically and automatically with the primary
domain controller (PDC). BDCs also authenticate user logons and can be
promoted to function as the PDC. There is only one PDC or PDC emulator in a
domain, and the rest are backup domain controllers.
base64 encoding: A binary-to-text encoding scheme whereby an arbitrary
sequence of bytes is converted to a sequence of printable ASCII characters,
as described in [RFC4648].
Basic Encoding Rules (BER): A set of encoding rules for ASN.1 notation. These
encoding schemes allow the identification, extraction, and decoding of data
structures. These encoding rules are defined in [ITUX690].
big-endian: Multiple-byte values that are byte-ordered with the most
significant byte stored in the memory location with the lowest address.
binary large object (BLOB): A collection of binary data stored as a single entity
in a database.
bridgehead domain controller (bridgehead DC): A domain controller (DC) that
may replicate updates to or from DCs in sites other than its own.
broadcast: A style of resource location or data transmission in which a client
makes a request to all parties on a network simultaneously (a one-to-many

Page | 333
 communication). Also, a mode of resource location that does not use a name
service.
built-in domain: The security identifier (SID) namespace defined by the fixed
SID S-1-5-32. Contains groups that define roles on a local machine such as
Backup Operators.
built-in domain SID: The fixed SID S-1-5-32.
canonical name: A syntactic transformation of an Active Directory
distinguished name (DN) into something resembling a path that still
identifies an object within a forest. DN "cn=Peter Houston, ou=NTDEV,
dc=microsoft, dc=com" translates to the canonical name
"microsoft.com/NTDEV/Peter Houston", while the DN "dc=microsoft,
dc=com" translates to the canonical name "microsoft.com/".
child naming context (child NC): Given naming contexts (NCs) with their
corresponding distinguished names (DNs) forming a child and parent
relationship, the NC in the child relationship is referred as the child NC. The
parent of a child NC must be an NC and is referred to as the parent naming
context (parent NC).
child object, children: An object that is not the root of its tree. The children of
an object o are the set of all objects whose parent is o. See section 1 of [MS-
ADTS] and section 1 of [MS-DRSR].
claim: An assertion about a security principal expressed as the n-tuple
{Identifier, ValueType, m Value(s) of type ValueType} where m is greater than
or equal to 1. A claim with only one Value in the n-tuple is called a single-
valued claim; a claim with more than one Value is called a multi-valued
claim.
code page: An ordered set of characters of a specific script in which a numerical
index (code-point value) is associated with each character. Code pages are a
means of providing support for character sets and keyboard layouts used in
different countries. Devices such as the display and keyboard can be
configured to use a specific code page and to switch from one code page
(such as the United States) to another (such as Portugal) at the user's
request.

Page | 334
 Component Object Model (COM): An object-oriented programming model that
defines how objects interact within a single process or between processes. In
COM, clients have access to an object through interfaces implemented on
the object. For more information, see [MS-DCOM].
computer object: An object of class computer. A computer object is a security
principal object; the principal is the operating system running on the
computer. The shared secret allows the operating system running on the
computer to authenticate itself independently of any user running on the
system. See security principal.
configuration naming context (config NC): A specific type of naming context
(NC), or an instance of that type, that contains configuration information. In
Active Directory, a single config NC is shared among all domain controllers
(DCs) in the forest. A config NC cannot contain security principal objects.
connection: A link between two devices that uses the Simple Symmetric
Transport Protocol (SSTP). Each connection can support one or more SSTP
sessions.
constructed attribute: An attribute whose values are computed from normal
attributes (for read) and/or have effects on the values of normal attributes
(for write).
container: An object in the directory that can serve as the parent for other
objects. In the absence of schema constraints, all objects would be
containers. The schema allows only objects of specific classes to be
containers.
control access right: An extended access right that can be granted or denied on
an access control list (ACL).
Coordinated Universal Time (UTC): A high-precision atomic time standard that
approximately tracks Universal Time (UT). It is the basis for legal, civil time all
over the Earth. Time zones around the world are expressed as positive and
negative offsets from UTC. In this role, it is also referred to as Zulu time (Z)
and Greenwich Mean Time (GMT). In these specifications, all references to
UTC refer to the time at UTC-0 (or GMT).

Page | 335
 cross-forest trust: A relationship between two forests that enables security
principals from any domain in one forest to authenticate to computers
joined to any domain in the other forest.
crossRef object: An object residing in the partitions container of the config NC
that describes the properties of a naming context (NC), such as its domain
naming service name, operational settings, and so on.
DC functional level: A specification of functionality available in a domain
controller (DC). See [MS-ADTS] section 6.1.4.2 for possible values and a
mapping between the possible values and product versions.
default domain naming context (default domain NC): When Active Directory is
operating as Active Directory Domain Services (AD DS), this is the default
naming context (default NC) of the domain controller (DC). When operating
as Active Directory Lightweight Directory Services (AD LDS), this NC is not
defined.
default naming context (default NC): When Active Directory is operating as
Active Directory Domain Services (AD DS), the default naming context
(default NC) is the domain naming context (domain NC) whose full replica is
hosted by a domain controller (DC), except when the DC is a read-only
domain controller (RODC), in which case the default NC is a filtered partial
NC replica. When operating as AD DS, a DC's default NC is the NC of its
default NC replica, and the default NC contains the DC's computer object.
When Active Directory is operating as AD LDS, the default NC is the naming
context (NC) specified by the msDS-DefaultNamingContext attribute on the
nTDSDSA object for the DC. See nTDSDSA object.
default schema: The schema of a given version of Active Directory, as defined
by [MS-ADSC], [MS-ADA1], [MS-ADA2], and [MS-ADA3] for AD DS, and as
defined by [MS-ADLS] for Active Directory Lightweight Directory Services
(AD LDS).
defunct: A state of an attributeSchema or classSchema object that represents
part of the schema. It is not possible to instantiate a defunct attribute or a
defunct class. The opposite term is active.

Page | 336
 deleted-object: An object that has been deleted, but remains in storage until a
configured amount of time (the deleted-object lifetime) has passed, after
which the object is transformed to a recycled-object. Unlike a recycled-
object or a tombstone, a deleted-object maintains virtually all the state of
the object before deletion, and can be undeleted without loss of
information. Deleted-objects exist only when the Recycle Bin optional
feature is enabled.
deleted-object lifetime: The time period that a deleted-object is kept in
storage before it is transformed into a recycled-object.
digest: The fixed-length output string from a one-way hash function that takes
a variable-length input string and is probabilistically unique for every
different input string. Also, a cryptographic checksum of a data (octet)
stream.
directory: A forest.
directory object: An Active Directory object, which is a specialization of the
"object" concept that is described in [MS-ADTS] section 1 or [MS-DRSR]
section 1, Introduction, under Pervasive Concepts. An Active Directory
object can be identified by the objectGUID attribute of a dsname according
to the matching rules defined in [MS-DRSR] section 5.50, DSNAME. The
parent-identifying attribute (not exposed as an LDAP attribute) is parent.
Active Directory objects are similar to LDAP entries, as defined in [RFC2251];
the differences are specified in [MS-ADTS] section 3.1.1.3.1.
directory service (DS): A service that stores and organizes information about a
computer network's users and network shares, and that allows network
administrators to manage users' access to the shares. See also Active
Directory.
directory service agent (DSA): A term from the X.500 directory specification
[X501] that represents a component that maintains and communicates
directory information.
discretionary access control list (DACL): An access control list (ACL) that is
controlled by the owner of an object and that specifies the access particular
users or groups can have to the object.

Page | 337
 distinguished name (DN): In Lightweight Directory Access Protocol (LDAP), an
LDAP Distinguished Name, as described in [RFC2251] section 4.1.3. The DN of
an object is the DN of its parent, preceded by the RDN of the object. For
example: CN=David Thompson, OU=Users, DC=Microsoft, DC=COM. For
definitions of CN and OU, see [RFC2256] sections 5.4 and 5.12, respectively.
DNS name: A fully qualified domain name (FQDN).
domain: A set of users and computers sharing a common namespace and
management infrastructure. At least one computer member of the set must
act as a domain controller (DC) and host a member list that identifies all
members of the domain, as well as optionally hosting the Active Directory
service. The domain controller provides authentication of members, creating
a unit of trust for its members. Each domain has an identifier that is shared
among its members. For more information, see [MS-AUTHSOD] section
1.1.1.5 and [MS-ADTS].
domain controller (DC): The service, running on a server, that implements
Active Directory, or the server hosting this service. The service hosts the data
store for objects and interoperates with other DCs to ensure that a local
change to an object replicates correctly across all DCs. When Active
Directory is operating as Active Directory Domain Services (AD DS), the DC
contains full NC replicas of the configuration naming context (config NC),
schema naming context (schema NC), and one of the domain NCs in its
forest. If the AD DS DC is a global catalog server (GC server), it contains
partial NC replicas of the remaining domain NCs in its forest. For more
information, see [MS-AUTHSOD] section 1.1.1.5.2 and [MS-ADTS]. When
Active Directory is operating as Active Directory Lightweight Directory
Services (AD LDS), several AD LDS DCs can run on one server. When Active
Directory is operating as AD DS, only one AD DS DC can run on one server.
However, several AD LDS DCs can coexist with one AD DS DC on one server.
The AD LDS DC contains full NC replicas of the config NC and the schema NC
in its forest. The domain controller is the server side of Authentication
Protocol Domain Support [MS-APDS].
domain functional level: A specification of functionality available in a domain.
Must be less than or equal to the DC functional level of every domain

Page | 338
 controller (DC) that hosts a replica of the domain's naming context (NC). For
information on defined levels, corresponding features, information on how
the domain functional level is determined, and supported domain
controllers, see [MS-ADTS] sections 6.1.4.2 and 6.1.4.3. When Active
Directory is operating as Active Directory Lightweight Directory Services (AD
LDS), domain functional level does not exist.
domain joined: A relationship between a machine and some domain naming
context (domain NC) in which they share a secret. The shared secret allows
the machine to authenticate to a domain controller (DC) for the domain.
domain local group: An Active Directory group that allows user objects, global
groups, and universal groups from any domain as members. It can
additionally include, and be a member of, other domain local groups from
within its domain. A group object g is a domain local group if and only if
GROUP_TYPE_RESOURCE_GROUP is present in g!groupType; see [MS-ADTS]
section 2.2.12, "Group Type Flags". A security-enabled domain local group is
valid for inclusion within access control lists (ACLs) from its own domain. If a
domain is in mixed mode, then a security-enabled domain local group in
that domain allows only user objects as members.
domain name: A domain name or a NetBIOS name that identifies a domain.
Domain Name System (DNS): A hierarchical, distributed database that contains
mappings of domain names to various types of data, such as IP addresses.
DNS enables the location of computers and services by user-friendly names,
and it also enables the discovery of other information stored in the database.
domain naming context (domain NC): A specific type of naming context (NC),
or an instance of that type, that represents a domain. A domain NC can
contain security principal objects; no other type of NC can contain security
principal objects. Domain NCs appear in the global catalog (GC). A domain
NC is hosted by one or more domain controllers (DCs) operating as AD DS. In
AD DS, a forest has one or more domain NCs. A domain NC cannot exist in
AD LDS. The root of a domain NC is an object of class domainDNS; for
directory replication [MS-DRSR], see domainDNS.

Page | 339
 domain prefix: A security identifier (SID) of a domain without the relative
identifier (RID) portion. The domain prefix refers to the issuing authority SID.
For example, the domain prefix of S-1-5-21-397955417-626881126-
188441444-1010 is S-1-5-21-397955417-626881126-188441444.
downlevel trust: A trust in which one of the peers is running Windows NT 4.0.
DSA GUID: The objectGUID of a DSA object.
dsname: A tuple that contains between one and three identifiers for an object.
The term dsname does not stand for anything. The possible identifiers are
the object's GUID (attribute objectGuid), security identifier (SID) (attribute
objectSid), and distinguished name (DN) (attribute distinguishedName). A
dsname can appear in a protocol message and as an attribute value (for
example, a value of an attribute with syntax Object(DS-DN)). Given a
DSName, an object can be identified within a set of NC replicas according to
the matching rules defined in [MS-DRSR] section 5.49.
dynamic object: An object with a time-to-die (attribute msDS-Entry-Time-To-
Die). The directory service garbage-collects a dynamic object immediately
after its time-to-die has passed. The constructed attribute entryTTL gives a
dynamic object's current time-to-live, that is, the difference between the
current time and msDS-Entry-Time-To-Die. For more information, see
[RFC2589].
entry: In Active Directory, a synonym for object.
existing-object: An object that is not a tombstone, deleted-object, or recycled-
object.
expunge: To permanently remove an object from a naming context (NC)
replica, without converting it to a tombstone.
Extended-Rights container: A container holding objects that correspond to
control access rights. The container is a child of configuration naming
context (config NC) and has relative distinguished name (RDN)
CN=Extended-Rights.
File Replication Service (FRS): One of the services offered by a domain
controller (DC), which is advertised through the Domain Controller Location

Page | 340
 protocol. The service being offered to clients is a replicated data storage
volume that is associated with the default naming context (NC). The running
or paused state of the FRS on a DC is available through protocols
documented in [MS-ADTS] section 6.3.
filter: In the context of the Lightweight Directory Access Protocol (LDAP), the
filter is one of the parameters in a search request. The filter specifies
matching constraints for the candidate objects.
filtered attribute set: The subset of attributes that are not replicated to the
filtered partial NC replica and the filtered GC partial NC replica. The filtered
attribute set is part of the state of the forest and is used to control the
attributes that replicate to a read-only domain controller (RODC). The
searchFlags schema attribute is used to define this set.
filtered GC partial NC replica: An NC replica that contains a schema-specified
subset of attributes for the objects. The attributes consist of the attributes
in the GC partial attribute set (PAS), excluding those present in the filtered
attribute set. A filtered GC partial NC replica is not writable; that is, it does
not accept originating updates.
filtered partial NC replica: An NC replica that contains a schema-specified
subset of attributes for the objects it contains. The subset of attributes
consists of all the attributes of the objects, excluding those attributes in the
filtered attribute set. A filtered partial NC replica is not writable; that is, it
does not accept originating updates.
flexible single master operation (FSMO): A read or update operation on a
naming context (NC), such that the operation must be performed on the
single designated master replica of that NC. The master replica designation is
"flexible" because it can be changed without losing the consistency gained
from having a single master. This term, pronounced "fizmo", is never used
alone; see also FSMO role, FSMO role owner, and FSMO object.
foreign principal object (FPO): A foreignSecurityPrincipal object.
forest: For Active Directory Domain Services (AD DS), a set of naming contexts
(NCs) consisting of one schema naming context (schema NC), one
configuration naming context (config NC), one or more domain naming

Page | 341
 contexts (domain NCs), and zero or more application naming contexts
(application NCs). Because a set of NCs can be arranged into a tree structure,
a forest is also a set containing one or several trees of NCs. For AD LDS, a set
of NCs consisting of one schema NC, one config NC, and zero or more
application NCs. (In Microsoft documentation, an AD LDS forest is called a
"configuration set".)
forest functional level: A specification of functionality available in a forest. It
must be less than or equal to the domain controller (DC) functional level of
every DC in the forest. See [MS-ADTS] section 6.1.4.4 for information on how
the forest functional level is determined.
forest root domain NC: For Active Directory Domain Services (AD DS), the
domain naming context (domain NC) within a forest whose child is the
forest's configuration naming context (config NC). The fully qualified
domain name (FQDN) of the forest root domain NC serves as the forest's
name.
forward link attribute: An attribute whose values include object references
(for example, an attribute of syntax Object(DS-DN)). The forward link values
can be used to compute the values of a related attribute, a back link
attribute, on other objects. If an object o refers to object r in forward link
attribute f, and there exists a back link attribute b corresponding to f, then a
back link value referring to o exists in attribute b on object r. The
relationship between the forward and back link attributes is expressed using
the linkId attribute on the attributeSchema objects representing the two
attributes. The forward link's linkId is an even number, and the back link's
linkId is the forward link's linkId plus one. A forward link attribute can exist
with no corresponding back link attribute, but not vice-versa. For more
information, see [MS-ADTS].
forward link value: The value of a forward link attribute.
FSMO role: A set of objects that can be updated in only one naming context
(NC) replica (the FSMO role owner's replica) at any given time. For more
information, see [MS-ADTS] section 3.1.1.1.11. See also FSMO role owner.

Page | 342
 FSMO role object: An object in a directory that represents a specific FSMO
role. This object is an element of the FSMO role and contains the
fSMORoleOwner attribute.
FSMO role owner: The domain controller (DC) holding the naming context
(NC) replica in which the objects of a FSMO role can be updated.
full NC replica: A naming context (NC) replica that contains all the attributes of
the objects it contains. A full replica accepts originating updates.
fully qualified domain name (FQDN): (1) An unambiguous domain name that
gives an absolute location in the Domain Name System's (DNS) hierarchy
tree, as defined in [RFC1035] section 3.1 and [RFC2181] section 11.
(2) In Active Directory, a fully qualified domain name (FQDN) (1) that
identifies a domain.
garbage collection: The process of identifying logically deleted objects (also
known as tombstones) and link values that have passed their tombstone
lifetime, and then permanently removing these objects from a naming
context (NC) replica. Garbage collection does not generate replication
traffic.
GC partial attribute set (PAS): The subset of attributes that replicate to a GC
partial NC replica. A particular GC partial attribute set (PAS) is part of the
state of the forest and is used to control the attributes that replicate to
global catalog servers (GC servers). The isMemberOfPartialAttributeSet
schema attribute is used to define this set.
GC partial NC replica: An NC replica that contains a schema-specified subset of
attributes for the objects it contains. The subset of attributes consists of the
attributes in the GC partial attribute set (PAS). A GC partial NC replica is not
writable; for example, it does not accept originating updates.
global catalog (GC): A unified partial view of multiple naming contexts (NCs) in
a distributed partitioned directory. The Active Directory directory service GC
is implemented by GC servers. The definition of global catalog is specified in
[MS-ADTS] section 3.1.1.1.8.

Page | 343
 global catalog server (GC server): A domain controller (DC) that contains a
naming context (NC) replica (one full, the rest partial) for each domain
naming context in the forest.
global group: An Active Directory group that allows user objects from its own
domain and global groups from its own domain as members. Also called
domain global group. Universal groups can contain global groups. A group
object g is a global group if and only if GROUP_TYPE_ACCOUNT_GROUP is
present in g! groupType; see [MS-ADTS] section 2.2.12, "Group Type Flags". A
global group that is also a security-enabled group is valid for inclusion within
ACLs anywhere in the forest. If a domain is in mixed mode, then a global
group in that domain that is also a security-enabled group allows only user
object as members. See also domain local group, security-enabled group.
globally unique identifier (GUID): A term used interchangeably with
universally unique identifier (UUID) in Microsoft protocol technical
documents (TDs). Interchanging the usage of these terms does not imply or
require a specific algorithm or mechanism to generate the value. Specifically,
the use of this term does not imply or require that the algorithms described
in [RFC4122] or [C706] must be used for generating the GUID. See also
universally unique identifier (UUID).
group: A collection of objects that can be treated as a whole.
group object: In Active Directory, a group object has an object class group. A
group has a forward link attribute member; the values of this attribute
either represent elements of the group (for example, objects of class user or
computer) or subsets of the group (objects of class group). The
representation of group subsets is called "nested group membership". The
back link attribute memberOf enables navigation from group members to
the groups containing them. Some groups represent groups of security
principals and some do not and are, for instance, used to represent email
distribution lists.
Group Policy: A mechanism that allows the implementer to specify managed
configurations for users and computers in an Active Directory service
environment.

Page | 344
 GUID-based DNS name: The domain naming service name of a domain
controller (DC), constructed by concatenating the dashed string
representation of the objectGuid of the DC's nTDSDSA object, the string
"._msdcs.", and the syntactic transformation of the root domain's
distinguished name (DN) to a domain naming service name. If a DC's DSA
GUID is "52f6c43b-99ec-4040-a2b0-e9ebf2ec02b8", and the forest root
domain NC's DNS name is "fabrikam.com", then the GUID-based DNS name
of the DC is "52f6c43b-99ec-4040-a2b0-
e9ebf2ec02b8._msdcs.fabrikam.com".
GUIDString: A GUID in the form of an ASCII or Unicode string, consisting of one
group of 8 hexadecimal digits, followed by three groups of 4 hexadecimal
digits each, followed by one group of 12 hexadecimal digits. It is the standard
representation of a GUID, as described in [RFC4122] section 3. For example,
"6B29FC40-CA47-1067-B31D-00DD010662DA". Unlike a curly braced GUID
string, a GUIDString is not enclosed in braces.
inbound trust: A trust relationship between two domains, from the perspective
of the domain that is trusted to perform authentication.
inheritance: See object class inheritance.
interdomain trust account: An account that stores information associated with
a domain trust in the domain controllers (DCs) of the domain that is trusted
to perform authentication.
intersite topology generator (ISTG): A domain controller (DC) within a given
site that computes an NC replica graph for each NC replica on any DC in its
site. This DC creates, updates, and deletes corresponding nTDSConnection
objects for edges directed from NC replicas in other sites to NC replicas in its
site.
invocation ID: The invocationId attribute. An attribute of an nTDSDSA object.
Its value is a unique identifier for a function that maps from update
sequence numbers (USNs) to updates to the NC replicas of a domain
controller (DC). See also nTDSDSA object.
JavaScript Object Notation (JSON): A text-based, data interchange format that
is used to transmit structured data, typically in Asynchronous JavaScript +

Page | 345
 XML (AJAX) web applications, as described in [RFC7159]. The JSON format is
based on the structure of ECMAScript (Jscript, JavaScript) objects.
Kerberos: An authentication system that enables two parties to exchange
private information across an otherwise open network by assigning a unique
key (called a ticket) to each user that logs on to the network and then
embedding these tickets into messages sent by the users. For more
information, see [MS-KILE].
Knowledge Consistency Checker (KCC): A component of the Active Directory
replication that is used to create spanning trees for domain controller to
domain controller replication and to translate those trees into settings of
variables that implement the replication topology.
LDAP connection: A TCP connection from a client to a server over which the
client sends Lightweight Directory Access Protocol (LDAP) requests and the
server sends responses to the client's requests.
LDAP Data Interchange Format (LDIF): A standard that defines how to import
and export directory data between directory servers that use the
Lightweight Directory Access Protocol (LDAP), as described in [RFC2849].
LDAP ping: A specific Lightweight Directory Access Protocol (LDAP) search that
returns information about whether services are live on a domain controller
(DC).
Lightweight Directory Access Protocol (LDAP): The primary access protocol for
Active Directory. Lightweight Directory Access Protocol (LDAP) is an industry-
standard protocol, established by the Internet Engineering Task Force (IETF),
which allows users to query and update information in a directory service
(DS), as described in [MS-ADTS]. The Lightweight Directory Access Protocol
can be either version 2 [RFC1777] or version 3 [RFC3377].
lingering object: An object that still exists in an NC replica even though it has
been deleted and garbage-collected from other replicas. This occurs, for
instance, when a domain controller (DC) goes offline for longer than the
tombstone lifetime.
link attribute: A forward link attribute or a back link attribute.

Page | 346
 link value: The value of a link attribute.
local domain controller (local DC): A domain controller (DC) on which the
current method is executing.
Lost and Found container: A container holding objects in a given naming
context (NC) that do not have parent objects due to add and remove
operations that originated on different domain controllers (DCs). The
container is a child of the NC root and has RDN CN=LostAndFound in domain
NCs and CN=LostAndFoundConfig in config NCs.
mailslot: A form of datagram communication using the Server Message Block
(SMB) protocol, as specified in [MS-MAIL].
mailslot ping: A specific mailslot request that returns information about
whether services are live on a domain controller (DC).
marshal: To encode one or more data structures into an octet stream using a
specific remote procedure call (RPC) transfer syntax (for example,
marshaling a 32-bit integer).
Messaging Application Programming Interface (MAPI): A Windows
programming interface that enables email to be sent from within a Windows
application.
mixed mode: A state of an Active Directory domain that supports domain
controllers (DCs) running Windows NT Server 4.0 operating system. Mixed
mode does not allow organizations to take advantage of new Active
Directory features such as universal groups, nested group membership, and
interdomain group membership. See also native mode.
most specific object class: In a sequence of object classes related by
inheritance, the class that none of the other classes inherits from. The
special object class top is less specific than any other class.
multi-valued claim: A claim with more than one Value in the n-tuple {Identifier,
ValueType, m Value(s) of type ValueType}.
name service provider interface (NSPI): A method of performing address-book-
related operations on Active Directory.

Page | 347
 naming context (NC): An NC is a set of objects organized as a tree. It is
referenced by a DSName. The DN of the DSName is the distinguishedName
attribute of the tree root. The GUID of the DSName is the objectGUID
attribute of the tree root. The security identifier (SID) of the DSName, if
present, is the objectSid attribute of the tree root; for Active Directory
Domain Services (AD DS), the SID is present if and only if the NC is a domain
naming context (domain NC). Active Directory supports organizing several
NCs into a tree structure.
NC replica: A variable containing a tree of objects whose root object is
identified by some naming context (NC).
NC replica graph: A directed graph containing NC replicas as nodes and
repsFrom tuples as inbound edges by which originating updates replicate
from each full replica of a given naming context (NC) to all other NC replicas
of the NC, directly or transitively.
NetBIOS: A particular network transport that is part of the LAN Manager
protocol suite. NetBIOS uses a broadcast communication style that was
applicable to early segmented local area networks. A protocol family
including name resolution, datagram, and connection services. For more
information, see [RFC1001] and [RFC1002].
NetBIOS domain name: The name registered by domain controllers (DCs) on
[1C] records of the NBNS (WINS) server (see section 6.3.4). For details of
NetBIOS name registration, see [MS-WPO] sections 7.1.4 and 10.4.
NetBIOS Name Service (NBNS): The name service for NetBIOS. For more
information, see [RFC1001] and [RFC1002].
Netlogon: A component that authenticates a computer and provides other
services. The running/paused state of Netlogon on a domain controller (DC)
is available through protocols documented in [MS-ADTS] section 6.3.
nonreplicated attribute: An attribute whose values are not replicated between
naming context (NC) replicas. The nonreplicated attributes of an object are,
in effect, local variables of the domain controller (DC) hosting the NC replica
containing that object, since changes to these attributes have no effect
outside that DC.

Page | 348
 nTDSDSA object: An object of class nTDSDSA that is always located in the
configuration naming context (config NC). This object represents a domain
controller (DC) in the forest. See [MS-ADTS] section 6.1.1.2.2.1.2.1.1.
NULL GUID: A GUID of all zeros.
object: A set of attributes, each with its associated values. For more
information on objects, see [MS-ADTS] section 1 or [MS-DRSR] section 1.
object class: A set of restrictions on the construction and update of objects. An
object class can specify a set of must-have attributes (every object of the
class must have at least one value of each) and may-have attributes (every
object of the class may have a value of each). An object class can also specify
the allowable classes for the parent object of an object in the class. An object
class can be defined by single inheritance; an object whose class is defined in
this way is a member of all object classes used to derive its most specific
class. An object class is defined in a classSchema object. See section 1 of
[MS-ADTS] and section 1 of [MS-DRSR].
object class name: The lDAPDisplayName of the classSchema object of an
object class. This document consistently uses object class names to denote
object classes; for example, user and group are both object classes. The
correspondence between Lightweight Directory Access Protocol (LDAP)
display names and numeric object identifiers (OIDs) in the Active Directory
schema is defined in the appendices of these documents: [MS-ADSC], [MS-
ADA1], [MS-ADA2], and [MS-ADA3].
object identifier (OID): In the Lightweight Directory Access Protocol (LDAP), a
sequence of numbers in a format described by [RFC1778]. In many LDAP
directory implementations, an OID is the standard internal representation of
an attribute. In the directory model used in this specification, the more
familiar ldapDisplayName represents an attribute.
object of class x (or x object): An object o such that one of the values of its
objectClass attributes is x. For instance, if objectClass contains the value user,
o is an object of class user. This is often contracted to "user object".
object reference: An attribute value that references an object. Reading a
reference gives the distinguished name (DN) of the object.

Page | 349
 operational attribute: An attribute that is returned only when requested by
name in a Lightweight Directory Access Protocol (LDAP) search request. An
LDAP search request requesting "all attributes" does not return operational
attributes and their values.
optional feature: A non-default behavior that modifies the Active Directory
state model. An optional feature is enabled or disabled in a specific scope,
such as a forest or a domain. For more information, refer to [MS-ADTS]
section 3.1.1.9.
organization: A collection of forests, including the current forest, whose
TRUST_ATTRIBUTE_CROSS_ORGANIZATION bit of the Trust attribute ([MS-
ADTS] section 6.1.6.7.9) of the trusted domain object (TDO) is not set.
oriented tree: A directed acyclic graph such that for every vertex v, except one
(the root), there is a unique edge whose tail is v. There is no edge whose tail
is the root. For more information, see [KNUTH1] section 2.3.4.2.
originating update: An update that is performed to an NC replica via any
protocol except replication. An originating update to an attribute or link
value generates a new stamp for the attribute or link value.
outbound trust: A trust relationship between two domains, from the
perspective of the domain that trusts another domain to perform
authentication.
parent naming context (parent NC): Given naming contexts (NCs) with their
corresponding distinguished names (DNs) forming a child and parent
relationship, the NC in the parent relationship is referred as the parent NC.
parent object: An object is either the root of a tree of objects or has a parent. If
two objects have the same parent, they must have different values in their
relative distinguished names (RDNs). See also, object in section 1 of [MS-
ADTS] and section 1 of [MS-DRSR].
partial attribute set (PAS): The subset of attributes that replicate to partial
naming context (NC) replicas. Also, the particular partial attribute set that is
part of the state of a forest and that is used to control the attributes that
replicate to global catalog (GC) servers.

Page | 350
 partial NC replica: An NC replica that contains a schema-specified subset of
attributes for the objects it contains. A partial NC replica is not writable—it
does not accept originating updates. See also writable NC replica.
Partitions container: A child object of the configuration naming context
(config NC) root. The relative distinguished name (RDN) of the Partitions
container is "cn=Partitions" and its class is crossRefContainer ([MS-ADTS]
section 2.30). See also crossRef object.
prefix table: A data structure that is used to translate between an object
identifier (OID) and a compressed representation for OIDs. See [MS-DRSR]
section 5.14.
primary domain controller (PDC): A domain controller (DC) designated to track
changes made to the accounts of all computers on a domain. It is the only
computer to receive these changes directly, and is specialized so as to ensure
consistency and to eliminate the potential for conflicting entries in the Active
Directory database. A domain has only one PDC.
primary group: The group object ([MS-ADSC] section 2.53) identified by the
primaryGroupID attribute ([MS-ADA3] section 2.120) of a user object ([MS-
ADSC] section 2.263). The primary group's objectSid attribute ([MS-ADA3]
section 2.45) equals the user's objectSid, with its relative identifier (RID)
portion replaced by the primaryGroupID value. The user is considered a
member of its primary group.
principal: A unique entity identifiable by a security identifier (SID) that is
typically the requester of access to securable objects or resources. It often
corresponds to a human user but can also be a computer or service. It is
sometimes referred to as a security principal.
privilege: The right of a user to perform system-related operations, such as
debugging the system. A user's authorization context specifies what
privileges are held by that user.
property set: A set of attributes, identified by a GUID. Granting access to a
property set grants access to all the attributes in the set.

Page | 351
 RDN attribute: The attribute used in a relative distinguished name (RDN). In
the RDN "cn=Peter Houston" the RDN attribute is cn. In the Active Directory
directory service, the RDN attribute of an object is determined by the 88
object class or the most specific structural object class of the object.
read permission: The authorization to read an attribute of an object. For more
information, see [MS-ADTS] section 5.1.3.
read-only domain controller (RODC): A domain controller (DC) that does not
accept originating updates. Additionally, an RODC does not perform
outbound replication. An RODC cannot be the primary domain controller
(PDC) for its domain.
read-only full NC replica: An NC replica that contains all attributes of the
objects it contains, and does not accept originating updates.
Recycle Bin: An optional feature that modifies the state model of object
deletions and undeletions, making undeletion of deleted-objects possible
without loss of the object's attribute values. For more information, see [MS-
ADTS] section 3.1.1.9.1.
recycled-object: An object that has been deleted, but remains in storage until a
configured amount of time (the tombstone lifetime) has passed, after which
the object is permanently removed from storage. Unlike a deleted-object,
most of the state of the object has been removed, and the object can no
longer be undeleted without loss of information. By keeping the recycled-
object in existence for the tombstone lifetime, the deleted state of the
object is able to replicate. Recycled-objects exist only when the Recycle Bin
optional feature is enabled.
relative distinguished name (RDN): The name of an object relative to its
parent. This is the leftmost attribute-value pair in the distinguished name
(DN) of an object. For example, in the DN "cn=Peter Houston, ou=NTDEV,
dc=microsoft, dc=com", the RDN is "cn=Peter Houston". For more
information, see [RFC2251].
relative identifier (RID): The last item in the series of SubAuthority values in a
security identifier (SID) [SIDD]. It distinguishes one account or group from all

Page | 352
 other accounts and groups in the domain. No two accounts or groups in any
domain share the same RID.
remote procedure call (RPC): A communication protocol used primarily
between client and server. The term has three definitions that are often used
interchangeably: a runtime environment providing for communication
facilities between computers (the RPC runtime); a set of request-and-
response message exchanges between computers (the RPC exchange); and
the single message from an RPC exchange (the RPC message). For more
information, see [C706].
replica: A variable containing a set of objects.
replicated attribute: An attribute whose values are replicated to other NC
replicas. An attribute is replicated if its attributeSchema object o does not
have a value for the systemFlags attribute, or if the
FLAG_ATTR_NOT_REPLICATED bit (bit 0) of o! systemFlags is zero.
replicated update: An update performed to a naming context (NC) replica by
the replication system, to propagate the effect of an originating update at
another NC replica. The stamp assigned during the originating update to
attribute values or a link value is preserved by replication.
replication: The process of propagating the effects of all originating writes to
any replica of a naming context (NC), to all replicas of the NC. If originating
writes cease and replication continues, all replicas converge to a common
application-visible state.
replication cycle: Sometimes referred to simply as "cycle". A series of one or
more replication responses associated with the same invocationId,
concluding with the return of a new up-to-date vector.
replication latency: The time lag between a final originating update to a
naming context (NC) replica and all NC replicas reaching a common
application-visible state.
Rivest-Shamir-Adleman (RSA): A system for public key cryptography. RSA is
specified in [RFC8017].

Page | 353
 root directory system agent-specific entry (rootDSE): The logical root of a
directory server, whose distinguished name (DN) is the empty string. In the
Lightweight Directory Access Protocol (LDAP), the rootDSE is a nameless
entry (a DN with an empty string) containing the configuration status of the
server. Access to this entry is typically available to unauthenticated clients.
The rootDSE contains attributes that represent the features, capabilities, and
extensions provided by the particular server.
root domain: The unique domain naming contexts (domain NCs) of an Active
Directory forest that is the parent of the forest's config NC. The config NC's
relative distinguished name (RDN) is "cn=Configuration" relative to the root
object of the root domain. The root domain is the domain that is created first
in a forest.
RPC transport: The underlying network services used by the remote procedure
call (RPC) runtime for communications between network nodes. For more
information, see [C706] section 2.
SASL: The Simple Authentication and Security Layer, as described in [RFC2222].
This is an authentication mechanism used by the Lightweight Directory
Access Protocol (LDAP).
schema: The set of attributes and object classes that govern the creation and
update of objects.
schema container: The root object of the schema naming context (schema
NC).
schema naming context (schema NC): A specific type of naming context (NC)
or an instance of that type. A forest has a single schema NC, which is
replicated to each domain controller (DC) in the forest. No other NC replicas
can contain these objects. Each attribute and class in the forest's schema is
represented as a corresponding object in the forest's schema NC. A schema
NC cannot contain security principal objects.
schema object: An object that defines an attribute or an object class. Schema
objects are contained in the schema naming context (schema NC).

Page | 354
 secret attribute: Any of the following attributes: currentValue, dBCSPwd,
initialAuthIncoming, initialAuthOutgoing, lmPwdHistory, ntPwdHistory,
priorValue, supplementalCredentials, trustAuthIncoming, trustAuthOutgoing,
and unicodePwd.
Secure Sockets Layer (SSL): A security protocol that supports confidentiality
and integrity of messages in client and server applications that communicate
over open networks. SSL supports server and, optionally, client
authentication using X.509 certificates [X509] and [RFC5280]. SSL is
superseded by Transport Layer Security (TLS). TLS version 1.0 is based on SSL
version 3.0 [SSL3].
security context: A data structure containing authorization information for a
particular security principal in the form of a collection of security identifiers
(SIDs). One SID identifies the principal specifically, whereas others represent
other capabilities. A server uses the authorization information in a security
context to check access to requested resources.
security descriptor: A data structure containing the security information
associated with a securable object. A security descriptor identifies an
object's owner by its security identifier (SID). If access control is configured
for the object, its security descriptor contains a discretionary access control
list (DACL) with SIDs for the security principals who are allowed or denied
access. Applications use this structure to set and query an object's security
status. The security descriptor is used to guard access to an object as well as
to control which type of auditing takes place when the object is accessed.
The security descriptor format is specified in [MS-DTYP] section 2.4.6; a
string representation of security descriptors, called SDDL, is specified in [MS-
DTYP] section 2.5.1.
security identifier (SID): An identifier for security principals that is used to
identify an account or a group. Conceptually, the SID is composed of an
account authority portion (typically a domain) and a smaller integer
representing an identity relative to the account authority, termed the
relative identifier (RID). The SID format is specified in [MS-DTYP] section
2.4.2; a string representation of SIDs is specified in [MS-DTYP] section 2.4.2
and [MS-AZOD] section 1.1.1.2.

Page | 355
 security principal: A unique entity, also referred to as a principal, that can be
authenticated by Active Directory. It frequently corresponds to a human
user, but also can be a service that offers a resource to other security
principals. Other security principals might be a group, which is a set of
principals. Groups are supported by Active Directory.
security principal object: An object that corresponds to a security principal. A
security principal object contains an identifier, used by the system and
applications to name the principal, and a secret that is shared only by the
principal. In Active Directory, a security principal object has the objectSid
attribute. In Active Directory, the user, computer, and group object classes
are examples of security principal object classes (though not every group
object is a security principal object). In AD LDS, any object containing the
msDS-BindableObject auxiliary class is a security principal. See also
computer object, group object, and user object.
security-enabled group: A group object with
GROUP_TYPE_SECURITY_ENABLED present in its groupType attribute. Only
security-enabled groups are added to a security context. See also group
object.
server object: A class of object in the configuration naming context (config
NC). A server object can have an nTDSDSA object as a child.
service principal name (SPN): (1) The name a client uses to identify a service
for mutual authentication. (For more information, see [RFC1964] section
2.1.1.) An SPN consists of either two parts or three parts, each separated by
a forward slash ('/'). The first part is the service class, the second part is the
host name, and the third part (if present) is the service name. For example,
"ldap/dc-01.fabrikam.com/fabrikam.com" is a three-part SPN where "ldap" is
the service class name, "dc-01.fabrikam.com" is the host name, and
"fabrikam.com" is the service name. See [SPNNAMES] for more information
about SPN format and composing a unique SPN.
(2) The name a client uses to identify a service for mutual authentication. For
more information, see [MS-ADTS] section 2.2.21 (Service Principal Name)
and [RFC1964] section 2.1.1.

Page | 356
 simple bind: A bind with the simple authentication option enabled according
to [RFC2251].
Simple Mail Transfer Protocol (SMTP): A member of the TCP/IP suite of
protocols that is used to transport Internet messages, as described in
[RFC5321].
single-valued claim: A claim with only one Value in the n-tuple {Identifier,
ValueType, m Value(s) of type ValueType}.
site: A collection of one or more well-connected (reliable and fast) TCP/IP
subnets. By defining sites (represented by site objects) an administrator can
optimize both Active Directory access and Active Directory replication with
respect to the physical network. When users log in, Active Directory clients
find domain controllers (DCs) that are in the same site as the user, or near
the same site if there is no DC in the site. See also Knowledge Consistency
Checker (KCC). For more information, see [MS-ADTS].
site object: An object of class site, representing a site.
site settings object: For a given site with site object s, its site settings object o
is the child of s such that o is of class nTDSSiteSettings and the relative
distinguished name (RDN) of o is CN=NTDS Site Settings. See also site object.
SRV record: A type of information record in DNS that maps the name of a
service to the DNS name of a server that offers that service. domain
controllers (DCs) advertise their capabilities by publishing SRV records in
DNS.
SSL/TLS handshake: The process of negotiating and establishing a connection
protected by Secure Sockets Layer (SSL) or Transport Layer Security (TLS).
For more information, see [SSL3] and [RFC2246].
stamp: Information that describes an originating update by a domain
controller (DC). The stamp is not the new data value; the stamp is
information about the update that created the new data value. A stamp is
often called metadata, because it is additional information that "talks about"
the conventional data values. A stamp contains the following pieces of
information: the unique identifier of the DC that made the originating

Page | 357
 update; a sequence number characterizing the order of this change relative
to other changes made at the originating DC; a version number identifying
the number of times the data value has been modified; and the time when
the change occurred.
structural object class: An object class that is not an 88 object class and can be
instantiated to create a new object.
SubAuthority: A variable-length array of unsigned, 32-bit integer values that is
part of a security identifier (SID). Each of these values is called a
SubAuthority. All SubAuthority values excluding the last one collectively
identify a domain. The last value, termed as the relative identifier (RID),
identifies a particular group or account relative to the domain. For more
information, see [SIDD].
subordinate reference object (sub-ref object): The naming context (NC) root
of a parent NC has a list of all the NC roots of its child NCs in the subRefs
attribute ([MS-ADA3] section 2.282). Each entry in this list is a subordinate
reference and the object named by the entry is denominated a subordinate
reference object. An object is a subordinate reference object if and only if it
is in such a list. If a server has replicas of both an NC and its child NC, then
the child NC root is the subordinate reference object, in the context of the
parent NC. If the server does not have a replica of the child NC, then another
object, with distinguishedName ([MS-ADA1] section 2.177) and objectGUID
([MS-ADA3] section 2.44) attributes equal to the child NC root, is present in
the server and is the subordinate reference object.
system access control list (SACL): An access control list (ACL) that controls the
generation of audit messages for attempts to access a securable object. The
ability to get or set an object's SACL is controlled by a privilege typically held
only by system administrators.
ticket-granting ticket (TGT): A special type of ticket that can be used to obtain
other tickets. The TGT is obtained after the initial authentication in the
Authentication Service (AS) exchange; thereafter, users do not need to
present their credentials, but can use the TGT to obtain subsequent tickets.

Page | 358
 tombstone: An object that has been deleted, but remains in storage until a
configured amount of time (the tombstone lifetime) has passed, after which
the object is permanently removed from storage. By keeping the tombstone
in existence for the tombstone lifetime, the deleted state of the object is
able to replicate. Tombstones exist only when the Recycle Bin optional
feature is not enabled.
tombstone lifetime: The amount of time a deleted directory object remains in
storage before it is permanently deleted. To avoid inconsistencies in object
deletion, the tombstone lifetime is configured to be many times longer than
the worst-case replication latency.
top level name (TLN): The DNS name of the forest root domain NC.
transitive membership: An indirect group membership that occurs when an
object is a member of a group that is a member of a second group. The
object is a member of the second group through a transitive membership.
Transmission Control Protocol (TCP): A protocol used with the Internet
Protocol (IP) to send data in the form of message units between computers
over the Internet. TCP handles keeping track of the individual units of data
(called packets) that a message is divided into for efficient routing through
the Internet.
Transport Layer Security (TLS): A security protocol that supports confidentiality
and integrity of messages in client and server applications communicating
over open networks. TLS supports server and, optionally, client
authentication by using X.509 certificates (as specified in [X509]). TLS is
standardized in the IETF TLS working group.
trust: To accept another authority's statements for the purposes of
authentication and authorization, especially in the case of a relationship
between two domains. If domain A trusts domain B, domain A accepts
domain B's authentication and authorization statements for principals
represented by security principal objects in domain B; for example, the list
of groups to which a particular user belongs. As a noun, a trust is the
relationship between two domains described in the previous sentence.
trust object: An object representing a trust.

Page | 359
 trust secret: A pair of keys used to encrypt or sign sensitive protocol data
between two trust authorities, such as domain controllers.
trusted domain object (TDO): A collection of properties that define a trust
relationship with another domain, such as direction (outbound, inbound, or
both), trust attributes, name, and security identifier of the other domain. For
more information, see [MS-ADTS].
TTL-DN: An alternative form of distinguished name (DN), applicable only to
values of link valued attributes, that includes the time until the link is no
longer returned to LDAP clients.
Unicode: A character encoding standard developed by the Unicode Consortium
that represents almost all of the written languages of the world. The Unicode
standard [UNICODE5.0.0/2007] provides three forms (UTF-8, UTF-16, and
UTF-32) and seven schemes (UTF-8, UTF-16, UTF-16 BE, UTF-16 LE, UTF-32,
UTF-32 LE, and UTF-32 BE).
universal group: An Active Directory group that allows user objects, global
groups, and universal groups from anywhere in the forest as members. A
group object g is a universal group if and only if
GROUP_TYPE_UNIVERSAL_GROUP is present in g! groupType. A security-
enabled universal group is valid for inclusion within ACLs anywhere in the
forest. If a domain is in mixed mode, then a universal group cannot be
created in that domain. See also domain local group, security-enabled
group.
universally unique identifier (UUID): A 128-bit value. UUIDs can be used for
multiple purposes, from tagging objects with an extremely short lifetime, to
reliably identifying very persistent objects in cross-process communication
such as client and server interfaces, manager entry-point vectors, and RPC
objects. UUIDs are highly likely to be unique. UUIDs are also known as
globally unique identifiers (GUIDs) and these terms are used
interchangeably in the Microsoft protocol technical documents (TDs).
Interchanging the usage of these terms does not imply or require a specific
algorithm or mechanism to generate the UUID. Specifically, the use of this
term does not imply or require that the algorithms described in [RFC4122] or
[C706] must be used for generating the UUID.

Page | 360
 update: An add, modify, or delete of one or more objects or attribute values.
See originating update, replicated update.
update sequence number (USN): A monotonically increasing sequence number
used in assigning a stamp to an originating update. For more information,
see [MS-ADTS].
uplevel trust: A trust in which both peers are running Windows 2000 or later
domain controllers.
User Datagram Protocol (UDP): The connectionless protocol within TCP/IP that
corresponds to the transport layer in the ISO/OSI reference model.
user object: An object of class user. A user object is a security principal object;
the principal is a person or service entity running on the computer. The
shared secret allows the person or service entity to authenticate itself, as
described in ([MS-AUTHSOD] section 1.1.1.1).
user principal name (UPN): A user account name (sometimes referred to as the
user logon name) and a domain name that identifies the domain in which the
user account is located. This is the standard usage for logging on to a
Windows domain. The format is: [email protected] (in the form of an
email address). In Active Directory, the userPrincipalName attribute of the
account object, as described in [MS-ADTS].
UTF-16: A standard for encoding Unicode characters, defined in the Unicode
standard, in which the most commonly used characters are defined as
double-byte characters. Unless specified otherwise, this term refers to the
UTF-16 encoding form specified in [UNICODE5.0.0/2007] section 3.9.
UTF-8: A byte-oriented standard for encoding Unicode characters, defined in
the Unicode standard. Unless specified otherwise, this term refers to the
UTF-8 encoding form specified in [UNICODE5.0.0/2007] section 3.9.
Virtual List View (VLV) search: Refers to a Lightweight Directory Access
Protocol (LDAP) search operation that enables the server to return a
contiguous subset of a large search result set. LDAP controls
LDAP_CONTROL_VLVREQUEST and LDAP_CONTROL_VLVRESPONSE (section
3.1.1.3.4.1.17) that are used to perform a VLV search.

Page | 361
 well-known object (WKO): An object within an naming context (NC) that can
be located using a fixed globally unique identifier (GUID).
Windows error code: A 32-bit quantity where zero represents success and
nonzero represents failure. The specific failure codes are specified in [MS-
ERREF].
Windows security descriptor: See security descriptor.
writable naming context (NC) replica: A naming context (NC) replica that
accepts originating updates. A writable NC replica is always full, but a full NC
replica is not always writable. Partial replicas are not writable. See also read-
only full NC replica.
MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are
used as defined in [RFC2119]. All statements of optional behavior use either
MAY, SHOULD, or SHOULD NOT.

Page | 362
Azure Active Directory

Page | 363
Page | 364
Azure Active Directory Main Menu options

Page | 365
Page | 366
Page | 367
Active Directory Replication: A Guide for IT Pros

Michael Reinders

Feb 14, 2022

Learn all there is to know about how Active Directory (AD) replication works. This
guide covers the basics of how domain controllers (DCs) replicate all of your user
accounts, passwords, computers, and other objects in your environment. Learn
about how sites define the logical layout of your network and how the tools and
features in Active Directory Domain Services work together to keep your directory
running smoothly.

Table of Contents [hide]

• Active Directory replication

o How does Microsoft Active Directory replication work?
o How often does Active Directory replication occur?
• Primary replication components
o Knowledge Consistency Checker (KCC)
o Directory System Agent (DSA)
o Extensible Storage Engine (ESE)
o Remote Procedure Call (RPC)
o Inter-Site Topology Generator (ISTG)
• Active Directory replication objects
o Failover functionality
o Subnet
o Site
o Site link
o Site link bridge
o Site link transitivity
o Global Catalog server
o Universal group membership caching
• Replication management
o Check the replication health
o Check the inbound replication requests that are queued.

Page | 368
 Check the replication status
o
o Synchronize replication between replication partners
o Force the Knowledge Consistency Checker to recalculate the
topology
• How to monitor AD replication: Commands and tools

Active Directory replication

Have you ever wondered what happens behind the scenes when you add a new
user to Active Directory? Or change their password? Or join a new computer in
your domain? If you add a new user on ‘DC01’, how and when does ‘DC05’ know
about it? Active Directory replication, that’s how. This is the engine that pushes
changes from domain controller to domain controller in your environment.

How does Microsoft Active Directory replication work?

The replication of updates between Active Directory objects means that data is
sent between multiple domain controllers to keep replicas of directory partitions
synchronized. Multiple domains are common in large organizations, as are
multiple sites in disparate locations. Also, DCs for the same domain are generally
placed in more than one site to accommodate compliance, mergers and
acquisitions, etc. Each time a new domain controller is added to an existing
domain or forest, new components are created, connection objects, site links, etc.
And when you add a new DC on a new subnet, MAGIC! Yes, a new ‘subnet’ is
created in Active Directory sites and services.

How often does Active Directory replication occur?

Well, that depends. By default, for domain controllers that are in the same site
(intra-site replication), replication occurs every 15 seconds. As soon as you
change an attribute of an AD object, for instance the job title of your newly
promoted systems engineer, the DC will send out the update to its replication
partner.

Advertisement

Inter-site replication is set to 180 minutes (three hours). There are a lot of
variables, topologies, hardware, subnets, and overall network design that goes
into the planning of inter-site replication. With separate offices in New York and

Page | 369
Los Angeles, it may be acceptable to wait up to three hours for changes to take
effect across the country. Again, there are many deployment methods you could
use. You may have a root forest and child domains in each site (city). At that
point, waiting three hours for someone’s password to update from New York to
Los Angeles may work fine for your business needs.

Primary replication components

Let’s briefly go over the basic replication components in Active Directory

replication and explain their purpose.

Knowledge Consistency Checker (KCC)

All domain controllers have a built-in process called the Knowledge Consistency
Checker (KCC). This generates replication topology for the Active Directory forest.
The KCC will automatically create separate replication topologies based on your
intra-site and inter-site topologies. To accommodate the addition of new DCs, the
removal of DCs, or the act of physically moving DCs from one geographic location
to another, the KCC also dynamically adjusts the topology on a periodic schedule.

Within a site, the connections between writable domain controllers are always
arranged in a bi-directional ring, with additional shortcut connections to reduce
latency in large sites. On the other hand, the inter-site topology is a layering of
spanning trees, which means one inter-site connection exists between any two
sites for each directory partition and generally does not contain shortcut
connections.

Page | 370
 Understanding AD replication

Directory System Agent (DSA)

In Active Directory Domain Services, the Directory System Agent (DSA) is part of
the Local System Authority (LSA) subsystem. The DSA is a collection of services
and processes that run on each domain controller and provides access to the data
store. The data store is the physical store of directory data location on the
server’s hard disk.

Extensible Storage Engine (ESE)

The Extensible Storage Engine (ESE) is a database engine utilized by Active

Directory Domain Services that stores information in a logical sequence.
Information can be retrieved by various methods, for example, sequentially or by
accessing defined indices. Database updates are implemented with a transaction
in order to ensure secure operations.

The ESE is a relatively scalable design, scalable to large or small applications. The
ESE also provides consistent data access in the event of a system crash. This
provides a lightweight, highly responsive engine to store the ‘raw contents’ of
Active Directory.

Page | 371
Remote Procedure Call (RPC)

Within a site, Active Directory replication uses Remote Procedure Call (RPC) over
IP for replication. RPC is an industry-standard protocol for client/server
communications. It is highly compatible with a wide variety of network types.

For replication within a site, RPC provides uniform, high-speed connectivity. This
efficiency provides the perfect backdrop for even complex layouts of network and
multiple site Active Directory topologies.

Inter-Site Topology Generator (ISTG)

The Inter-Site Topology Generator is an Active Directory process that defines the
replication between Active Directory sites on a network. A single domain
controller in each site is automatically designated to be the Inter-Site Topology
Generator. Because this action is automatic, you don’t need to complete any
explicit steps during the installation of new DCs.

The domain controller that holds the Inter-Site Topology Generator role performs
two functions:

• It automatically selects one or more domain controllers to become

bridgehead servers, which are DCs that are mainly used for intersite
replication. If a bridgehead server becomes unavailable, the Inter-Site
Topology Generator automatically selects another bridgehead server.
• It runs the Knowledge Consistency Checker to determine the replication
topology and resultant connection objects that the bridgehead servers can
use to communicate with bridgehead servers of other sites.

Active Directory replication objects

Next, we’ll go over and explain the various types of objects you’ll come across in
the design of your Active Directory topology.

Failover functionality

What happens when one of your domain controllers is offline or down for
maintenance? Will its replication partners simply be content with potentially stale
information? Hardly.

Page | 372
Sites (and services) ensure that replication is routed around network failures and
domain controllers unavailable due to maintenance. Remember, the Knowledge
Consistency Checker runs automatically at specified intervals to keep track of the
logical topology of your network and DCs. The KCC will periodically review the
replication status of existing connections to find out if any connections are
inoperable. If a connection is not working due to a failed domain controller, the
KCC will automatically build temporary connections to other replication partners
(if they’re available) to ensure that replication occurs. If all the DCs in a site are
unavailable, the KCC will create replication connections between domain
controllers from another site.

Subnet

Now, I would imagine most IT Pros know what a Subnet is in TCP/IP arenas, but
let’s be complete: A Subnet is a segment of a TCP/IP network that defines a set of
logical IP addresses. Subnets group computers in a way that identifies their
relative physical location on your network. Subnet objects in Active Directory
Domain Services help to identify the network addresses that are used to map
computers to sites.

Site

If you do a search on this post for the word ‘site’, you’ll see quite a few hits (up to
this point). Sites are a very large topic when it comes to the logical layout of your
Active Directory topology. A site is an Active Directory object that represents one
or more TCP/IP subnets with highly reliable and ‘fast’ network connections. Site
information allows admins to configure AD access and replication to optimize
usage of their physical network. Site objects are associated with a collection of
subnets, and each domain controller in a forest is associated with an AD site
according to its IP address.

Page | 373
 AD sites
and services

Site link

When the Knowledge Consistency Checker creates a connection object for

domain controllers between sites (setting up inter-site replication), site links are
created. They are Active Directory objects that represent logical paths for Active
Directory replication. A site link object represents a set of sites that can
communicate at a uniform cost through a specified inter-site transport.

All sites contained within the site link are connected by means of the same
(logical) network type. Sites must be manually linked to other sites by using site
links so that domain controllers in one site can replicate directory changes from
DCs in another site.

Page | 374
Do you remember when we previously learned about the Inter-Site Topology
Generator and bridge servers? Well, that knowledge will help you understand
this: When two sites are connected by a site link, the replication system
automatically creates connections between specific domain controllers in each
site that are called bridgehead servers. When the KCC creates replication
connections, they are randomly distributed among all candidate bridgehead
servers in a site to share the replication workload.

Site link bridge

A site link bridge is an AD object that represents a set of site links. These
‘connected’ sites can communicate by using a common transport. Site link bridges
enable domain controllers that are not directly connected via a communication
link to replicate with each other. Typically, a site link bridge corresponds to a
router (or a set of routers) on an IP network.

The Knowledge Consistency Checker forms a transitive route through all site links
that have some sites in common. Each site link represents its own distinct and
isolated network if this behavior is disabled. Containers of site links that can be
treated as a single route are expressed through a site link bridge. Each bridge
represents an isolated segment of the communication environment for network
traffic.

Site link bridges are used to represent transitive physical connectivity accurately
and logically between sites. A site link bridge offers the Knowledge Consistency
Checker the ability to use any combination of the included site links to determine
the least expensive route to interconnect directory partitions held in those sites.
The site link bridge doesn’t actually provide connectivity to the domain
controllers. If the site link bridge is removed, replication will continue until the
Knowledge Consistency Checker removes the links.

Site link transitivity

By default, all site links are transitive, or “bridged.” When you bridge site links and
the schedules overlap, the Knowledge Consistency Checker will create replication
connections that determine domain controller replication partners between sites,
where the sites are not connected directly by site links but are connected

Page | 375
transitively through a set of common sites. This means that you can connect any
site to any other site through a combination of site links.

Global Catalog server

A Global Catalog (GC) server is a domain controller that stores information about
all objects in the forest so that users, applications, and other pieces of software
can search Active Directory Domain Services without referring to specific DCs that
store the requested data. Like all DCs, a Global Catalog server stores complete,
updateable replicas of the configuration and schema directory partitions and a
full, writable replica of the domain directory partition for the domain that it is
hosting. In addition, a Global Catalog server stores a partial, read-only replica of
every other domain in the forest. Partial, read-only domain replicas contain every
object in the domain but only a subset of the attributes (those attributes that are
most commonly used for searching the object).

Universal group membership caching

Universal group membership caching allows the domain controllers to cache the
membership of universal groups info for users. You can enable domain controllers
that are running Windows Server 2008 or higher to cache universal group
memberships by using the Active Directory Sites and Services snap-in.

You can avoid installing a Global Catalog server at every site in a domain by
enabling universal group membership caching. This will minimize network
bandwidth usage because a domain controller does not need to replicate all of
the objects located in the forest. It also reduces logon times because the
authenticating domain controllers do not always need to access a global catalog
to obtain universal group membership information.

Replication management

There are various tools you can use to monitor and manage the Active Directory
replication status in your environment: Active Directory Sites and Services,
PowerShell, the trusty Command Line, and the Active Directory Replication Status
Tool (I’ll show you this at the end of this post…). For now, let me show you how to
use the ‘Repadmin’ command to discover the status and any potential replication
errors present in your environment.

Page | 376
Check the replication health

To check the overall replication health of your domain controllers, run this
command:

repadmin /replsummary

Checking your AD Replication Health

Check the inbound replication requests that are queued.

Repadmin /Queue

Checking the queue during replication

Check the replication status

Repadmin /Showrepl

Page | 377
Showing full replication status

Synchronize replication between replication partners

Repadmin /syncall

Page | 378
Running the /Syncall switch to force replication

Force the Knowledge Consistency Checker to recalculate the topology

Repadmin /KCC

Using the /KCC switch to tell the KCC to manually re-check all replication partners
are valid
How to monitor AD replication: Commands and tools

Besides the RepAdmin.exe command-line tool, there’s also a Graphical User

Interface (GUI) front-end called Active Directory Replication Status Tool.

The Active Directory Replication Status Tool (ADREPLSTATUS) does some

analyzing of the replication status for domain controllers in an Active Directory
domain or forest. ADREPLSTATUS is essentially a helpful, front-end GUI for the
commands I showed you above. This is similar to REPADMIN /SHOWREPL * /CSV
imported into Excel, but with significant enhancements.

Page | 379
The Active Directory Replication Status Tool

Specific capabilities for this tool include:

• Expose Active Directory replication errors occurring in a domain or forest

• Prioritize errors that need to be resolved in order to avoid the creation of lingering objects in
Active Directory forests
• Help administrators and support professionals resolve replication errors by linking to Active
Directory replication troubleshooting content on Microsoft TechNet
• Allow replication data to be exported to source or destination domain administrators or support
professionals for offline analysis

To download the Active Directory Replication Status Tool, click here.

Active Directory replication is quite a technical topic, but we hope this guide helped you to
understand everything you need to know about primary replication components, Active
Directory replication objects, and replication management.

Page | 380
How to Restore Active Directory

Page | 381