Introduction

Learn about the fundamentals of Active Directory Domain Services (AD DS) in Windows Server,
including forests, domains, sites, domain controllers, organizational units (OUs), users, and groups.

Scenario
Contoso, Ltd. is a financial services company in Seattle with major offices located throughout the
world. Most of its compute environment runs on-premises on Windows Server. This includes
virtualized workloads on Windows Server 2016 hosts.

Contoso IT staff are migrating Contoso on-premises servers to Windows Server 2022. As part of the
migration, Contoso is evaluating its current AD DS environment. As a Windows Server administrator,
you’ll be responsible for managing AD DS objects, such as users, groups, and OUs.

After completing this module, you’ll understand the fundamental AD DS structure and how users,
groups, and group managed service accounts, and how they relate to OUs.

Learning objectives
After completing this module, you'll be able to:

• Describe AD DS.
• Describe users, groups, and computers.
• Identify and describe AD DS forests and domains.
• Describe OUs.
• Manage objects and their properties in AD DS.

Define AD DS
AD DS and its related services form the foundation for enterprise networks that run Windows
operating systems. The AD DS database is the central store of all the domain objects, such as user
accounts, computer accounts, and groups. AD DS provides a searchable, hierarchical directory and
a method for applying configuration and security settings for objects in an enterprise.

AD DS includes both logical and physical components. You should understand how AD DS
components work together so that you can manage your infrastructure efficiently. In addition, you
can use AD DS options to perform actions such as:

• Installing, configuring, and updating apps.

• Managing the security infrastructure.
• Enabling Remote Access Service and DirectAccess.
• Issuing and managing digital certificates.

What are the logical components?

AD DS logical components are structures that you use to implement an AD DS design that is
appropriate for an organization. The following table describes the types of logical components that
an AD DS database contains.

Logical component - Description

Partition

A partition, or naming context, is a portion of the AD DS database. Although the database consists of one file
named Ntds.dit, different partitions contain different data. For example, the schema partition contains a copy
of the Active Directory schema. The configuration partition contains the configuration objects for the forest,
and the domain partition contains the users, computers, groups, and other objects specific to the domain.
Active Directory stores copies of partitions on multiple domain controllers and updates them through directory
replication.

Schema

A schema is the set of definitions of the object types and attributes that you use to define the objects created
in AD DS.

Domain

A domain is a logical administrative container for objects such as users and computers. A domain maps to a
specific partition and you can organize the domain with parent-child relationships to other domains.

Domain tree

A domain tree is a hierarchical collection of domains that share a common root domain and a contiguous
Domain Name System (DNS) namespace.

Forest

A forest is a collection of one or more domains that have a common AD DS root, a common schema, and a
common global catalog.

OU

An OU is a container object for users, groups, and computers that provides a framework for delegating
administrative rights and administration by linking Group Policy Objects (GPOs).

Container

A container is an object that provides an organizational framework for use in AD DS. You can use the default
containers, or you can create custom containers. You can't link GPOs to containers.

What are the physical components?

Physical components in AD DS are those objects that are tangible, or that described tangible
components in the real world.
The following table describes some of the physical components of AD DS.

Physical component - Description

Domain controller

A domain controller contains a copy of the AD DS database. For most operations, each domain controller can
process changes and replicate the changes to all the other domain controllers in the domain.

Data store

A copy of the data store exists on each domain controller. The AD DS database uses Microsoft Jet database
technology and stores the directory information in the Ntds.dit file and associated log files. The
C:\Windows\NTDS folder stores these files by default.

Global catalog server

A global catalog server is a domain controller that hosts the global catalog, which is a partial, read-only copy
of all the objects in a multiple-domain forest. A global catalog speeds up searches for objects that might be
stored on domain controllers in a different domain in the forest.

Read-only domain controller (RODC)

An RODC is a special, read only installation of AD DS. RODCs are common in branch offices where physical
security is not optimal, IT support is less advanced than in the main corporate centers, or line-of-business
applications need to run on a domain controller.
Site

A site is a container for AD DS objects, such as computers and services that are specific to a physical location.
This is in comparison to a domain, which represents the logical structure of objects, such as users and groups,
in addition to computers.

Subnet

A subnet is a portion of the network IP addresses of an organization assigned to computers in a site. A site can
have more than one subnet.

Define users, groups, and computers

In addition to the high-level components and objects, AD DS contains other objects such as users,
groups, and computers.

Create user objects

In AD DS, you must provide all users that require access to network resources with a user account.
With this user account, users can authenticate to the AD DS domain and access network resources.

In Windows Server, a user account is an object that contains all the information that defines a user.
A user account includes:

• The username.
• A user password.
• Group memberships.

A user account also contains settings that you can configure based on your organizational
requirements.
The username and password of a user account serve as the user’s sign-in credentials. A user object
also includes several other attributes that describe and manage the user. You can use the following
to create and manage user objects in AD DS:

• Active Directory Administrative Center.

• Active Directory Users and Computers.
• Windows Admin Center.
• Windows PowerShell.
• The dsadd command-line tool.

What are managed service accounts?

Many apps contain services that you install on the server that hosts the program. These services
typically run at server startup or are triggered by other events. Services often run in the background
and don't require any user interaction. For a service to start up and authenticate, you use a service
account. A service account might be an account that is local to the computer, such as the built-in
Local Service, Network Service, or Local System accounts. You also can configure a service account
to use a domain-based account located in AD DS.

To help centralize administration and to meet program requirements, many organizations choose
to use a domain-based account to run program services. While this does provide some benefit over
using a local account, there are a number of associated challenges, such as the following:

• Extra administration effort might be necessary to manage the service account password
securely.
• It can be difficult to determine where a domain-based account is being used as a service
account.
• Extra administration effort might be necessary to manage the service principal name (SPN).
Windows Server supports an AD DS object, named a managed service account, which you use to
facilitate service-account management. A managed service account is an AD DS object class that
enables:

• Simplified password management.

• Simplified SPN management.

What are group managed service accounts?

Group managed service accounts enable you to extend the capabilities of standard managed service
accounts to more than one server in your domain. In server farm scenarios with Network Load
Balancing (NLB) clusters or IIS servers, there often is a need to run system or program services under
the same service account. Standard managed service accounts can't provide managed service
account functionality to services that are running on more than one server. By using group managed
service accounts, you can configure multiple servers to use the same managed service account and
still retain the benefits that managed service accounts provide, like automatic password maintenance
and simplified SPN management.

To support group managed service account functionality, your environment must meet the following
requirement:

• You must create a KDS root key on a domain controller in the domain.

To create the KDS root key, run the following command from the Active Directory Module for
Windows PowerShell on a Windows Server domain controller

Add-KdsRootKey –EffectiveImmediately

You create group managed service accounts by using New-ADServiceAccount Windows PowerShell
cmdlet with the –PrinicipalsAllowedToRetrieveManagedPassword parameter.

For example:

New-ADServiceAccount -Name LondonSQLFarm -PrincipalsAllowedToRetrieveManagedPassword SEA-

SQL1, SEA-SQL2, SEA-SQL3

What are group objects?

Although it might be practical to assign permissions and rights to individual user accounts in small
networks, this becomes impractical and inefficient in large enterprise networks.

For example, if several users need the same level of access to a folder, it's more efficient to create a
group that contains the required user accounts, and then assign the required permissions to the
group.
Tip

As an added benefit, you can change users’ file permissions by adding or removing them from
groups rather than editing the file permissions directly.

Before you implement groups in your organization, you must understand the scope of various AD
DS group types. In addition, you must understand how to use group types to manage access to
resources or to assign management rights and responsibilities.

Group types

In a Windows Server enterprise network, there are two types of groups, described in the following
table.

Group type - Description

Security

Security groups are security-enabled, and you use them to assign permissions to various resources. You can
use security groups in permission entries in access control lists (ACLs) to help control security for resource
access. If you want to use a group to manage security, it must be a security group.
Distribution

Email applications typically use distribution groups, which are not security-enabled. You also can use security
groups as a means of distribution for email applications.

Note

When you create a group, you choose the group type and scope. The group type determines the
capabilities of the group.

Group scopes

Windows Server supports group scoping. The scope of a group determines both the range of a
group’s abilities or permissions and the group membership. There are four group scopes.

• Local. You use this type of group for standalone servers or workstations, on domain-
member servers that are not domain controllers, or on domain-member workstations.
Local groups are available only on the computer where they exist. The important
characteristics of a local group are:
o You can assign abilities and permissions on local resources only, meaning on
the local computer.
o Members can be from anywhere in the AD DS forest.
• Domain-local. You use this type of group primarily to manage access to resources or
to assign management rights and responsibilities. Domain-local groups exist on domain
controllers in an AD DS domain, and so, the group’s scope is local to the domain in
which it resides. The important characteristics of domain-local groups are:
o You can assign abilities and permissions on domain-local resources only,
which means on all computers in the local domain.
o Members can be from anywhere in the AD DS forest.
• Global. You use this type of group primarily to consolidate users who have similar
characteristics. For example, you might use global groups to join users who are part of
a department or a geographic location. The important characteristics of global groups
are:
o You can assign abilities and permissions anywhere in the forest.
o Members can be from the local domain only and can include users, computers,
and global groups from the local domain.
• Universal. You use this type of group most often in multidomain networks because it
combines the characteristics of both domain-local groups and global groups.
Specifically, the important characteristics of universal groups are:
o You can assign abilities and permissions anywhere in the forest similar to how
you assign them for global groups.
o Members can be from anywhere in the AD DS forest.

What are computer objects?

Computers, like users, are security principals, in that:
 • They have an account with a sign-in name and password that Windows changes
automatically on a periodic basis.
• They authenticate with the domain.
• They can belong to groups and have access to resources, and you can configure them
by using Group Policy.

A computer account begins its lifecycle when you create the computer object and join it to your
domain. After you join the computer account to your domain, day-to-day administrative tasks
include:

• Configuring computer properties.

• Moving the computer between OUs.
• Managing the computer itself.
• Renaming, resetting, disabling, enabling, and eventually deleting the computer object.

Computers container

Before you create a computer object in AD DS, you must have a place to put it. The Computers
container is a built-in container in an AD DS domain. This container is the default location for the
computer accounts when a computer joins the domain.

This container is not an OU. Instead, it is an object of the Container class. Its common name is
CN=Computers. There are subtle but important differences between a container and an OU. You
cannot create an OU within a container, so you cannot subdivide the Computers container. You also
cannot link a Group Policy Object to a container. Therefore, we recommend that you create custom
OUs to host computer objects, instead of using the Computers container.

Define AD DS forests and domains

An AD DS forest is a collection of one or more AD DS trees that contain one or more AD DS domains.
Domains in a forest share:

• A common root.
• A common schema.
• A global catalog.

An AD DS domain is a logical administrative container for objects such as:

• Users
• Groups
• Computers

What is an AD DS forest?
A forest is a top-level container in AD DS. Each forest is a collection of one or more domain trees
that share a common directory schema and a global catalog. A domain tree is a collection of one or
more domains that share a contiguous namespace. The forest root domain is the first domain that
you create in the forest.

The forest root domain contains objects that don't exist in other domains in the forest. Because you
always create these objects on the first domain controller, a forest can consist of as few as one
domain with a single domain controller, or it can consist of several domains across multiple domain
trees.

The following graphic displays Contoso.com as the forest root domain. Beneath are two
domains, Adatum.com in a separate tree, and Seattle.Contoso.com as a child of Contoso.com.

The following objects exist in the forest root domain:

• The schema master role.

 • The domain naming master role.
• The Enterprise Admins group.
• The Schema Admins group.
Note

Although the schema and domain naming master roles are assigned initially in the root domain on
the first domain controller you create, you can move them to other domain controllers anywhere in
the forest.

An AD DS forest is often described as:

• A security boundary. By default, no users from outside the forest can access any
resources inside the forest. In addition, all the domains in a forest automatically trust
the other domains in the forest. This makes it easy to enable access to resources for all
the users in a forest, regardless of the domain to which they belong.
• A replication boundary. An AD DS forest is the replication boundary for the
configuration and schema partitions in the AD DS database. Therefore, organizations
that want to deploy applications with incompatible schemas must deploy additional
forests. The forest is also the replication boundary for the global catalog. The global
catalog makes it possible to find objects from any domain in the forest.
Tip

Typically, an organization creates only one forest.

The following objects exist in each domain (including the forest root):

• The RID master role.

• The Infrastructure master role.
• The PDC emulator master role.
• The Domain Admins group.

What is an AD DS domain?
An AD DS domain is a logical container for managing user, computer, group, and other objects. The
AD DS database stores all domain objects, and each domain controller stores a copy of the database.

The following graphic displays an AD DS domain. It contains users, computers, and groups.
The most commonly used objects are described in the following table:

Object - Description

User accounts

User accounts contain information about users, including the information required to authenticate a user during
the sign-in process and build the user's access token.

Computer accounts

Each domain-joined computer has an account in AD DS. You can use computer accounts for domain-joined
computers in the same way that you use user accounts for users.

Groups

Groups organize users or computers to simplify the management of permissions and Group Policy Objects in
the domain.

Note

AD DS allows a single domain to contain nearly two billion objects. This means that most
organizations need only deploy a single domain.

An AD DS domain is often described as:

