1 70- 742 Identity with Windows Server 2016

Lesson 2
Overview of AD DS domain controllers
Because domain controllers authenticate all users and computers in the domain, domain controller deployment is critical
for the network to function correctly.
This lesson examines domain controllers, the sign-in process, and the importance of DNS in that process. In addition, this
lesson discusses the purpose of the global catalog.
All domain controllers are essentially the same, with two exceptions. RODCs contain a read-only copy of the AD DS
database, whereas other domain controllers have a read/write copy. Also, certain operations can be performed only on
specific domain controllers called operations masters, which are discussed at the end of this lesson.
Lesson Objectives
After completing this lesson, you will be able to:
• Describe the purpose of domain controllers.
• Understand what is contained in the SYSVOL folder.
• Describe the purpose of the global catalog.
• Describe the AD DS sign-in process and the importance of DNS and service records (SRV records) in that process.
• Explain the functions of operations masters.
• Describe operations master role transfer and seizing.
What is a domain controller?
A domain controller is a server that is configured to store a copy of the AD DS
directory database (Ntds.dit) and a copy of the SYSVOL folder. All domain
controllers except RODCs store a read/write copy of both Ntds.dit and the SYSVOL
folder. Ntds.dit is the database itself, and the SYSVOL folder contains all the
template settings and files for GPOs.
Domain controllers use a multimaster replication process to copy data from one
domain controller to another. This means that for most operations, data can be
modified on any domain controller, except for an RODC. The AD DS replication
service then synchronizes the changes that have been made to the AD DS database
with all the other domain controllers in the domain. In Windows Server 2016, you
can use only Distributed File System (DFS) replication to replicate the SYSVOL folders. Earlier versions of Windows
Server used the file replication service (FRS) to replicate the folders, but FRS is obsolete for several versions of Windows.
Domain controllers host several other services related to AD DS, including the Kerberos authentication service, which user
and computer accounts use for sign-in authentication. and the Key Distribution Center (KDC), which issues the ticket-
granting ticket (TGT) to an account that signs in to the AD DS domain. Optionally, you can configure domain controllers
to host a copy of the global catalog.
All the users in an AD DS domain exist in the AD DS database. If the database is unavailable for any reason, all operations
that depend on domain-based authentication will fail. As a best practice, an AD DS domain should have at least two domain
controllers. This makes the AD DS database more available and spreads the authentication load during peak sign-in times.
Note: Consider two domain controllers as the absolute minimum for most enterprises, to ensure high availability and
performance. When you deploy a domain controller in a branch office where physical security is less than optimal, you can
use additional measures to reduce the impact of a breach of security. One option is to deploy an RODC.
The RODC contains a read-only copy of the AD DS database, and by default, it does not cache any user passwords. 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 is much lower than with a full read/write domain controller. Another option is to use BitLocker Drive
Encryption to encrypt the domain controller’s hard drive. If the hard drive is stolen, BitLocker will help to ensure that a
malicious hacker has difficulty getting any useful information from it.
Note: BitLocker is a drive encryption feature that is available for Windows Server operating systems and certain
Windows client operating systems. BitLocker encrypts the entire drive to help prevent the computer from starting unless it
receives a private key and (optionally) passes an integrity check. A hard drive remains encrypted even if you transfer it to
another computer.

Trainer: Muhammad Muazzam M1 - Lesson 2 Overview of AD DS domain controllers

 2 70- 742 Identity with Windows Server 2016

What is a global catalog?