• A replication boundary. When you make changes to any object in the domain, the
domain controller where the change occurred replicates that change to all other domain
controllers in the domain. If multiple domains exist in the forest, only subsets of the
changes replicate to other domains. AD DS uses a multi-master replication model that
allows every domain controller to make changes to objects in the domain.
• An administrative unit. The AD DS domain contains an Administrator account and a
Domain Admins group. By default, the Administrator account is a member of the
 Domain Admins group, and the Domain Admins group is a member of every local
Administrators group of domain-joined computers. Also, by default, the Domain Admins
group members have full control over every object in the domain.
Note

The Administrator account in the forest root domain has additional rights.

An AD DS domain provides:

• Authentication. Whenever a domain-joined computer starts or a user signs in to a

domain-joined computer, AD DS authenticates it. Authentication verifies that computer
or user has the proper identity in AD DS by verifying its credentials.
• Authorization. Windows uses authorization and access control technologies to
determine whether to allow authenticated users to access resources.
Tip

Organizations with decentralized administrative structures or multiple locations might consider

implementing multiple domains in the same forest to accommodate their administrative needs.

What are trust relationships?

AD DS trusts enable access to resources in a complex AD DS environment. When you deploy a single
domain, you can easily grant access to resources within the domain to users and groups from the
domain. When you implement multiple domains or forests, you should ensure that the appropriate
trusts are in place to enable the same access to resources.

In a multiple-domain AD DS forest, two-way transitive trust relationships generate automatically

between AD DS domains so that a path of trust exists between all the AD DS domains.

Note

The trusts that create automatically in the forest are all transitive trusts, which means that if domain
A trusts domain B, and domain B trusts domain C, then domain A trusts domain C.

You can deploy other types of trusts. The following table describes the main trust types.
When you set up trusts between domains within the same forest, across forests, or with an external
realm, Windows Server creates a trusted domain object to store the trusts' information, such as
transitivity and type, in AD DS. Windows Server stores this trusted domain object in the System
container in AD DS.

Define OUs
An OU is a container object within a domain that you can use to consolidate users, computers,
groups, and other objects. You can link Group Policy Objects (GPOs) directly to an OU to manage
the users and computers contained in the OU. You can also assign an OU manager and associate a
COM+ partition with an OU.

You can create new OUs in AD DS by using:

• Active Directory Administrative Center.

• Active Directory Users and Computers.
• Windows Admin Center.
• Windows PowerShell with the Active Directory PowerShell module.

Why create OUs?

There are two reasons to create an OU:

• To consolidate objects to make it easier to manage them by applying GPOs to the

collective. When you assign GPOs to an OU, the settings apply to all the objects within
the OU. GPOs are policies that administrators create to manage and configure settings
for computers or users. You deploy the GPOs by linking them to OUs, domains, or sites.
• To delegate administrative control of objects within the OU. You can assign
management permissions on an OU, thereby delegating control of that OU to a user or
a group within AD DS, in addition to the Domain Admins group.

You can use OUs to represent the hierarchical, logical structures within your organization. For
example, you can create OUs that represent the departments within your organization, the
geographic regions within your organization, or a combination of both departmental and
geographic regions. You can use OUs to manage the configuration and use of user, group, and
computer accounts based on your organizational model.

What are the generic containers?

AD DS has several built-in containers, or generic containers, such as Users and Computers. These
containers store system objects or function as the default parent objects to new objects that you
create. Don't confuse these generic container objects with OUs. The primary difference between OUs
and containers is the management capabilities. Containers have limited management capabilities.
For example, you can't apply a GPO directly to a container.
Installing AD DS creates the Domain Controllers OU and several generic container objects by default.
AD DS primarily uses some of these default objects, which are also hidden by default. The following
objects are displayed by default:

• Domain. The top level of the domain organizational hierarchy.

• Builtin container. A container that stores several default groups.
• Computers container. The default location for new computer accounts that you create
in the domain.
• Foreign Security Principals container. The default location for trusted objects from
domains outside the local AD DS domain that you add to a group in the local AD DS
domain.
• Managed Service Accounts container. The default location for managed service
accounts. AD DS provides automatic password management in managed service
accounts.
• Users container. The default location for new user accounts and groups that you create
in the domain. The Users container also holds the administrator, the guest accounts for
the domain, and some default groups.
• Domain Controllers OU. The default location for domain controllers' computer accounts.
This is the only OU that is present in a new installation of AD DS.

There are several containers that you can review when you select Advanced Features. The following
table describes the objects that are hidden by default.

Object - Description

LostAndFound

This container holds orphaned objects.

Program Data

This container holds Active Directory data for Microsoft applications, such as Active Directory Federation
Services (AD FS).

System

This container holds the built-in system settings.

NTDS Quotas

This container holds directory service quota data.

TPM Devices

This container stores the recovery information for Trusted Platform Module (TPM) devices.

Note

Containers in an AD DS domain cannot have GPOs linked to them. To link GPOs to apply
configurations and restrictions, create a hierarchy of OUs and then link the GPOs to them.

Use a hierarchical design

The administrative needs of the organization dictate the design of an OU hierarchy. Geographic,
functional, resource, or user classifications could all influence the design. Whatever the order, the
hierarchy should make it possible to administer AD DS resources as effectively and flexibly as
possible. For example, if you need to configure all IT administrators’ computers in a certain way, you
can group all the computers in an OU and then assign a GPO to manage those computers.

You also can create OUs within other OUs. For example, your organization might have multiple
offices, each with its own IT administrator who is responsible for managing user and computer
accounts. In addition, each office might have different departments with different computer-
configuration requirements. In this situation, you can create an OU for each office, and then within
each of those OUs, create an OU for the IT administrators and an OU for each of the other
departments.

Although there is no limit to the number of levels in your OU structure, limit your OU structure to a
depth of no more than 10 levels to ensure manageability. Most organizations use five levels or fewer
to simplify administration. Note that applications that work with AD DS can impose restrictions on
the OU depth within the hierarchy for the parts of the hierarchy that they use.

Manage objects and their properties in AD DS

Managing the AD DS environment is one of the most common tasks an IT pro performs. There are
several tools that you can use to manage AD DS.

Active Directory Administrative Center

The Active Directory Administrative Center provides a GUI that is based on Windows PowerShell.
This enhanced interface allows you to perform AD DS object management by using task-oriented
navigation, and it replaces the functionality of Active Directory Users and Computers.

Tasks that you can perform by using the Active Directory Administrative Center include:

• Creating and managing user, computer, and group accounts.

• Creating and managing OUs.
• Connecting to and managing multiple domains within a single instance of the Active
Directory Administrative Center.
• Searching and filtering AD DS data by building queries.
• Creating and managing fine-grained password policies.
• Recovering objects from the Active Directory Recycle Bin.
• Managing objects that the Dynamic Access Control feature requires.

Windows Admin Center

Windows Admin Center is a web-based console that you can use to manage server computers and
computers that are running Windows 10. Typically, you use Windows Admin Center to manage
servers instead of using Remote Server Administration Tools (RSAT).

Windows Admin Center works with any browser that is compliant with modern standards, and you
can install it on computers that run Windows 10 and Windows Server with Desktop Experience.

Note

You can’t install Windows Admin Center on a server computer that is configured as an AD DS domain
controller.

With a decreasing number of exceptions, Windows Admin Center supports most current Windows
Server and Windows 10 administrative functionality. However, Microsoft intends that Windows
Admin Center will eventually support all the administrative functionality that is presently available
through RSAT.

To use Windows Admin Center, you must first download and install it. You can download Windows
Admin Center from the Microsoft download website. After downloading and installing Windows
Admin Center, you must enable the appropriate TCP port on the local firewall. On a Windows 10
computer (in standalone mode), this defaults to 6516. On Windows Server (in gateway mode), this
defaults to TCP 443. In both cases, you can change it during setup.

Note

Unless you are using a certificate from a trusted CA, the first time you run Windows Admin Center,
it prompts you to select a client certificate. Ensure you select the certificate labeled Windows Admin
Center Client.

Remote Server Administration Tools

RSAT is a collection of tools which enables you to manage Windows Server roles and features
remotely.
Note

You no longer need to download RSAT. Instead, you enable it from the Settings app. In Settings,
search for Manage optional features, select Add a feature, and then select the appropriate RSAT
tools from the returned list. Select Install to add the feature.

You can install the consoles available within RSAT on computers running Windows 10 or on server
computers that are running the Server with Desktop Experience option of a Windows Server
installation. Until the introduction of Windows Admin Center, RSAT consoles were the primary
graphical tools for administering the Windows Server operating system.

Other AD DS management tools

Other management tools that you'll use to perform AD DS administration are described in the
following table.
Demonstration
The following video demonstrates how to manage objects in AD DS by using Active Directory
Administrative Center. The main steps in the process are:

1. From Server Manager, open Active Directory Administrative Center.

2. Select Dynamic Access Control in the Contoso domain.
3. Perform a global search and review the results.
4. Reset the password for a user in the Contoso domain.
5. Create a new computer object called SEA-CL4.
6. Open the new computer object and review its properties, including its Extensions.
7. Review the Windows PowerShell history and examine the New-ADComputer command.

Contoso IT staff are migrating Contoso on-premises servers to Windows Server 2022. As part of the
migration, Contoso evaluated its current AD DS environment. As a Windows Server administrator,
you've been responsible for managing AD DS objects, such as users, groups, and OUs. You now
understand the fundamental AD DS structure and how users, groups, and group managed service
accounts relate to OUs.

Manage AD DS domain controllers and FSMO

roles
Learn about essential AD DS domain controllers management and maintenance tasks, including their
deployment, backup and recovery, and schema management. Find out about design considerations
for optimal number, roles, and location of domain controllers.

Learning objectives
After completing this module, you'll be able to:
• Deploy AD DS domain controllers.
• Maintain AD DS domain controllers.
• Describe the AD DS global catalog role and its placement considerations.
• Describe AD DS operations master roles, their placement considerations, and their
management tasks.
• Describe AD DS schema and its management tasks.

Introduction
Learn about essential management and maintenance tasks for Active Directory Domain Services (AD
DS) domain controllers, including their deployment, backup and recovery, and schema management.
Find out about design considerations regarding the optimal number, roles, and location of domain
controllers.

Scenario
Contoso, Ltd. is a financial services company in Seattle with major offices located throughout the
world. Most of its compute environment runs on-premises on Windows Server. This includes
virtualized workloads on Windows Server 2016 hosts.

Contoso IT staff are migrating Contoso on-premises servers to Windows Server 2022. As part of the
migration, Contoso plans to expand into additional sites and use virtualization to help expedite
bringing a new site online. The company is also generating larger volumes of data with plans for
even more data in the future. Because of this, the company needs flexible storage options. Finally,
Contoso plans to increase their use of virtualization to optimize their computing environment
because many physical servers are underutilized.

As a newly hired Windows Server administrator, you'll be responsible for managing and maintaining
Active Directory Domain Services (AD DS) operations, including domain controller deployments, and
AD DS backup and recovery. You also need to identify and implement the optimal placement of
such AD DS roles as operation masters or global catalog. In addition, you've been asked to
implement custom schema extensions to accommodate deployment of a newly developed in-house
application.

After completing this module, you'll understand how to accomplish these tasks.

Learning objectives
After completing this module, you'll be able to:

• Deploy and maintain AD DS domain controllers.

• Describe the AD DS global catalog role and its placement considerations.
• Describe AD DS operations master roles, their placement considerations, and their
management tasks.
• Describe the AD DS schema and its management tasks.

Prerequisites
To get the best learning experience from this module, it's important that you have knowledge and
experience of the following areas:

• Windows Server 2012 or Windows Server 2016.

• Core networking technologies.
• AD DS.

Deploy AD DS domain controllers

Domain controllers authenticate all users and computers in a domain. Therefore, it's critical to ensure
the optimal number and placement of domain controllers in any AD

Question - Comments

Are you installing a new forest, a new tree, or an additional domain controller for an existing domain?

Answering this question determines what additional information you might need, such as the parent domain
name.

What is the Domain Name System (DNS) name for the AD DS domain?

When you create the first domain controller for a domain, you must specify the fully qualified domain name
(FQDN). When you add a domain controller to an existing domain or forest, you use the existing domain
name.

Which level will you choose for the forest functional level?

The forest functional level determines the available forest features and the supported domain controller
operating system (OS). This also sets the minimum domain functional level for the domains in the forest.

Which level will you choose for the domain functional level?
The domain functional level determines the domain features that will be available and the supported domain
controller operating systems.

Will the domain controller be a DNS server?

You can install the DNS role as part of the domain controller deployment.

Will the domain controller host the global catalog?

This option is selected by default.

Will the domain controller be a read-only domain controller (RODC)?

This option is not available for the first domain controller in a forest.

What will be the Directory Services Restore Mode (DSRM) password?

This is necessary for restoring AD DS database objects from a backup.

What is the NetBIOS name for the AD DS domain?

When you create the first domain controller for a domain, you must specify the NetBIOS name for the domain.

Where will the database, log files and SYSVOL folders be created?

By default, the database and log files folder is located at C:\Windows\NTDS. By default, the SYSVOL folder
is located at C:\Windows\SYSVOL.

DS environment, especially in larger, distributed environments such as the one that Contoso is
transitioning to.

Deploy AD DS domain controllers in an on-premises

environment
The domain controller deployment process has two steps. First, you install the binaries necessary to
implement the domain controller role. For this purpose, you can use Windows Admin Center or
Server Manager. At the end of the initial installation process, you have installed the AD DS files, but
not yet configured AD DS on the server. The second step is to configure AD DS role. The simplest
way to perform this configuration is by using the Active Directory Domain Services Configuration
Wizard. You start the wizard by selecting the AD DS link in Server Manager.