A global catalog is a partial, read-only, searchable copy of all the objects in the
forest. It speeds 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 is replicated
on the global catalog servers in other domains in the forest.
Within a particular domain, a query for an object is directed to one of the domain
controllers in that domain, but that query does not include results about objects
in other domains in the forest. For a query to include results from other domains
in the forest, you must query a domain controller that is a global catalog server.
By default, the first domain controller in the forest root domain is the only hosted global catalog server. To enhance
searching across domains in a forest, you should configure additional domain controllers to each store a copy of the global
catalog.
The global catalog does not contain all the attributes for each object. Instead, the global catalog maintains the subset of
attributes that are most likely to be useful in cross-domain searches. These attributes include givenName, displayName, and
mail. You can modify the set of attributes replicated to the global catalog by modifying the partial attribute set (PAS) in the
schema.
For various reasons, you might perform a search against a global catalog rather than a domain controller that is not a global
catalog. For example, when a server that is running Exchange Server receives an incoming email, it needs to search for the
recipient’s account so that it can decide how to route the message. By automatically querying a global catalog, the server
that is running Exchange Server can locate the recipient in a multiple domain environment.
For another example, when users sign in to their Active Directory account, the domain controller that performs the
authentication must contact a global catalog to check for universal group memberships before the user is authenticated. In
a single domain, you should configure all the domain controllers to hold a copy of the global catalog. However, in a multiple-
domain environment, the infrastructure master should not be a global catalog server unless all the domain controllers in the
domain are also global catalog servers. When you have multiple sites, you should also make at least one DC at each site a
global catalog server, so that you are not dependent on other sites when global catalog queries are required. Deciding which
domain controllers should be configured to hold a copy of the global catalog depends on replication traffic and network
bandwidth. Many organizations opt to make every domain controller a global catalog server.
Overview of domain controller SRV records
When users sign in to AD DS, their computer looks in DNS for SRV records to locate
the nearest domain controller. SRV records specify information about available services.
Each domain controller dynamically registers its addresses in DNS at startup by
registering an updated SRV record in DNS.
Clients can locate a suitable domain controller to service their sign-in requests by using
DNS lookups which use these SRV records.
SRV records for AD DS are created in the following pattern.
_Service._Protocol.DomainName
For example, if a client is looking for a server that is running the Lightweight Directory Access Protocol (LDAP) service
in the Adatum.com domain, it queries for _ldap._tcp.Adatum.com.
Sites and SRV records
A client uses sites when it needs to contact a domain controller. It starts by looking up SRV records in DNS. The response
to the DNS query includes:
▪ A list of the domain controllers in the same site as the client.
▪ A list of the domain controllers from the next closest site that does not include an RODC, if no domain controllers were
available in the same site and the Try Next Closest Site Group Policy setting is enabled.
▪ A random list of available domain controllers in the domain, if no domain controller was found in the next closest site.
Administrators can define sites in AD DS. When you define sites, you should consider which parts of the network have
good connectivity and bandwidth. For example, if a branch office is connected to the main datacenter by an unreliable wide
area network (WAN) link, you should define the branch office and the datacenter as separate sites.
The Net Logon service that runs on each domain controller registers the SRV records in DNS. If the SRV records are not
entered in DNS correctly, you can trigger the domain controller to reregister those records by restarting the Net Logon
service on that domain controller. Note that this process reregisters only the SRV records. If you want to reregister the host
(A) record information in DNS, you must run ipconfig /registerdns from a command prompt, just as you would for any
other computer.

Trainer: Muhammad Muazzam M1 - Lesson 2 Overview of AD DS domain controllers

 3 70- 742 Identity with Windows Server 2016

Demonstration: Viewing the SRV records in DNS

This demonstration shows you how to display the various types of SRV records that the domain controllers register in DNS.
These records are crucial to how AD DS operates because they are used to find domain controllers for signing in, changing
passwords, and editing GPOs. Domain controllers also use SRV records to find replication partners.
Demonstration Steps
View the SRV records by using DNS Manager
1. On LON-DC1, sign in with the user name Adatum\Administrator and the password Pa$$w0rd.
2. Open the DNS Manager window, and then explore the DNS domains that begin with an underscore (_).
3. View the SRV records that are registered by domain controllers.
Note: These records provide alternate paths so that clients can discover them.
AD DS sign-in process
When a user attempts to sign in to a computer, the computer first searches for a domain
controller to authenticate the user by using DNS lookup. The computer then sends the user’s
name and password to the domain controller for authentication. The local security authority
(LSA) on the domain controller handles the actual authentication process. If the sign-in
succeeds, the LSA builds an access token for the user that contains the security IDs (SIDs)
for the user and any groups in which the user is a member. The token provides the access
credentials for any process initiated by that user. For example, say that after signing in to
AD DS, a user runs Microsoft Word and attempts to open a file. Word then uses the
credentials in the user’s access token to verify the level of the user’s permissions for that
file.
Note: A SID is a unique string in the form S-R-X-Y1-Y2-Yn-1-Yn. For example, a user SID can be S-1-5-21-322346712-
1256085132-1900709958-500.
The following table explains the parts of this SID .