As part of AD DS role configuration, you need to provide answers to the questions in the following
table:
Install a domain controller on a Server Core installation of Windows Server

A Windows Server computer that is running a Server Core installation doesn't have the Server
Manager graphical user interface (GUI). Therefore, you must use alternative methods to install the
files for the domain controller role, and to install the domain controller role itself. You can use
Windows Admin Center, Server Manager, Windows PowerShell, or Remote Server Administration
Tools (RSAT) installed on any supported version of Windows Server that has the Desktop
Experience feature, or any supported Windows client such as Windows 10.

Install a domain controller from media

If you have a network connection between sites that is slow, unreliable, or costly, you might find it
beneficial to add another domain controller at a remote location or branch office. In this scenario,
to significantly reduce the amount of traffic moving over the wide area network (WAN) link, you can
create an AD DS backup (perhaps to a USB drive) and take this backup to the remote location. When
you're at the remote location and run Server Manager to install AD DS, you can select the Install
from media option. Most of the copying occurs locally. In this scenario, the WAN link transfers only
security-related traffic and AD DS changes following the backup. The WAN link also helps ensure
that the new domain controller receives any changes made to the central AD DS after you created
the Install from media backup.

Branch office considerations

When you deploy a domain controller in a branch office that can't guarantee physical security, you
can use additional measures to reduce the impact of a security breach. One option is to deploy an
RODC. The RODC contains a read-only copy of the AD DS database, and by default, it doesn't cache
any user passwords. However, you can configure the RODC to cache the passwords for users in the
branch office. If an RODC is compromised, the potential loss of information risk is much lower than
with a full read/write domain controller.

Upgrade domain controllers from the previous version

The process for upgrading a domain controller is the same for any version of Windows Server
starting with Windows Server 2012 R2 through Windows Server 2022. You can upgrade to a
Windows Server 2022 domain using either of the following methods:

• Upgrade the OS on existing domain controllers that are running Windows Server 2012 R2 or
later.
• Add servers running Windows Server 2022 as domain controllers in a domain that already has
domain controllers running earlier Windows Server versions.

We recommend the latter method, because when you finish you'll have a clean installation of both
the Windows Server 2022 OS and the AD DS database. Whenever you add a new domain controller,
Windows Server automatically updates the domain DNS records so clients will be able to locate and
use this domain controller.
Deploy AD DS domain controllers in Azure virtual machines
(VMs)
Azure provides infrastructure as a service (IaaS), which is a cloud-based virtualization platform. When
deploying AD DS on Azure IaaS, you're installing the domain controller on a VM, so all the rules that
apply to virtualizing a domain controller apply to deploying AD DS in Azure.

When you implement AD DS in Azure, consider the following:

• Network topology. To meet AD DS requirements, you must create an Azure Virtual Network and
attach your VMs to it. If you intend to join an existing on-premises AD DS infrastructure, you
can extend network connectivity to your on-premises environment. You can achieve this through
hybrid connectivity methods such as a virtual private network (VPN) connection or an Azure
ExpressRoute circuit, depending on the speed, reliability, and security that your organization
requires.
• Site topology. As with a physical site, you should define and configure an AD DS site that
corresponds to the IP address space of your Azure Virtual Network.
• IP addressing. All Azure VMs receive Dynamic Host Configuration Protocol (DHCP) addresses by
default, but you can configure static addresses that will persist across restarts and shutdowns.
• DNS. Azure's built-in DNS does not meet the requirements of AD DS, such as Dynamic DNS and
service (SRV) resource records. To provide DNS functionality for an AD DS environment in Azure,
you can use the Windows Server DNS server role or other DNS solutions available in Azure, such
as Azure private DNS zones.
• Disks. You have control of caching Azure VM disk configurations. When you install AD DS to an
Azure VM, you should place the NTDS.DIT and SYSVOL files on one of its data disks, and set
the Host Cache Preference setting of that disk to NONE.

Maintain AD DS domain controllers

There are operational aspects applicable to every AD DS environment that focus on maintaining
business continuity of the authentication services. This includes backup and recovery of domain
controllers, and the AD DS objects they host.

Maintain AD DS domain controller availability

Domain controllers use a multi-master replication process to copy data from one domain controller
to another. As a best practice, an AD DS domain should have at least two domain controllers per AD
DS site. This makes the AD DS database more available and spreads the authentication load during
peak sign-in times.

Important

For most enterprises, consider two domain controllers per geographical region as the absolute
minimum to help ensure high availability and performance.

Plan for AD DS backup and restore

Maintaining the reliability of the Active Directory data is important. Performing regular backups can
play a part in this process but knowing how to restore or recover data after a failure is vital.

Restoring deleted AD DS objects by using Recycle Bin

Because restoring objects deleted from AD DS by using traditional backup methods involves
temporary OS downtime, Windows Server offers the Active Directory Recycle Bin feature, which
provides a straightforward method to restore deleted objects with no AD DS downtime. After you
enable Active Directory Recycle Bin, the Deleted Objects container displays in Active Directory
Administrative Center. Deleted objects persist in this container until their deleted object lifetime
expires. For new AD DS deployments, that lifetime is set to 180 days, but you have the option to
change it. You can choose to restore the objects either to their original location or to an alternate
location within AD DS.

Important

You cannot use Active Directory Recycle Bin to revert changes to existing objects. In such cases,
you must use the traditional methods of backing up and restoring AD DS.

AD DS backup and restore

To restore AD DS, a backup must explicitly include system state data. System state is a collection of
critical OS and server role files that include the AD DS database and the registry.

Important

A full server backup that is used for full server recovery does not support this scenario.

To perform an AD DS restore, you must have full access to the files on the domain controller. This
requires restarting the domain controller in DSRM. If you're restarting a domain controller locally,
open the advanced startup options and choose the DSRM from the menu.

When you start a domain controller in DSRM, you will sign in as Administrator with the DSRM
password. You then can use Windows Server Backup to restore the directory database. After
completing the restore process, you must restart the server you are recovering. The domain
controller will ensure that its database is consistent with the rest of the domain by pulling from its
replication partners the changes to the directory that have occurred since the date of the backup.

Nonauthoritative restore

By default, you restore an AD DS backup as of a known good date. Essentially, you roll the domain
controller back in time. When AD DS restarts on the domain controller, the domain controller
contacts its replication partners and requests all subsequent updates. In other words, the domain
controller catches up with the rest of the domain by using standard replication mechanisms.

This type of restore is useful when the directory on a domain controller has been damaged or
corrupted, but the problem has not spread to other domain controllers. However, in some scenarios,
this approach is not suitable. For example, this will not enable you to recover an object you deleted
after the backup took place, if that deletion has replicated to other domain controllers. If you restore
a known good version of AD DS and restart the domain controller, the deletion that happened after
the backup took place will simply replicate back to the domain controller.

Authoritative restore

An authoritative restore allows you to restore a known good copy of AD DS objects, which replaces
the current version of these objects in the AD DS database. In an authoritative restore, you start with
the same sequence of steps as the nonauthoritative restore. However, before you restart the domain
controller, you mark the restored objects that you want to persist as authoritative, so they will
replicate from the restored domain controller outbound to its replication partners.

Manage the AD DS Global Catalog role

As part of planning for domain controller deployments, it's important to identify the optimal number
and placement of the global catalog role. This becomes relevant when expanding AD DS
environment to other locations, as is the case with Contoso's planned expansion.

Manage the AD DS global catalog role

The global catalog is a partial, read-only, searchable copy of all the objects in a forest. The global
catalog can help speed up searches for objects that might be stored on domain controllers in a
different domain in the forest.

Within a single domain, the AD DS database on each domain controller contains all the information
about every object in that domain. However, only a subset of this information replicates to the global
catalog servers in other domains in the forest. Within a domain, a query for an object is directed to
one of the domain controllers in that domain. However, that query does not return results about
objects in other domains within the forest. For a query to include results from other forest domains,
you must query a domain controller that is also a global catalog server.

The global catalog doesn't contain all the attributes for each object. Instead, it maintains the subset
of attributes that are most likely to be useful in cross-domain searches. These attributes include, for
example, givenName, displayName, and mail. You can change the set of attributes replicated to
the global catalog by modifying the AD DS schema.

In a multiple-domain forest, searching the global catalog can be useful in many situations. For
example, when a server that's running Microsoft Exchange Server receives an incoming email, it must
search for the recipient’s account so it can decide how to route the message. By automatically
querying the global catalog, the server can find the recipient in a multiple-domain environment.
Additionally, when users sign in to their Active Directory accounts, the domain controller that
performs the authentication must contact the global catalog to check for universal group
memberships before authenticating the users.
In a single domain, you should configure all the domain controllers to have a copy of the global
catalog. In multiple-domain and multiple-site forests, it might sometimes make sense to limit the
number of domain controllers hosting the global catalog role to reduce the volume of replication
traffic, although this is an uncommon scenario. Note, however, that this will introduce dependency
on connectivity to other sites when performing global catalog queries.

Tip

Consider configuring every domain controller as a global catalog unless you must reduce replication
traffic volume.

Manage AD DS operations masters

AD DS uses a multiple-master process to copy data between domain controllers, and automatically
implements a conflict resolution algorithm that remediates simultaneous, conflicting updates. These
provisions allow for a distributed management model, where multiple users and applications can
concurrently apply changes to AD DS objects on different domain controllers. Such a model is
necessary to support any AD DS environment with two or more domain controllers. However, it's
particularly critical for larger, distributed environments such as Contoso's. It's important to
remember though, that certain operations can be performed only by a specific role, on a specific
domain controller.

What are AD DS operations masters?

AD DS operation master roles are responsible for performing operations that are not suitable for a
multiple-master model. A domain controller that has one of these roles is an operations master. An
operations master role is also known as a Flexible Single Master Operation (FSMO) role. There are five
operations master roles:

• Schema master
• Domain-naming master
• Infrastructure master
• RID master
• PDC emulator master

By default, the first domain controller installed in a forest hosts all five roles. However, you can
transfer these roles after deploying additional domain controllers. When performing operations
master-specific changes, you must connect to the domain controller with the role. The five
operations master roles have the following distribution:

• Each forest has one schema master and one domain naming master.
• Each AD DS domain has one relative ID (RID) master, one infrastructure master, and one primary
domain controller (PDC) emulator.

You can place all five on a single domain controller, or distribute them across several domain
controllers.
Forest operations masters

A forest has the following operations master roles:

• Domain naming master. This is the domain controller that you must contact when you add or
remove a domain or make domain name changes.
Important

If the domain naming master is unavailable, you will not be able to add domains to the forest.

• Schema master. This is the domain controller in which you make all schema changes.
Important

If the schema master is unavailable, you will not be able to make changes to the schema.

Note

The Windows PowerShell command Get-ADForest, from the Active Directory module for Windows
PowerShell, displays the forest properties, including the current domain naming master and schema
master.

Domain operations masters

A domain has the following operations master roles:

• RID master. Whenever you create a security principal such as a user, computer, or group in AD
DS, the domain controller where you created the object assigns the object a unique identifying
number known as a security ID (SID). To ensure that no two domain controllers assign the same
SID to two different objects, the RID master allocates blocks of RIDs to each domain controller
within the domain to use when building SIDs.
Important

If the RID master is unavailable, you might experience difficulties adding security principals to the
domain. Also, as domain controllers use their existing RIDs, they eventually run out of them and are
unable to create new objects.

• Infrastructure master. This role maintains interdomain object references, such as when a group
in one domain has a member from another domain. In this situation, the infrastructure master
manages maintaining the integrity of this reference. For example, when you review an
object's Security tab, the system references the listed SIDs and translates them into names. In
a multiple-domain forest, the infrastructure master updates references to SIDs from other
domains with the corresponding security principal names.
Important

If the infrastructure master is unavailable, domain controllers that are not global catalogs will not be
able to perform translation of SIDs security principal names.

Important
The infrastructure master role should not reside on the domain controller that's hosting the global
catalog role unless every domain controller in the forest is configured to serve as a global catalog.
In this case, the infrastructure master role is not necessary because every domain controller knows
about every object in the forest.

• PDC emulator master. The domain controller that is the PDC emulator master serves as the time
source for the domain. The PDC emulator master in each domain in a forest synchronizes their
time with the PDC emulator master in the forest root domain. You set the PDC emulator master
in the forest root domain to synchronize with a reliable external time source. Additionally, by
default, changes to Group Policy Objects (GPOs) are by default written to the PDC Emulator
master. The PDC emulator master is also the domain controller that receives urgent password
changes. If a user's password changes, the domain controller with the PDC emulator master role
receives this information immediately. This means that if the user tries to sign in, the domain
controller in the user's current location will contact the domain controller with the PDC emulator
master role to check for recent changes. This will occur even if a domain controller in a different
location that had not yet received the new password information authenticated the user.
Important

If the PDC emulator master is unavailable, users might have trouble signing in until their password
changes have replicated to all the domain controllers.

Note

The Windows PowerShell command Get-ADDomain, from the Active Directory module for Windows
PowerShell, displays the domain properties, including the current RID master, infrastructure master,
and PDC emulator master.

Manage AD DS operations masters

In an AD DS environment where you distribute operations master roles among domain controllers,
you might need to move a role from one domain controller to another. When you perform a move
in a planned manner between two online domain controllers, the move is known as transferring the
role. In emergencies, if the current role holder is not available, the move is known as seizing the role.
When you transfer a role, the latest data from the domain controller in that role replicates to the
target server.

Important

You should seize a role only as a last resort when there is no chance for recovering the current role
holder.

Transfer operations master roles

You can transfer operations master roles by using the AD DS snap-ins that the following table lists.
Seize operations master roles

You cannot use AD DS snap-ins to seize operations master roles. Instead, you must use either
the ntdsutil.exe command-line tool or Windows PowerShell to seize roles.

Note

You can also use these tools to transfer roles.

The syntax for transferring a role and seizing a role is similar within Windows PowerShell, as the
following syntax line demonstrates:

Move-ADDirectoryServerOperationsMasterRole -Identity "<servername>" -OperationsMasterRole

"<rolenamelist>" -Force

For the preceding syntax, the noteworthy definitions are as follows:

• servername. The name of the target domain controller to which you are transferring
one or more roles.
• rolenamelist. A comma-separated list of AD DS role names to move to the target server.
• -Force. An optional parameter that you include to seize a role instead of transferring it.

Demonstration
The following video demonstrates how to:

• Identify placement of operations master roles.

• Transfer operations master roles between domain controllers.

The main steps in the process are:

 1. Create AD DS environment. Create a single domain AD DS forest containing two domain
controllers.
2. Check the placement of operations master roles. Identify which of the two domain
controllers hosts the operations master roles.
3. Transfer operations master roles between domain controllers by using the GUI tools.
Use the GUI tools to transfer the operations masters roles from the domain controller
you identified in the previous step to the other one.
4. Transfer operations master roles between domain controllers by using command-line
tools. Use the command-line tools to transfer the operations masters roles back to the
first domain controller

Manage AD DS schema
Many applications and services utilize data that's stored in an AD DS database. Some of them, such
as Contoso's newly developed in-house application that you need to implement, require that data
to be in a specific format. This, in turn, might require extending AD DS schema.

What is a schema?
AD DS stores and retrieves information from a wide variety of applications and services. It does this,
in part, by standardizing how the AD DS directory stores data. By standardizing data storage, AD DS
can retrieve, update, and replicate data while helping to maintain data integrity.

An AD DS schema is the component that defines all the object classes and attributes that AD DS
uses to store data. All domains in a forest contain a copy of the schema that applies to that forest.
Any change in the schema replicates to every domain controller in the forest via their replication
partners. However, changes originate at the schema master.

Objects

AD DS uses objects as units of storage. The schema defines all object types. Each time the directory
manages data, the directory queries the schema for an appropriate object definition. Based on the
object definition in the schema, the directory creates the object and stores the data.

Object definitions specify both the types of data that the objects can store and the data syntax. You
can only create objects that the schema defines. Because objects store data in a rigidly defined
format, AD DS can store, retrieve, and validate the data that it manages, regardless of which
application supplies it.

Relationships among objects, rules, attributes, and classes

AD DS schema objects consist of attributes, which are grouped together into classes. Each class has
rules that define which attributes are mandatory and which are optional. For example, the user class
consists of more than 400 possible attributes, including cn (the common name
attribute), givenName, displayName, objectSID, and manager. Of these attributes,
the cn and objectSID attributes are mandatory.
The user class is an example of a structural class. A structural class is the only type of class that can
have objects in an AD DS database. To modify the schema, you can create an auxiliary class with its
own attributes, and then reference it in the definition of a structural class.

Manage AD DS schema
When managing the AD DS schema, you can modify the schema only if you are a member of the
Schema Admins group in the root domain of the AD DS forest. For this purpose, you can use the
Active Directory Schema snap-in.

Important

AD DS schema does not support deletions.

You should change the schema only when necessary because the schema controls the storage of
information. Additionally, any changes made to the schema affect every domain controller. Before
you change the schema, you should review the changes and implement them only after you've
performed testing. This will help ensure that the changes Won't adversely affect the rest of the forest
or any applications that use AD DS.
Using the knowledge acquired in this module, you deployed AD DS domain controllers in the manner that
ensured the optimal placement of operation masters and global catalog roles. You also applied custom AD
DS schema extensions to accommodate deployment of a new in-house developed application.

Implement Group Policy Objects

Learn to implement Group Policy Objects (GPOs) in Active Directory Domain Services (AD DS) in
Windows Server 2019.

Learning objectives
After completing this module, you'll be able to:
• Describe GPOs.
• Describe GPO scope and inheritance.
• Describe domain-based GPOs.
• Create and configure GPOs.
• Explain GPO storage.
• Describe administrative templates and the Central Store.

Introduction
Learn to implement Group Policy Objects (GPOs) in Active Directory Domain Services (AD DS) in
Windows Server.

Scenario
Contoso, Ltd. is a financial services company in Seattle with major offices located throughout the
world. Most of its compute environment runs on-premises on Windows Server. This includes
virtualized workloads on Windows Server 2016 hosts.

Contoso IT staff is migrating Contoso on-premises servers to Windows Server 2022. As a Windows
Server administrator at Contoso, you're responsible for configuring user and computer settings.
These settings will be applied by using GPOs.

After completing this module, you’ll understand how group policies work in a Windows Server Active
Directory environment.

Learning objectives
After completing this module, you'll be able to:

• Describe GPOs.
• Describe GPO scope and inheritance.
• Describe domain-based GPOs.
• Create and configure GPOs.
• Explain GPO storage.
• Describe administrative templates and the Central Store.

Define GPOs
Since early versions of Windows Server, the Group Policy feature of Windows operating systems has
provided an infrastructure with which administrators can define settings centrally and then deploy
them to computers across their organizations.

Consequently, IT staff at Contoso can define, enforce, and update their entire configuration by using
GPO settings. By using GPO settings, they can affect an entire site or a domain within their
organization, or they can narrow their focus to a single OU.

Tip

Filtering based on security group membership and physical computer attributes also enables
Contoso to define the target for their GPO settings even further.

What is Group Policy?

Group Policy is a framework in Windows operating systems with components that reside in AD DS,
on domain controllers, and on each Windows Server and client. By using these components, you can
manage configuration in an AD DS domain. You define Group Policy settings within a GPO. A GPO
is an object that contains one or more policy settings that apply to one or more configuration
settings for a user or a computer.
Group Policy is a powerful administrative tool. You can use GPOs to push various settings to a large
number of users and computers. Because you can apply them to different levels, from the local
computer to domain, you also can focus these settings precisely. Primarily, you use Group Policy to
configure settings that you do not want users to configure. Additionally, you can use Group Policy
to standardize desktop environments on all computers in an organizational unit (OU) or in an entire
organization. You also can use Group Policy to provide additional security, to configure some
advanced system settings, and for other purposes discussed in a subsequent demonstration unit.
What are GPOs?
The most granular component of Group Policy is an individual policy setting. An individual policy
setting defines a specific configuration, such as a policy setting that prevents a user from accessing
registry-editing tools. If you define that policy setting and then apply it to a user, that user will be
unable to run tools such as Regedit.exe.

Some settings affect a user, known as user configuration settings or user policies, and some affect
the computer, known as computer configuration settings or computer policies.

Important

Settings do not affect groups directly and apply only to user and computer objects.

Group Policy manages various policy settings, and the Group Policy framework is extensible. You
can manage almost any configurable setting with Group Policy.
To define a policy setting:

1. In the Group Policy Management Editor, locate the policy setting and then select Enter.
The policy setting Properties dialog box appears.
2. Change the policy state to Enabled or Disabled. Most policy settings can have three
states: Not Configured, Enabled, and Disabled.
3. If required, configure additional values, and when complete, select OK.

GPOs store Group Policy settings. In a new GPO, every policy setting defaults to Not Configured.
When you enable or disable a policy setting, Windows Server makes a change to the configuration
of users and computers to which the GPO is applied.

Note

When you return a setting to its Not Configured value, you return it to its default value.

To create a new GPO in a domain:

 1. In Group Policy Management, right-click or access the context menu for the Group
Policy Objects container, and then select New.
2. To modify the configuration settings in a GPO, right-click or access the context menu
for the GPO, and then select Edit. This opens the Group Policy Management Editor
snap-in.

The Group Policy Management Editor displays all the policy settings that are available in a GPO in
an organized hierarchy that begins with the division between computer settings and user settings:
the Computer Configuration node and the User Configuration node.

GPOs display in a container named Group Policy Objects. The next two levels of the hierarchy are
nodes named Policies and Preferences. Progressing through the hierarchy, the Group Policy
Management Editor displays folders, called nodes or policy setting groups. The policy settings are
within the folders.

What are starter GPOs?

You can use a Starter GPO as a template from which to create other GPOs within the Group Policy
Management Console. Starter GPOs only have Administrative Template settings. You might use a
Starter GPO to provide a starting point to create new GPOs in your domain. The Starter GPO might
already have specific settings that are best practices for your environment. You can export starter
GPOs to, and import them from, cabinet (.cab) files to make distribution to other environments
simple and efficient.

Note

The Group Policy Management Console stores Starter GPOs in a folder called StarterGPOs, which is
in SYSVOL.

Note

SYSVOL is a shared folder on domain controllers.

Microsoft includes pre-configured Starter GPOs for Windows client operating systems. These Starter
GPOs have Administrative Template settings that reflect best practices that Microsoft
recommends for the configuration of the client environment.

Implement GPO scope and inheritance

Policy settings in GPOs define configuration. However, you must specify the computers or users to
which the GPO applies before the configuration changes in a GPO will affect computers or users in
your organization. This is called scoping a GPO. The scope of a GPO is the collection of users and
computers that will apply the settings in the GPO.

Important

You scope a GPO by linking it to an OU that contains the target users and computers.
Scope a GPO
You can use several methods to manage the scope of domain-based GPOs. The first is the GPO link.
In AD DS, you can link GPOs to:

• Sites
• Domains
• OUs

The site, domain, or OU then becomes the maximum scope of the GPO. The configurations that the
policy settings in the GPO specify will affect all computers and users within the site, domain, or OU,
including those in child OUs. You can link a GPO to more than one domain, OU, or site.

Caution

Linking GPOs to multiple sites in a multiple domain forest can introduce performance issues when
applying the policy, and you should avoid linking GPOs to multiple sites in this situation. This is
because, in a multi-forest multiple-site network, the GPOs are stored on the domain controllers in
the domain where the GPOs were created. The consequence of this is that computers in other
domains might need to traverse a slow wide area network (WAN) link to obtain the GPOs.

You can further narrow the scope of the GPO with one of two types of filters discussed in the
following table.

Filter - Description

Security

These specify security groups or individual user or computer objects that relate to a GPO’s scope, but to which
the GPO explicitly should or shouldn't apply.

WMI

These specify a scope by using characteristics of a system, such as an operating system version or free disk
space.
Use security filters and WMI filters to narrow or specify the scope within the initial scope that the
GPO link created. The following is an example of a WMI filter that results in a list of computers
running Windows 10.

PowerShell

select * from Win32_OperatingSystem where Version like "10.%"

GPO processing order

The GPOs that apply to a user, computer, or both don't apply all at once. GPOs apply in a particular
order. Conflicting settings that process later might overwrite settings that process first.

Group Policy follows the following hierarchical processing order:

1. Local GPOs.
2. Site-linked GPOs.
3. Domain-linked GPOs.
4. OU-linked GPOs.
5. Child OU-linked GPOs.
Important

In Group Policy application, the default rule is that the last policy (the most specific policy) applied
prevails.

For example, a policy that restricts access to the Control Panel applied at the domain level could be
reversed by a policy applied at the OU level for the objects contained in that particular OU.
If you link several GPOs to an OU, their processing occurs in the order that the administrator specifies
on the OU’s Linked Group Policy Objects tab in the Group Policy Management Console. By default,
processing is enabled for all GPO links. You can disable a container’s GPO link to block the
application of a GPO completely for a given domain or OU. For example, if you made a recent change
to a GPO and it's causing production issues, you can disable the link or links until the issue resolves.

Note

Note that if the GPO is linked to other containers, they'll continue to process the GPO if their links
are enabled.

You also can disable the user or computer configuration of a particular GPO independently from
either the user or computer. If one section of a policy is known to be empty, disabling the other
section can speed up policy processing slightly. For example, if you have a policy that only delivers
user desktop configuration, you could disable the computer section of the policy.

GPO inheritance
You can configure a policy setting in more than one GPO, which might result in GPOs conflicting
with each other. In this case, the precedence of the GPOs determines which policy setting the client
applies. A GPO with higher precedence prevails over a GPO with lower precedence. Precedence is
determined numerically. Each GPO has a precedence value. The lower the number, the higher the
precedence. Therefore, a GPO that has a precedence of one prevails over all other GPOs.

The default behavior of Group Policy is that GPOs linked to a higher-level container are inherited by
lower-level containers. When a computer starts up or a user signs in, the Group Policy Client
Extensions examines the location of the computer or user object in AD DS and evaluates the GPOs
with scopes that include the computer or user. Then, the client-side extensions apply policy settings
from these GPOs. Policies apply sequentially, beginning with the policies that link to the site,
followed by those that link to the domain, followed by those that link to OUs. This sequential
application of GPOs creates an effect called policy inheritance. Policies are inherited, which means
that the Resultant Set of Policies (RSoPs) for a user or computer will be the cumulative effect of site,
domain, and OU policies.

Block Inheritance