Component Definition In the example

S Indicates that the string is an SID S
R Revision level 1
X Identifier authority value 5 (NT Authority)
Y1-Y2-Yn-1 Domain identifier 21-322346712-1256085132-1900709958
Yn relative ID (RID) 500

Every user and computer account and every group that you create has a unique SID. They differ from each other only by
virtue of the unique RID. The SID in the example is a well-known SID for the domain administrator account. Default
accounts and groups use well-known SIDs. The Domain Administrator account’s SID always ends with 500. Although the
sign-in process appears to the user as a single event, it is actually made up of two parts:
• The user provides credentials, usually a user account name and password, which are checked against the AD DS
database. If the user account name and password match the information that is stored in the AD DS database, the
user becomes an authenticated user and is issued a TGT by the domain controller. At this point, the user does not
have access to any resources on the network.
• A secondary process in the background submits the TGT to the domain controller and requests access to the local
computer. The domain controller issues a service ticket to the user, who then can interact with the local computer.
At this point in the process, the user is authenticated to AD DS and signed in to the local computer.
When a user subsequently attempts to connect to another computer on the network, the secondary process runs again, and
the TGT is submitted to the nearest domain controller. When the domain controller returns a service ticket, the user can
access the computer on the network, which generates a logon event at that computer.
Note: A domain-joined computer also signs in to AD DS when it starts—a fact that is often overlooked. You do not see
the transaction when the computer uses its computer account name and a password to sign in to AD DS. After it is
authenticated, the computer becomes a member of the Authenticated Users group. Although the computer logon event does
not have visual confirmation in a GUI, it is recorded in the event log. Also, if auditing is enabled, additional events are
recorded in the security log of Event Viewer.

Trainer: Muhammad Muazzam M1 - Lesson 2 Overview of AD DS domain controllers

 4 70- 742 Identity with Windows Server 2016

What are operations masters?