You can configure a domain or OU to prevent the inheritance of policy settings. This is known as
blocking inheritance. To block inheritance, right-click or access the context menu for the domain or
OU in the GPMC console tree, and then select Block Inheritance.
The Block Inheritance option is a property of a container, so it blocks all Group Policy settings from
GPOs that link to parents in the Group Policy hierarchy.

Caution

Use the Block Inheritance option sparingly because blocking inheritance makes it more difficult to
evaluate Group Policy precedence and inheritance.

Tip

With security group filtering, you can carefully scope a GPO so that it applies to only the correct
users and computers in the first place, making it unnecessary to use the Block Inheritance option.

Enforce a GPO link

Additionally, you can set a GPO link to be enforced. To enforce a GPO link, right-click or access the
context menu for the GPO link in the console tree, and then select Enforced from the shortcut menu.
When you set a GPO link to Enforced, the GPO takes the highest level of precedence. Policy settings
in that GPO prevail over any conflicting policy settings in other GPOs.

Important

An enforced link applies to child containers even when those containers are set to Block Inheritance.
The Enforced option causes the policy to apply to all objects within its scope.

Enforcement is useful when you must configure a GPO that defines a configuration that's mandated
by your corporate IT security and usage policies. Therefore, you want to ensure that other GPOs that
are linked to the same or lower levels don't override those settings. You can do this by enforcing the
GPO’s link.

Evaluating precedence

To facilitate evaluation of GPO precedence, you can simply select an OU or domain, and then select
the Group Policy Inheritance tab. This tab displays the resulting precedence of GPOs, accounting
for GPO link, link order, inheritance blocking, and link enforcement.
Important

This tab doesn't account for policies that are linked to a site, for GPO security, or WMI filtering.

Define domain-based GPOs

You can create domain-based GPOs in AD DS and store them on domain controllers. You can use
these GPOs to manage configuration centrally for the domain’s users and computers. When you
install AD DS, Windows Server creates two default GPOs:

• Default Domain Policy

• Default Domain Controllers Policy
Note

Windows computers also have local GPOs, which are primarily used when computers aren't
connected to domain environments.

Default Domain Policy

The Default Domain Policy GPO is linked to the domain, and it applies to Authenticated Users. This
GPO doesn't have any WMI filters. Therefore, it affects all users and computers in the domain. This
GPO contains policy settings that specify password, account lockout, and Kerberos version 5
authentication protocol policies.

These settings are of critical importance to the AD DS environment, and thus, make the Default
Domain Policy a critical component of Group Policy. You shouldn't add unrelated policy settings to
this GPO. If you need to configure other settings to apply broadly in your domain, create additional
GPOs that link to the domain.
Default Domain Controllers Policy
The Default Domain Controllers Policy GPO links to the OU of the domain controllers. Because
computer accounts for domain controllers are kept exclusively in the Domain Controllers OU, and
other computer accounts should be kept in other OUs, this GPO affects only domain controllers or
other computer objects that are in the Domain Controllers OU.

You should modify GPOs linked to the Domain Controllers OU to implement your auditing policies
and to assign user rights that are required on domain controllers.

Create and configure a domain-based GPO

You manage GPOs by using two primary tools:

• The Group Policy Management console

• The Group Policy Management Editor

You can also use Windows PowerShell cmdlets to manage GPOs and their settings, including those
described in the following table.

What can you manage with GPOs?

There are two major categories of policy settings: computer settings, which are contained in
the Computer Configuration node, and user settings, which are contained in the User
Configuration node:

• The Computer Configuration node contains the settings that apply to computers, regardless
of who logs on to them. Computer settings apply when the operating system starts, during
background refreshes, and every 90 to 120 minutes thereafter.
• The User Configuration node contains settings that apply when a user logs on to a computer,
during background refreshes, and every 90 to 120 minutes thereafter.
Within the Computer Configuration and User Configuration nodes are
the Policies and Preferences nodes.

The Policies nodes in Computer Configuration and User Configuration have a hierarchy of folders
that contain policy settings. Because there are thousands of settings, the scope of this course doesn't
include individual settings. However, it's worth reviewing the types of settings that you can configure.

Apply security settings

In the Windows Server operating system, GPOs include a large number of security-related settings
that you can apply to both users and computers. For example, you can enforce settings for the
domain password policy, for Windows Defender Firewall, and you can configure auditing and other
security settings. You also can configure full sets of user-rights assignments.

Manage desktop and application settings

You can use Group Policy to provide a consistent desktop and application environment for all users
in your organization. By using GPOs, you can configure each setting that affects the representation
of the user environment. You also can configure settings for some applications that support GPOs.

Deploy software

With Group Policy, you can deploy software to users and computers. You can use Group Policy to
deploy all software that is available in the .msi format. Additionally, you can enforce automatic
software installation, or you can let your users decide whether they want the software to deploy to
their computers.

Important

Deploying large software packages with GPOs might not be the most efficient way to distribute an
application to your organization’s computers. In some circumstances, it might be more effective to
distribute applications as part of the desktop computer image.

Manage Folder Redirection

With the Folder Redirection option, it is easier to back up users’ data files. By redirecting folders, you
also ensure that users have access to their data regardless of the computer to which they sign in.
Additionally, you can centralize all users’ data to one place on a network server, while still providing
a user experience that is similar to storing these folders on their computers. For example, you can
configure Folder Redirection to redirect users’ Documents folders to a shared folder on a network
server.

Configuring network settings

By using Group Policy, you can configure various network settings on client computers. For example,
you can enforce settings for wireless networks to allow users to connect only to specific Wi-Fi
network SSIDs and with predefined authentication and encryption settings. You also can deploy
policies that apply to wired network settings, and some Windows Server roles use Group Policy to
configure the client side of services, such as DirectAccess.

Troubleshooting the application of GPOs?

Group Policy inheritance, filters, and exceptions are complex, and it can often be difficult to
determine which policy settings will apply. RSoP is the net effect of GPOs applied to a user or
computer, considering GPO links, exceptions such as Enforced and Block Inheritance, and the
application of security and WMI filters.

RSoP also is a collection of tools that you can use to evaluate, model, and troubleshoot the
application of Group Policy settings. RSoP can query a local or remote computer and report the
exact settings that applied to the computer and to any user who has logged on to the computer.
RSoP also can model the policy settings that are anticipated to be applied to a user or computer
under a variety of scenarios, including moving the object between OUs or sites, or changing the
object’s group membership. With these capabilities, RSoP can help you manage and troubleshoot
conflicting policies. The following tools exist for performing RSoP analysis:

• The Group Policy Results Wizard.

• The Group Policy Modeling Wizard.
• GPResult.exe.

Demonstration
The following video demonstrates how to create, configure, and apply GPOs. The main steps in the
process are:

1. Open the Group Policy Management console.

2. Navigate to the Group Policy Objects container.
3. Create a new GPO.
4. Open the GPO for editing and modify some user settings.
5. Link the GPO to the Contoso.com domain.
6. Sign in to a client computer as an administrator and enable Remote Event Log Management
and WMI through the firewall.
7. Sign in as a standard user and review the effect of the GPO on the local computer.
8. Create a new GPO, edit its settings, and link it to an OU. Review the inheritance settings.
9. Change the security filtering settings so that the policy only applies to a group, and not
Authenticated Users.
10. Verify the effect of the change of inheritance and security filtering.

Define GPO storage

Group Policy settings present as GPOs in AD DS user interface tools, but a GPO actually includes two
components.

What are Group Policy containers and templates?

These two components are described in the following table.

Note

Similar to all AD DS objects, each Group Policy container includes a GUID attribute that uniquely
identifies the object within AD DS.

When you change the settings of a GPO, the changes are saved to the SYSVOL share. By default, the
domain controller that holds the PDC Emulator operations master role is used. Changes made are
then replicated to other domain controllers.

Tip

By default, when Group Policy refresh occurs, the client-side extensions apply settings in a GPO only
if the GPO has been updated.

The Group Policy client can identify an updated GPO by its version number, as the following
describes:

• Each GPO has a version number that increments each time you make a change.
• The version number is stored as a Group Policy container attribute and in a text file,
GPT.ini, in the Group Policy template folder.
• The Group Policy client knows the version number of each GPO it has previously applied.
• If, during the Group Policy refresh, the Group Policy client discovers that the version
number of the Group Policy container has changed, Windows Server will inform the
client-side extensions that the GPO is updated.

GPO replication
The Group Policy container and the Group Policy template both replicate between all domain
controllers in the local domain in AD DS. However, these two items use different replication
mechanisms.
 • The Group Policy container in AD DS replicates by using the Directory Replication Agent
(DRA). The DRA uses a topology that the Knowledge Consistency Checker generates,
which you can define or refine manually. The result is that the Group Policy container
replicates within seconds to all domain controllers in a site and replicates between sites
based on your intersite replication configuration.
• The Group Policy template in the SYSVOL replicates by using the Distributed File System
Replication (DFS-R).
Caution

Because the Group Policy container and Group Policy template replicate separately, it is possible for
them to become out-of-sync for a brief time. Typically, when this happens, the Group Policy
container will replicate to a domain controller first.

Systems that obtained their ordered list of GPOs from that domain controller will identify the new
Group Policy container. Those systems will then attempt to download the Group Policy template,
and they'll notice that the version numbers are not the same. A policy processing error will record
in the event logs.

If the reverse happens, and the GPO replicates to a domain controller before the Group Policy
container, clients that obtain their ordered list of GPOs from that domain controller won't be notified
of the new GPO until the Group Policy container has replicated.

Define administrative templates

Administrative template files provide most of the available GPO settings, which modify specific
registry keys. The use of administrative templates is known as a registry-based policy, because all
the settings you configure in administrative templates result in changes to the registry. For many
apps, using a registry-based policy is the simplest and best way to support the centralized
management of policy settings.

Overview of administrative templates

You can use administrative templates to control the environment of an operating system and the
user experience. There are two sets of administrative templates:

• Computer-related settings
• User-related settings

When you configure settings in the Administrative Templates node of the GPO, you make
modifications to the registry. Administrative templates have the following characteristics:

• They have subnodes that correspond to specific areas of the environment, such as
network, system, and Windows components.
 • The settings in the computer section of the Administrative Templates node edit the
HKEY_LOCAL_MACHINE hive in the registry.
• The settings in the user section of the Administrative Templates node edit the
HKEY_CURRENT_USER hive in the registry.
• Some settings exist for both user and computer.
Important

In the case of conflicting settings, the computer setting prevails.

• Some settings are available only to certain versions of Windows operating systems. For
example, you can apply several new settings only to Windows 10.
Tip

To check which Windows versions are supported, select the setting you want, and then select the
Extended tab.

The following table details the organization of the Administrative Templates node.

The All Settings node contains an alphabetically sorted list of all settings contained in all the other
nodes.

What are .admx and .adml files?

All the settings in the Administrative Templates node of a GPO are stored in files. All currently
supported operating systems store the settings in .admx files.

These settings use a standards-based XML file format known as .admx files. By default, Windows
stores .admx files in the Windows\PolicyDefinitions folder, but you can store them in a central
location.

The .admx files are language neutral. The plain language descriptions of the settings are not part of
the .admx files. Instead, they're stored in language-specific .adml files. This means that administrators
can review the same GPO and observe the policy descriptions in their own language because they
can each use their own language-specific .adml files.
The PolicyDefinitions folder stores .adml files subfolders. Each language has its own folder. For
example, the en-US folder stores the English files, and the es-ES folder stores the Spanish files. By
default, only the .adml language files for the language of the installed operating system are present.

What is the Central Store?

In domain-based enterprises, you can create a Central Store location for .admx files, which anyone
with permissions to create or edit GPOs can access. The Group Policy Management Editor
automatically reads and displays administrative templates policy settings from .admx files in the
Central Store, and then ignores the .admx files stored locally. If the domain controller or Central
Store is not available, the Group Policy Management Editor uses the local store.

The advantages of creating a Central Store are:

• You ensure that whenever someone edits a GPO, the settings in the Administrative
Templates node are always the same.
• When Microsoft releases new administrative templates for new operating systems or
apps, such as Office, you only need to update the administrative templates files in one
location.

You must create the Central Store manually, and then update it manually on a domain controller.
The domain controllers then use AD DS replication and DFS-R to replicate the data.

To create a Central Store for .admx and .adml files, create a folder and name it PolicyDefinitions in
the \\FQDN\SYSVOL\FQDN\Policies location, where FQDN is the domain name for your AD DS domain.

For example, to create a Central Store for the Seattle.Contoso.com domain, create a PolicyDefinitions
folder in the following location:

PowerShell

\\Seattle.Contoso.com\SYSVOL\Seattle.Contoso.com\policies

An administrator must copy all files and subfolders of the PolicyDefinitions folder, which on a
Windows computer resides in the Windows folder. The PolicyDefinitions folder stores all .admx files,
and subfolders store .adml files for all languages enabled on the client computer. For example, on a
Windows Server computer that has English enabled, C:\Windows\PolicyDefinitions will contain the
.admx files and in the subfolder en-US, the .adml files will contain English-based descriptions for the
settings defined in the .admx files.

Important

You must update the PolicyDefinitions folder for each feature update and for other software, such
as Windows 10 Version 2004 and Microsoft Office 2019 .admx files.

Summary
Contoso, Ltd. is a financial services company in Seattle with major offices located throughout the
world. Most of its compute environment runs on-premises on Windows Server. This includes
virtualized workloads on Windows Server 2016 hosts.

Contoso IT staff is migrating Contoso on-premises servers to Windows Server 2022. As a Windows
Server administrator at Contoso, you're responsible for configuring user and computer settings.
These settings are applied by using GPOs.

After completing this module, you’ll understand how group policies work in a Windows Server Active
Directory environment.

Manage advanced features of AD DS

Learn about advanced AD DS administration tasks, including creating trust relationships,
implementing Enhanced Security Administrative Environment (ESAE) forests, monitoring and
troubleshooting AD DS replication, and creating custom AD DS partitions.

Learning objectives
After completing this module, you'll be able to:
• Identify the purpose, types, and the process of creating trust relationships.
• Describe the purpose and the process of implementing ESAE forests.
• Monitor and troubleshoot AD DS replication.
• Identify the purpose and the process of creating custom AD DS partitions.

Learn about advanced Azure Active Directory Domain Services (AD DS) administration tasks,
including creating trust relationships, implementing Enhanced Security Administrative Environment
(ESAE) forests, monitoring and troubleshooting AD DS replication, and creating custom AD DS
partitions.

Scenario
Contoso, Ltd. is a financial services company in Seattle with major offices located throughout the
world. Most of its compute environment runs on-premises on Windows Server. This includes
virtualized workloads on Windows Server 2016 hosts.

Contoso IT staff are migrating Contoso on-premises servers to Windows Server 2022. As part of the
migration, Contoso plans to expand into additional sites and use virtualization to help expedite
bringing a new site online. The company is also generating larger volumes of data with plans for
even more data in the future. Because of this, the company needs flexible storage options. Finally,
Contoso plans to increase the use of virtualization to optimize their computing environment because
many physical servers are underutilized.

As part of its technology expansion and modernization initiative, Contoso plans to consolidate its
existing AD DS environment comprising several isolated AD DS forests, starting with the creation of
trust relationships between them. Another major change that’s scheduled to take place in the
upcoming months is a setup of an ESAE forest. Additionally, to facilitate deployment of a new in-
house developed suite of applications, it’s necessary to create a custom AD DS partition.

As an experienced Windows Server administrator, you’re responsible for planning and implementing
these changes. Throughout their implementation, you also need to ensure that the environment you
manage remains fully operational. This includes monitoring and troubleshooting AD DS replication.

Learning objectives
After completing this module, you'll be able to:

• Identify the purpose, types, and the process of creating trust relationships.
• Describe the purpose and the process of implementing ESAE forests.
• Monitor and troubleshoot AD DS replication.
• Identify the purpose and the process of creating custom AD DS partitions.

Create trust relationships

An AD DS forest represents a security boundary, providing secure authentication and authorization
for its users, computers, and applications. Sometimes, it might be necessary to extend this boundary
to include other AD DS domains and forests. This, for example, might result from mergers and
acquisitions between organizations, or from consolidation initiatives, as is the case with Contoso.

What is a trust relationship?

AD DS trusts enable access to resources in a multiple-domain and multiple-forest AD DS
environment. In a single-domain forest, all users and resources, such as file shares, printers, or
applications share the same domain, so access management is straightforward and readily available.
When you have multiple domains or forests, you need trusts to provide users in one domain with
secure access to resources in another domain.

In a multiple-domain AD DS forest, by default, domains form a tree-like structure with a two-way

transitive trust relationship between directly adjacent domains. Trust transitivity implies that a path
of trust exists between all the AD DS domains in the same forest. Additionally, you can create other
types of trusts. The following table describes the main trust types.

Create trust relationships

An AD DS forest represents a security boundary, providing secure authentication and authorization
for its users, computers, and applications. Sometimes, it might be necessary to extend this boundary
to include other AD DS domains and forests. This, for example, might result from mergers and
acquisitions between organizations, or from consolidation initiatives, as is the case with Contoso.

What is a trust relationship?

AD DS trusts enable access to resources in a multiple-domain and multiple-forest AD DS
environment. In a single-domain forest, all users and resources, such as file shares, printers, or
applications share the same domain, so access management is straightforward and readily available.
When you have multiple domains or forests, you need trusts to provide users in one domain with
secure access to resources in another domain.

In a multiple-domain AD DS forest, by default, domains form a tree-like structure with a two-way

transitive trust relationship between directly adjacent domains. Trust transitivity implies that a path
of trust exists between all the AD DS domains in the same forest. Additionally, you can create other
types of trusts. The following table describes the main trust types.
Note

Forest trust relationships provide most flexibility from the authentication standpoint. They are also
easier to establish, maintain, and administer than separate trust relationships between external,
domain-level trusts and individual domains across the two forests.
Create and configure forest trust relationships
If the AD DS environment contains multiple forests, it is possible to set up one-way or two-way trust
relationships between any pair of forests. With a one-way forest trust, you can grant users in the
trusted forest access to resources in the trusting forest. With a two-way forest trust, it becomes
possible to grant users on each side of the trust access to resources in the other forest.

When creating a trust, you specify the root domain of each forest. However, because forest trusts
are transitive for all domains in each forest, you effectively establish a trust between each pair of
domains across both forests. However, unlike trusts between multiple domains in the same forest,
forest trusts are not transitive across multiple forests. Forest trusts can only be created between two
forests and can't be implicitly extended to a third forest. This means that if you create a forest trust
between Forest 1 and Forest 2 and you create a forest trust between Forest 2 and Forest 3, Forest 1
doesn't implicitly trust Forest 3.

Forest trusts are particularly useful in scenarios that involve cross-organization collaboration,
mergers and acquisitions, or within a single organization that has more than one forest in which to
isolate Active Directory data and services. Forest trusts are also useful for application service
providers, for collaborative business extranets, and for organizations that want a solution for
administrative autonomy.

Before you can implement a forest trust, you need to ensure that DNS name resolution exists
between the forests. To implement such name resolution, you can use several different DNS
resolution techniques, such as secondary zones, stub zones, or conditional forwarding.

Configuring advanced AD DS trust settings

In some cases, you might want to limit the scope of trust relationships to minimize the possibility of
unauthorized access to resources in your forest. Several technologies can help you accomplish this
goal.

SID filtering

By default, when you establish a forest or domain trust, you can enable a domain quarantine, also
known as SID filtering. When a user authenticates in a trusted domain, the user presents an
authorization request that includes the SID attributes of all groups to which the user belongs.
Additionally, the user's authorization request includes the SID-History attribute of the user and the
user's groups. SID filtering blocks the use of SIDs present in SID-History that don't originate from
the trusted domain. This prevents a potential exploit that involves tempering with the SID-History
attribute to gain unauthorized access to resources in the trusted domain.

Selective authentication
When you create a forest trust, you can manage the scope of authentication of trusted security
principals. There are two modes of authentication for an external or forest trust:
 • Forest-wide authentication.
• Selective authentication.

Choosing the forest-wide authentication enables all users in the trusted forest to authenticate for
services and access on all computers in the trusting forest. Therefore, it is possible for resource
administrators in the trusting forest to grant users from the trusted forest permissions to resources
in the local forest. Additionally, all users from a trusted forest are considered Authenticated Users in
the trusting forest. Effectively, any resource that grants permissions to Authenticated Users becomes
accessible by users in the trusted forest.

If you choose selective authentication, users in the trusted forest are not considered Authenticated
Users in the trusting forest. Instead, you have to explicitly designate computers that they will be able
to authenticate to by granting them the Allowed to Authenticate permission on those computers.
For example, imagine that you have a forest trust with a partner organization's forest. You want to
ensure that only users from the partner organization's marketing group can access shared folders
on a specific file server. To do so, you can configure selective authentication for the trust relationship
and then grant the trusted users the right to authenticate only to that one file server.

Note

When using selective authentication, in addition to the right to authenticate, users from the trusted
forest still need file-system and folder-level permissions on the shared folders to access their
content.

Demonstration
The following video demonstrates how to:

• Configure prerequisites for trust relationships.

• Create a trust relationship.

The main steps in the process are:

1. Create two AD DS forests. Deploy two domain controllers, with each one in a separate forest.
Make sure that their names don't match.
2. Configure DNS conditional forwarding. Configure DNS conditional forwarding on each AD DS
Domain controller to provide DNS name resolution across forests.
3. Create a forest trust relationship from the first forest to the second one. Use Active Directory
Domains and Trusts to establish one-way trust relationship from the first forest to the second
forest.
4. Create a forest trust relationship from the second forest to the first one. Use Active Directory
Domains and Trusts to establish one-way trust relationship from the second forest to the first
forest.

Implement ESAE forests

As IT environments expand beyond the boundaries of internal networks, the role of identity as a
security perimeter becomes increasingly important. One way to enhance its security capabilities is
to implement the ESAE forest model, which is what Contoso is planning to do in the upcoming
months.

What is ESAE forest?

ESAE forests represent an architectural approach in which a dedicated administrative Active
Directory forest hosts privileged accounts, privileged groups, and privileged access workstations.
This ESAE forest is configured with a one-way trust relationship with a production forest. A one-way
trust relationship means that accounts from the ESAE forest can be used in the production forest,
however, accounts in the production forest can't be used in the ESAE forest. A production forest is
a forest in which administrators perform an organization’s day-to-day activities. The production
forest is then configured so that administrative tasks in the production forest can be performed only
by using accounts that the ESAE forest hosts.

ESAE forests have the following benefits:

• Locked-down accounts. Standard nonprivileged user accounts in the ESAE forest can be
configured as highly privileged in the production forest. For example, a standard user
account in the ESAE forest is a member of the Domain Admins group in a domain in the
production forest. It is possible to lock down the standard user account hosted in the
ESAE forest so that it can't sign in to hosts in the ESAE forest and can only be used to
sign in to hosts in the production forest. This design is more secure if an account is
compromised while it is used in the production forest, because the malicious hacker
can't use that account to perform administrative tasks in the ESAE forest.
• Selective authentication. ESAE forest design allows organizations to leverage the trust
relationship’s selective authentication feature. For example, sign-ins from the ESAE
forest will be restricted to specific hosts in the production forest. This is another method
 that helps limit credential exposure. For example, you can limit credential exposure
when you configure selective authentication so that privileged accounts in the
production forest can only be used on privileged access workstations or jump servers.
• Simple way to improve security. ESAE forest design provides substantive improvement
in the security of existing production forests without requiring complete rebuilding of
the production environment. The ESAE forest approach has a small hardware/software
footprint and affects only IT Operations team users. In this design, standard user
accounts remain hosted in the production forest. Only privileged administrative
accounts are hosted in the ESAE forest. Because they are hosted in a separate forest,
privileged administrative accounts can be subject to more stringent security
requirements than standard user accounts in the production forest.

What is the clean-source principle?

The clean-source principle specifies that all security dependencies are as trustworthy as the item
being secured. In the context of ESAE forests, the clean-source principle involves ensuring that all of
the security accounts and workstations that are used are trustworthy.

The clean-source principle is an important aspect of security because, if a malicious hacker can
control a security dependency, the hacker also can control the item being secured. One reason for
using the ESAE forest design approach is that it helps secure the privileged accounts that manage
the production environment.

When securing the ESAE forest, ensure that ESAE domain controllers are running on a secure
virtualization fabric and that security technologies such as device guard, credential guard, and
BitLocker are in use. The clean-source principle also applies to installation media. If installation media
is infected, then all software and operating systems that are deployed from that installation media
are untrustworthy and at risk for control by the hacker. Software obtained from vendors through
physical media needs to be validated. Software downloaded from the Internet should be checked
against vendor-provided file hashes to ensure that it hasn't been tampered with by unauthorized
third parties.

Tip

You can use the certutil.exe command, built into the Windows operating system, to compare a
downloaded file with the hash file that the vendor provided.

Implementing ESAE forests

You should consider several factors when implementing an ESAE forest. An ESAE forest should have
the following properties:

• Limit the function of the ESAE forest to hosting accounts of administrative users for the
production forest. To keep the hacker surface minimized, don't deploy applications or
additional resources in the ESAE forest.
 • The ESAE forest should be a single-domain Active Directory forest. There is no need for
multiple domains in an ESAE forest. The ESAE forest hosts only a few accounts to which
strict security policies must be applied.
• Only use one-way trusts. You should only configure a one-way trust where the
production forest trusts the ESAE forest. This means that accounts from the ESAE forest
can be used in the production forest, however, accounts from the production forest
can't be used in the ESAE forest. Accounts used for administrative tasks in the
production forest should be standard user accounts in the ESAE forest. If an account is
compromised in the production forest, it can't be used to elevate privileges in the ESAE
forest.

The ESAE forest servers need to be configured in the following ways:

• Installation media should be validated.

• Servers should run the most recent version of the Windows Server operating system.
• Servers should be updated automatically with security updates.
• Security Compliance Manager baselines should be used as the starting point for server
configuration.
• Servers should be configured with Secure Boot, BitLocker volume encryption, Credential
Guard, and Device Guard.
• Servers should be configured to block USB storage.
• Servers should be on isolated networks. Inbound and outbound Internet connections
should be blocked.

Monitor and troubleshoot AD DS

Performance and operational issues are common in real-world environments. To analyze, evaluate,
and remediate such issues affecting AD DS domain controller is a fundamental skill of any IT
professional responsible for ensuring stability and availability of an AD DS environment.

Monitor AD DS operational status

Insufficient system resources can lead to poor domain controller system performance. The four key
system resources are the central processing unit (CPU), disk subsystem, memory, and network.
Identifying and remediating bottlenecks involves close examination of system logs and performance
counters to determine which resource is currently constrained. After augmenting that resource,
performance will improve, but it might reach a plateau if it hits a new bottleneck in another system
resource.