Certain operations can be performed only by a specific role, on a specific domain controller.
A domain controller that holds one of these roles is called an operations master. An operations
master role is also known as a flexible single master operations (FSMO) role. Five operations
master roles exist, and all five can be located on a single domain controller or they can be
spread across several domain controllers. By default, the first domain control installed in a
forest contains all five roles. However, these roles can be moved after more domain controllers
are built. By allowing changes only on a single domain controller, the operations master roles
help to prevent conflicts in AD DS caused by replication latency. When making changes to
data held on one of the operations masters, you must connect to the domain controller that holds the role.
The five operations master roles are distributed as follows:
• Each forest has one schema master and one domain naming master.
• Each AD DS domain has one RID master, one infrastructure master, and one primary domain controller (PDC)
emulator.
Forest operations masters
A forest contains the following single master roles:
▪ Domain naming master. This is the domain controller that must be contacted when you add or remove a domain or
make domain name changes.
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. To make changes, you typically
sign in to the schema master as a member of both the Schema Admins and the Enterprise Admins group. A user who
is a member of both of these groups and who has the appropriate permissions can also edit the schema by using a
script. If the schema master is unavailable, you will not be able to make changes to the schema. This prevents the
installation of applications that require schema changes, such as Exchange Server.
Note: The Windows PowerShell command Get-ADForest, from the Active Directory module for Windows PowerShell,
shows the forest properties, including the current domain naming master and schema master.
Domain operations masters
A domain contains the following single master roles:
▪ RID master. Whenever an object is created in AD DS, the domain controller where the object is created assigns the
object a unique identifying number known as a 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 the SID. If the RID master is unavailable, you might experience difficulties adding new objects to the
domain. 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
contains a member from another domain. In this situation, the infrastructure master is responsible for maintaining the
integrity of this reference. For example, when you look at the Security tab of an object, the system looks up the SIDs
that are listed and translates them into names. In a multiple-domain forest, the infrastructure master looks up SIDs
from other domains. If the infrastructure master is unavailable, domain controllers that are not global catalogs will not
be able to check universal group memberships or to authenticate users.
The infrastructure role should not reside on a global catalog server unless you have a single-domain forest. The
exception is when you follow best practices and make every domain controller a global catalog. In that case, the
infrastructure role is not required because every domain controller knows about every object in the forest.
▪ PDC emulator master. The domain controller that holds the PDC emulator master is the time source for the domain.
The PDC emulator masters in each domain in a forest synchronize 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.
The PDC emulator master is also the domain controller that receives urgent password changes. If a user’s password
is changed, the information is immediately sent to the domain controller holding the PDC emulator master role. This
means that if the user tries to sign in, even if the user had been authenticated by a domain controller in a different
location that had not yet received the new password information, the domain controller in the user’s current location
will contact the domain controller holding the PDC emulator master role to check for recent changes. If the PDC
emulator master is unavailable, users might have trouble signing in until their password changes have replicated to all
the domain controllers.
The PDC emulator master is also used for editing GPOs. When a GPO other than a local GPO is opened for editing,
the edited copy is stored on the PDC emulator master. This prevents conflicts if two administrators attempt to edit the
same GPO at the same time on different domain controllers. However, you can choose to use a specific domain
Trainer: Muhammad Muazzam M1 - Lesson 2 Overview of AD DS domain controllers
 5 70- 742 Identity with Windows Server 2016

controller to edit the GPOs. This is especially useful when editing GPOs in a remote office with a slow connection to
the PDC emulator.
Note: The Windows PowerShell command Get-ADDomain, from the Active Directory module for Windows
PowerShell, shows the domain properties, including the current RID master, infrastructure master, and PDC emulator
master.
Note: The global catalog is not one of the operations master roles.
Transferring and seizing roles
In an AD DS environment where FSMO roles are split among domain controllers, you
might need to move a role from one domain controller to another. When you plan this
role move—for example, to decommission servers or balance workloads—the move is
known as transferring the role. If you do not plan the move—for example, in the case of
a hardware or system failure—the move is known as seizing the role. For transferring a
role, the latest data from the domain controller in that role is replicated to the target
server. You should seize a role only as a last resort. For seizing a role, the original domain
controller is not available, so the available data might be incomplete or out of date.
Transferring FSMO roles
You can transfer FSMO roles through the GUI by using the AD DS snap-ins that are listed in the following table.
Role Snap-in
Schema master Active Directory
Domain naming master Schema Active Directory Domains and Trusts
Infrastructure master Active Directory Users and Computers
RID master Active Directory Users and Computers
PDC emulator Active Directory Users and Computers

Seizing FSMO roles

You cannot use the snap-ins to seize FSMO roles. Instead, you must use the ntdsutil.exe command-line tool or Windows
PowerShell to seize roles. You can also use these tools to transfer roles.
The syntax for transferring or seizing a role is similar within Windows PowerShell, as shown in the following syntax line.
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 transfer one or more roles to.
▪ <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 simply transfer it.
Question: Should a domain controller be a global catalog?
Question: Verify the correctness of the statement by placing a mark in the column to the right.

Statement Answer
In a multiple-domain forest, a copy of the global catalog should be
stored on every domain controller

Trainer: Muhammad Muazzam M1 - Lesson 2 Overview of AD DS domain controllers