You can use several tools in Windows Server for various types of monitoring. Most of these tools are
available by default as Windows Server components, and you can use them for real-time and
historical monitoring of AD DS and other services. The most commonly used tools are Task Manager,
Resource Monitor, Event Viewer, and Performance Monitor. With Performance Monitor, you can
review current performance statistics or historical data gathered by using data collector sets.
There are many counters that you can review and analyze to address your specific requirements,
including processor-, memory-, disk-, and network-specific counters. On a domain controller, you
also should monitor NT Directory Service (NTDS) object counters.

• Security System-Wide Statistics\Kerberos Authentications/sec. This counter tracks the number

of Kerberos authentications per second.
• Security System-Wide Statistics\NTLM Authentications. This counter tracks the number of
Windows Network LAN Manager (NTLM) authentications processed per second.

If you use System Center Operations Manager in your environment, you also have the option to
deploy the Active Directory Domain Services Management Pack for Operations Manager to monitor
and analyze operations of your domain controllers. This management pack contains many alerts,
views, tasks, and reports for a variety of AD DS functions.

Tools for monitoring and troubleshooting replication

In any AD DS domain environment containing multiple domain controllers, it is essential to monitor
AD DS replication and, in case of any issues, troubleshoot and resolve them. Performance monitor
allows you to capture and analyze Directory Replication Agent (DRA) counters, including:

• NTDS\DRA Inbound Bytes Total/sec. This counter depicts the total number of bytes replicated
into the AD DS database.
• NTDS\DRA Inbound Object. This counter depicts the number of Active Directory objects
received from neighbors through inbound replication.
• NTDS\DRA Outbound Bytes Total/sec. This counter depicts the total number of bytes replicated
out.
• NTDS\DRA Pending Replication Synchronizations. This is the number of directory
synchronizations that are in this server's queue, waiting for processing.

Two additional tools are particularly useful for reporting and analyzing replication: the Replication
Diagnostics Tool (Repadmin.exe) and the Domain Controller Diagnostics Tool (Dcdiag.exe).

Repadmin.exe

Repadmin.exe is a command-line tool that enables you to report the status of replication on each
domain controller. The information that Repadmin.exe produces can help you spot a potential
replication problem in the forest. You can review levels of detail down to the replication metadata
for specific objects and attributes, enabling you to identify where and when a problematic change
was made to AD DS. You can even use Repadmin.exe to manage the replication topology and force
replication between domain controllers.

Repadmin.exe supports several commands that perform specific tasks. You can learn about each
command by running repadmin /? from the Command Prompt. Most commands take a DC_LIST
parameter, which is simply a network label (DNS, NetBIOS name, or IP address) of a domain
controller. Some of the replication monitoring tasks that you can perform by using Repadmin.exe
include:
 • Displaying the replication partners for a domain controller. To display the replication
connections of a domain controller, enter `repadmin /showrepl DC_LIST . By default,
Repadmin.exe lists intersite connections only. Add the /repsto argument also to list intersite
connections.
• Displaying connection objects for a domain controller. Enter repadmin /showconn DC_LIST to
list the connection objects for a domain controller.
• Displaying metadata about an object, its attributes, and replication. You can learn much about
replication by examining an object on two different domain controllers to find out which
attributes have or haven't replicated. Enter repadmin /showobjmeta DC_LIST Object , where
DC_LIST indicates the domain controller or controllers to query. You can use an asterisk to
indicate all domain controllers. The Object represents the GUID of an object, which is its unique
identifier.

Dcdiag.exe

Dcdiag.exe performs several tests and reports on the overall health of replication and operational
status for AD DS. Run by itself, Dcdiag.exe performs summary tests and then reports the results. At
the other extreme, Dcdiag.exe /c runs a comprehensive list of tests. You can redirect the output to
files of various types, including XML. You also can specify one or more tests to perform by using
the /test:Test Name parameter. Tests that relate directly to replication include:

• DFSREvent. Reports any operation errors in the Distributed File System (DFS).
• Intersite. Checks for failures that would prevent or delay intrasite replication.
• KccEvent. Identifies errors in the Knowledge Consistency Checker.
• Replications. Checks for timely replication between domain controllers.
• Topology. Checks that the replication topology is connected fully for all domain controllers.
• VerifyReplicas. Verifies that all application directory partitions are instantiated fully on all domain
controllers that host replicas.

Monitoring replication with Microsoft System Center Operations Manager

Active Directory Domain Services Management Pack for Operations Manager includes replication
monitoring functionality that collects AD DS replication alerts along with performance data
representing replication latency, and the volume of both inbound and outbound replication traffic.
The management pack offers replication topology dashboards that display site links, connection
objects and broken connection objects. It also allows you to generate reports on replication
connection objects, replication site links, replication bandwidth, and replication latency.

Windows PowerShell AD DS replication cmdlets

Windows Server supports Windows PowerShell cmdlets that facilitate monitoring AD DS replication
and reviewing its configuration. The following list describes some of them.

• Get-ADReplicationConnection. Provides a specific AD DS replication connection or a set of AD

DS replication connection objects based on a specified filter
• Get-ADReplicationFailure. Provides a description of an AD DS replication failure
• Get-ADReplicationPartnerMetadata . Provides replication metadata for a set of one or more
replication partners
 • Get-ADReplicationSite. Provides a specific AD DS replication site or a set of replication site
objects based on a specified filter
• Get-ADReplicationSiteLink. Provides a specific Active Directory site link or a set of site links
based on a specified filter
• Get-ADReplicationSiteLinkBridge . Provides a specific Active Directory site link bridge or a set
of site link bridge objects based on a specified filter
• Get-ADReplicationSubnet. Provides an Active Directory subnet or a set of Active Directory
subnets based on a specified filter.

Create custom AD DS partitions

Custom applications might need to store their data in the AD DS database. Some of them rely on
schema extensions for this purpose, however, there are also others, which require creating custom
AD DS partitions. This happens to be the case with the new, Contoso's in-house developed suite of
applications that you need to help deploy.

What are AD DS partitions?

A partition, or naming context, is a portion of the AD DS database. Although the database is one file
named NTDS.dit, different partitions contain different data. Each partition is a unit of replication, and
each partition has its own replication topology. The default partitions include:

• Configuration partition. The configuration partition is created automatically when you

create the first domain controller in a forest. The configuration partition contains
information about the forest-wide AD DS structure, including which domains and sites
exist and which domain controllers exist in each domain. This partition replicates to all
domain controllers in the forest.
• Schema partition. The schema partition contains definitions of all the objects and
attributes that you can create in the data store, and the rules for creating and
manipulating them. Schema information replicates to all domain controllers in the
forest.
• Domain partition. When you create a new domain, AD DS automatically creates an
instance of the domain partition. That partition is subsequently automatically replicated
to every new domain controller in the same domain. The domain partition contains
information about all domain-specific objects, including users, groups, computers,
organizational units (OUs), and domain-related system settings.
• Application partition. The application partition stores nondomain, application-related
information that tends to be updated at a higher frequency or have a customizable
lifetime, such as a Domain Name System (DNS) partition when Active Directory–
integrated DNS is enabled. You typically have the flexibility to designate the scope of
replication of application partitions, by designating which domain controllers in a forest
will host its copies.
Note

By default, when you configure a domain controller to host Active Directory integrated DNS zones,
two separate application partitions, domainDnsZones and forestDnsZones, are created. The
domainDnsZones partition contains domain-specific DNS records and its replication scope consists
of other AD DS domain controllers that host the DNS Server role.
Create AD DS partitions
You can create and manage AD DS partitions by using the NtdsUtil.exe command-line tool.
NtdsUtil.exe also allows you to perform several other AD DS-related management tasks, such as:

• NTDS database maintenance, including creating snapshots, relocating database, files,

and offline defragmentation.
• Cleaning up domain-controller metadata following its unrecoverable failure.
• Resetting the password used to sign in to the Directory Services Restore Mode (DSRM).

Demonstration
The following video demonstrates how to create a custom AD DS partition. The main steps in the
process are:

1. Create AD DS environment. Create a single-domain AD DS forest containing two domain

controllers.
2. Create a custom AD DS partition. Use command-line tools to create a custom
application partition.
3. Verify that a custom AD DS partition exists. Use command-line tools to verify existence
of a custom application partition.
4. Delete a custom AD DS partition. Use command-line tools to delete a custom
application partition.

Using the knowledge acquired in this module, you created trust relationships between the Contoso’s AD DS
existing forests, implemented the ESAE forest, and created a custom AD DS partition to facilitate deployment
of a new in-house developed suite of applications. Throughout these changes, you ensured that the AD DS
replication remained fully operational.

Implement and manage Active Directory

Certificate Services
Learn about the Active Directory Certificate Services (AD CS) concepts and administration tasks,
including types of certification authorities (CAs), the process of issuing and revoking certificates, and
establishing certificate trusts.

Learning objectives
After completing this module, you'll be able to:
• Identify the purpose of Public Key Infrastructure (PKI) and components of AD CS.
• Identify types of AD CS certification authorities and the process of implementing them.
• Manage certificate enrollment.
• Manage certificate revocation.
• Manage certificate trusts.
Introduction
Learn about the Active Directory Certificate Services (AD CS) concepts and administration tasks,
including types of certification authorities (CAs), the process of issuing and revoking certificates, and
establishing certificate trusts.

Scenario
Contoso, Ltd. is a financial services company in Seattle with major offices located throughout the
world. Most of its compute environment runs on-premises on Windows Server. This includes
virtualized workloads on Windows Server 2016 hosts.

Contoso IT staff are migrating Contoso on-premises servers to Windows Server 2019. As part of the
migration, Contoso plans to expand into additional sites and use virtualization to help expedite
bringing a new site online. The company is also generating larger volumes of data with plans for
even more data in the future. Because of this, the company needs flexible storage options. Finally,
Contoso plans to increase the use of virtualization to optimize their computing environment because
many physical servers are underutilized.

As part of its technology modernization initiative, Contoso plans to implement its internal public key
infrastructure (PKI) by deploying AD CS. As a new Windows Server administrator, you are responsible
for designing the certification authority hierarchy, implementing it, and managing the process of
issuing and revoking certificates. You also need to ensure that appropriate certificate trusts are in
place.

Learning objectives
After completing this module, you'll be able to:

• Identify the purpose of PKI and components of AD CS.

• Identify types of AD CS certification authorities and the process of implementing them.
• Manage certificate enrollment.
• Manage certificate revocation.
• Manage certificate trusts.

Explore the fundamentals of PKI and AD CS

To obtain certificates for your AD DS infrastructure, you can request them from a public CA or issue
them by using your own infrastructure. To implement your own CA, you can use AD CS, which is the
path that Contoso chose to take. AD CS is an identity technology in Windows Server that allows you
to implement PKI for your organization.

What is PKI?
PKI is the combination of software, encryption technologies, processes, and services that enables an
organization to secure its data, communications, and business transactions. PKI relies on the
exchange of digital certificates between authenticated users and trusted resources. You use
certificates to secure data and to manage identification credentials from users and computers both
within and outside of your organization.

What is AD CS?
You can implement a PKI solution by using the AD CS Windows Server role. AD CS provides all PKI-
related components as role services. Each role service is responsible for a specific portion of the
certificate infrastructure while working together to form a complete solution.

The AD CS role includes the following role services:

• Certification Authority. The main purposes of CAs are to issue certificates, to revoke
certificates, and to publish authority information access (AIA) and revocation
information. The first CA you deploy becomes the root of your internal PKI.
Subsequently, you can deploy subordinate CAs, positioned within the PKI hierarchy, with
the root CA at its top. Subordinate CAs implicitly trust the root CA and, by implication,
certificates it issues.

Note

You have the option of deploying multiple internal CA hierarchies, each with its own
root.

• Certification Authority Web Enrollment. This component provides a method to issue and
renew certificates in scenarios where users use devices that are not joined to the domain
or are running operating systems other than Windows.
• Online Responder. You can use this component to configure and manage Online
Certificate Status Protocol (OCSP) validation and revocation checking. An Online
Responder decodes revocation status requests for specific certificates, evaluates the
status of those certificates, and returns a signed response that has the requested
certificate status information.
• Network Device Enrollment Service (NDES). With this component, routers, switches, and
other network devices can obtain certificates from AD CS.
• Certificate Enrollment Web Service (CES). This component works as a proxy client
between a computer running Windows and the CA. CES enables users, computers, or
applications to connect to a CA by using web services to:
o Request, renew, and install issued certificates.
o Retrieve certificate revocation lists (CRLs).
o Download a root certificate.
o Enroll over the internet or across forests.
o Renew certificates automatically for computers that are part of untrusted AD
DS domains or are not joined to a domain.
• Certificate Enrollment Policy Web Service. This component enables users to obtain
certificate enrollment policy information. Combined with CES, it enables policy-based
 certificate enrollment in scenarios where user devices are not joined to the domain or
can't connect to a domain controller.

Design and implement AD CS

It is critical to ensure that you design your internal CA in the optimal manner. Your design will have
significant implications to security and operational aspects of your PKI environment.

Designing AD CS-based hierarchy

Before implementing AD CS, you first should design your CA hierarchy. As part of your design, you
should decide how many CA tiers you need and what will be the purpose of the CA in each tier. We
don't recommend building a CA hierarchy deeper than three levels, unless it is in a complex, highly
secure, or distributed environment. Most commonly, CA hierarchies have two levels, with the root
CA at the top level and a subordinate, issuing CA on the second level. Usually, you use the root CA
to build the CA hierarchy. In such case, the root CA remains offline while you rely on the subordinate
CA to issue and manage certificates.

Note

A multilevel CA hierarchy isn't mandatory. For smaller, less complex environments, you can
implement a root CA only. In such case, the root CA also provides certificate issuance and
management functionality.

Some more complex CA designs include:

• CA hierarchies with a policy CA. Policy CAs are subordinate CAs that reside directly under
the root CA and above other, subordinate CAs in a CA hierarchy. You use policy CAs to
issue CA certificates to their subordinate CAs. The CA certificates reflect the policies and
procedures that an organization implements to secure its PKI, the processes that
validate the identity of certificate holders, and the processes that enforce the procedures
that manage certificates. A policy CA issues certificates only to other CAs. The CAs that
receive these certificates must uphold and enforce the policies that the policy CA
defined. Using policy CAs isn't mandatory unless different divisions, sectors, or locations
of your organization require different issuance policies and procedures. For example, an
organization can implement one policy CA for all certificates that it issues internally to
employees and another policy CA for all certificates that it issues to contractors.
• CA hierarchies with cross-certification trust. In this scenario, two independent CA
hierarchies interoperate when a CA in one hierarchy issues a cross-certified CA
certificate to a CA in another hierarchy. When you do this, you establish mutual trust
between different CA hierarchies.
Standalone vs. enterprise CAs
When using AD CS, you can deploy two types of CAs: standalone and enterprise. These types of CAs
are not about hierarchy, but instead, about functionality and integration with AD DS. A standalone
CA doesn't depend on AD DS. An enterprise CA requires AD DS, to provide additional functionality,
such as autoenrollment. Autoenrollment allows domain users and domain-joined devices to enroll
automatically for certificates after you enable automatic certificate enrollment through Group Policy.

The following table details the most significant differences between standalone and enterprise CAs.
An enterprise root CA is the most common choice when deploying a single CA in an AD DS
environment. If you deploy a two-tier hierarchy with a subordinate CA in an AD DS environment,
then you should consider a using standalone root CA as the root CA. This allows you to take it offline
without impacting the process of managing certificates for domain users and domain-joined devices.

Another consideration is the operating system installation type. Both the Desktop Experience and
the Server Core installation scenarios support AD CS. Server Core minimizes potential malicious
hacker surface and the operating system maintenance overhead, which makes it the optimal choice
for AD CS in an enterprise environment.

Additionally, you should keep in mind that you can't change computer names, domain name, or
computer domain memberships after you deploy a CA of any type on that computer. Therefore, it is
important to configure these settings before the deployment.

There are also some considerations specific to deployment of an offline, standalone root CA:

• Before you issue a subordinate certificate from the root CA, make sure that you provide
at least one certificate revocation list distribution point (CDP) and AIA location that will
be available to all clients. This is because, by default, a standalone root CA has the CDP
and AIA located on itself. Therefore, when you take the root CA off the network, a
revocation check will fail because the CDP and AIA locations will be inaccessible. When
you define these locations, you should manually copy CRL and AIA information to that
location.
• Set a validity period for CRLs that the root CA publishes to a long period of time, for
example, one year. This means that you'll have to turn on the root CA once per year to
publish a new CRL, and then you'll have to copy it to a location that is available to clients.
If you fail to do so, after the CRL on the root CA expires, revocation checks for all
certificates will also fail.
• Use Group Policy to publish the root CA certificate to a trusted root CA store on all
server and client computers. You must do this manually because a standalone CA can't
 do it automatically, unlike an enterprise CA. You can also publish the root CA certificate
to AD DS by using the certutil command-line tool.

Demonstration
The following video demonstrates how to:

• Configure prerequisites for an enterprise root CA.

• Deploy an enterprise root CA.

The main steps in the process are:

1. Create an AD DS environment. Create a single-domain AD DS forest.

2. Configure prerequisites for an enterprise root CA. Install the required server role and
server role services.
3. Deploy an enterprise root CA. Configure Enterprise Root CA settings.

Manage certificate enrolment

The purpose of CA is to allow users and devices to enroll for and use certificates. This, however, just
as with CA implementation, requires careful planning and preparation that determines the type of
certificates that a CA can issue.

What is a certificate?
A certificate is a small file that contains several pieces of information about its owner. This data can
include the owner's email address, the owner's name, the certificate usage type, the validity period,
and the URLs for AIA and CDP locations.

A certificate also contains the key pair, which consists of a private key and the corresponding public
key. You can use these keys in processes of validating identities, digital signatures, and encryption.
The key pair that each certificate generates has the following conditions:

• When content is encrypted with the public key, it can be decrypted only with the private key.
• When content is encrypted with the private key, it can be decrypted only with the public key.
• No other key is involved in the relationship between the keys from a single key pair.
• The private key can't be derived in a reasonable amount of time from a public key, and vice
versa.

As part of the certificate enrollment process, the client generates the public/private key pair. The
client then sends the public key to CA, which confirms client information, signs it with its own private
key, and then sends the certificate, which includes the client public key, back to the client.

Note

You can think of a certificate as being like a driver's license. Many businesses accept a driver's license
as a form of identification because they consider the license issuer (a government institution) as
trustworthy. Because businesses understand the process by which someone can obtain a driver's
license, they trust that the issuer verified the identity of the individual before issuing the license.
Therefore, the driver's license is acceptable as a valid form of identification. A certificate trust is
established in a similar way.

What are certificate templates?

Certificate templates define how users and devices can request and use Enterprise CA issued
certificates based on that template. For example, you can create a template that will provide file
encryption or email signing functionality. CA relies on AD DS to store the templates you configure.

Important

Certificate templates are available only when using Enterprise CA. This means that with a Standalone
CA, every certificate request must be created manually and include all required information to be
included in the certificate.

CA provides templates for users and for computers. You can assign permissions to certificate
templates to define who can manage them, who can perform enrollment or autoenrollment, and
what is their validity and renewal periods. You can apply additional modifications by duplicating pre-
defined certificate templates. To make templates available to users and devices, you must explicitly
allow their usage.
Template versions

The CA in Windows Server 2019 AD CS supports four versions of certificate templates, with the
following functional differences:

• Version 1 templates. These templates allow you to modify certificate related permissions only.
When you install a CA, version 1 certificate templates are created by default.
• Version 2 templates. With these templates, you can customize additional settings, such as
validity and renewal periods. This is also the minimum version that supports autoenrollment.
The default installation of AD CS provides several preconfigured version 2 templates. You can
create version 2 templates or duplicate a version 1 certificate template to create a new version
2 template.
• Version 3 templates. Version 3 certificate templates support Cryptography Next Generation
(CNG). CNG supports advanced cryptographic algorithms. You can duplicate default version 1
and version 2 templates to upgrade them to version 3. When you use the version 3 certificate
templates, you can use CNG encryption and hash algorithms for certificate requests, issued
certificates, and protection of private keys for key exchange and key archival scenarios.
• Version 4 templates. Version 4 certificate templates support both cryptographic service
providers (CSPs) and key storage providers. You can also configure them to require renewal with
the same key.

Demonstration
The following video demonstrates how to:

• Create a new template based on the Web Server template.

• Configure templates so that they can be issued.

The main steps in the process are:

1. Create an AD DS environment. Create a single-domain AD DS forest.

2. Deploy an Enterprise Root CA.
3. Create a custom certificate template. Use the Certificate Templates console to duplicate the Web
Server template.
4. Configure the template so that it can be issued. Use the Certification Authority console, to make
the template available for use.

Manage certificate revocation

As part of managing a certificate lifecycle, you not only need to control their issuance but also keep
track of their usage, and, whenever necessary, enforce their revocation. This is critical to mitigate
and remediate potential compromise of certificate-based security.

What is certificate revocation?

Revocation is the process in which you disable the validity of one or more certificates. By initiating
the revocation process, you publish a certificate thumbprint in the corresponding CRL. This indicates
that a specific certificate is no longer valid.
Important

Every certificate has its own validity period, after which it is no longer considered valid. With
revocation, you can invalidate the certificate before that period passes, for example, to remediate
certificate compromise.

The revocation process consists typically of the following sequence of steps:

1. Revoke a certificate and provide the reason and the target date and time. You can
perform this task from the CA console.
2. Publish a CRL. You have the option to trigger publishing from the CA console or
schedule automatic publishing in regular intervals. You can publish CRLs in AD DS, in a
shared folder, or on a website.
3. If an operating systems, applications, or service initiates a secure action that involves
the use of a certificate, that triggers an automatic check of the revocation status of that
certificate by querying the issuing CA and the corresponding CDP location. This process
determines whether the certificate is revoked.
Important

The support for the automatic check of a certificate revocation status is dependent on the way an
operating system, application, or service was implemented. Most modern commercial software
supports this functionality.

Windows operating systems include CryptoAPI, which is responsible for the certificate revocation
and status-checking processes. CryptoAPI uses the following phases in the certificate-checking
process:
 • Certificate discovery. Certificate discovery collects CA certificates, AIA information in
issued certificates, and details of the certificate enrollment process.
• Path validation. Path validation is the process of verifying the certificate through the CA
chain, or path, until the root CA certificate is reached.
• Revocation checking. Each certificate in the certificate chain is verified to ensure that
none of the certificates are revoked.
• Network retrieval and caching. Network retrieval is performed by using OCSP. CryptoAPI
is responsible for checking the local cache first for revocation information, and if there
is no match, making a call by using OCSP, which is based on the URL that the issued
certificate provides.

What is an Online Responder service?

An Online Responder service offers a more efficient way to check certificate revocation status. The
Online Responder service relies on OCSP to determine the revocation status of a certificate. OCSP
submits certificate status requests by using HTTP.

Clients access CRLs to determine the revocation status of a certificate. CRLs might be large, and
clients might use a significant amount of time to search through these CRLs. An Online Responder
service can search these CRLs dynamically for the clients and respond to the client with the status of
the requested certificate. You can use a single Online Responder to determine revocation status
information for certificates that are issued by a single CA or by multiple CAs. You also can implement
multiple Online Responders to distribute CA revocation requests.

You must configure the CAs to include the URL of the Online Responder in the AIA extension of
issued certificates. The OCSP client uses this URL to validate the certificate status. You also must
issue the OCSP Response Signing certificate template, so Online Responders can enroll that
certificate.

Demonstration
The following video demonstrates how to:

• Configure CRL publishing.

• Configure CDP location.

The main steps in the process are:

1. Create an AD DS environment. Create a single-domain AD DS forest.

2. Deploy an Enterprise Root CA.
3. Configure CRL publishing. Use the Certification Authority console to configure CRL
publishing.
4. Configure CDP location. Use the Certification Authority console to configure CDP
location.

Manage certificate trusts

Certificates play a crucial role in protecting and validating authentication and other security-related
tasks. One of the core principles that enable these capabilities is a certificate trust. For a certificate
to be effective, every user, device, or application using it must trust the CA that issued it.

What is certificate trust?

When using certificates, it is important that you consider who or what might need to assess their
authenticity and validity. There are three types of certificates that you can use:

• Internal certificates from an organizational CA, such as a server hosting the AD CS role.
• External certificates from a public CA such as an organization that provides commercial
cybersecurity software or identity services.
• A self-signed certificate.

If you deploy an Enterprise Root CA and use it to enroll certificates onto your users' domain-joined
devices, these devices will accept the enrolled certificates as trusted. However, any workgroup device
will consider the same certificates as untrusted. To resolve this issue, you can:

• Obtain public certificates from an external CA for the workgroup devices. This comes
with an extra cost of public certificates.
• Configure the workgroup devices to trust the Enterprise Root CA. This requires
additional configuration.

Manage certificates and certificate trusts in Windows

You can manage certificates that are stored within the Windows operating system by using a range
of tools, including Windows Admin Center, the Certificates Microsoft Management Console snap-in,
Windows PowerShell, and certutil command line tool. Each of them gives you access to certificate
stores of the current user, the local computer, and its services. Each store consists of several folders,
including:
To ensure that workgroup devices trust your Enterprise Root CA, export its certificate from the
Trusted Root Certification Authorities folder on a domain-joined computer and import it into the
same folder on these devices.

Note

Alternatively, you can obtain the certificate of the Enterprise Root CA from the CertEnroll share on
the server hosting that role.

Create a self-signed certificate for testing purposes

While self-signed certificates are not suitable for production scenarios, they can be useful for testing
purposes. You can use the Windows PowerShell New-SelfSignedCertificate cmdlet to create a self-
signed certificate. If you include the CloneCert parameter and provide an existing certificate, the new
one will have the matching settings with exception of the public key. Instead, the cmdlet will create
a new key of the same algorithm and length.

The following example creates a self-signed SSL server certificate in the local machine personal store
with the subject alternative name set to www.fabrikam.com, www.contoso.com and Subject and
Issuer name set to www.fabrikam.com.

PowerShell
New-SelfSignedCertificate -DnsName "www.fabrikam.com", "www.contoso.com" -CertStoreLocation
"cert:\LocalMachine\My"

Using the knowledge acquired in this module, you implemented Contoso’s internal PKI by deploying
AD CS. You designed the certification authority hierarchy, deployed it, and operationalized the
process of issuing and revoking certificates, including ensuring that appropriate certificate trusts are
in place.