Active Directory (AD) is a directory service created by Microsoft, and

it comes as a set of processes and services in most versions of Windows

Server operating systems.
You can imagine AD as a database or a safe location that stores all the
attributes of your users such as usernames, passwords, and more. This
central repository automates many tasks such as management of user data,
provision of security, and inter-operations with other directories.
In the initial versions of AD, there were many chances for conflicts. For
example, let’s say, a domain controller added a new employee to the
database. Since the change was made to the AD, it was reflected
throughout the enterprise, and that’s fine. A few seconds later, another
domain controller wanted to delete the records of employees who no
longer worked in the enterprise. Accidentally, it deleted this employee
from the AD as well.
The conflict management system that existed then followed the “last writer
wins” policy, so the change made by the second domain controller was
valid while the change made by the first domain controller was discarded.
This means, the new employee was no longer in the system and couldn’t
access the system’s resources, which is obviously not right.
To prevent such conflicts, a single-master model was introduced. In this
model, only one domain controller (DC) could perform a particular type of
update. In the above case, if only the first DC was in charge of adding and
removing employees and the second DC was in charge of security, then
such a conflict wouldn’t have occurred.
However, this came with limitations too. What happens when the first DC
goes down? You can’t add or delete employees until it comes back up
again. Such heavy dependence on a single controller is never good from an
operational standpoint.
So, Microsoft went a little further in subsequent versions to include
multiple roles for each DC and to give each DC the ability to transfer the
entire role to any other DC within the same enterprise. The obvious
advantage here is no role is bound to any particular DC, so when one goes
down, you can automatically transfer this role to another working DC.
Since such a model offers a lot of flexibility, it’s called the Flexible Single
Master Operation (FSMO).
Effectively, FSMO is a multimaster model that assigns clear roles and
responsibilities to every DC and at the same time, giving the flexibility to
transfer roles if needed.
FSMO roles
FSMO is broadly divided into five roles and they are:
 Schema master
 Domain naming master
 RID master
 PDC emulator
 Infrastructure master
Out of these, the first two FSMO roles are available at the forest level
while the remaining three are necessary for every domain.

Remote Extensions

Let’s now look at each FSMO role in depth.

Schema master

Schema master, as the name suggests, holds a read-write copy of your

AD’s entire schema. If you’re wondering what a schema is, it’s all the
attributes associated with a user object and includes password, role,
designation, and employee ID, to name a few.
So, if you want to change the employee ID, you’ll have to do it in this DC.
By default, the first controller you install in your forest will be the schema
master.

naming master

Domain naming master is responsible for verifying domains, so there’s

only one for every forest. This means if you’re creating a brand new
domain in an existing forest, this controller ensures that such a domain
doesn’t already exist. If your domain naming master is down for any
reason, you can’t create a new domain.
Since you don’t create domains often, some enterprises prefer to have
schema master and domain naming master within the same controller.

RID master

Every time you create a security principle, be it a user account, group

account, or a master account, you want to add access permissions to it. But
you can’t do it based on the name of a user or group because that can
change at any time.
Let’s say you had Andy with a particular role, and he left the company. So,
you closed Andy’s account and instead brought in Tim. Now, you’ll have
to go and replace Andy with Tim in the security access lists of every
resource.
This is not practical, as it’s time-consuming and error prone.
This is why you associate every security principle with something called a
security ID or SID. This way, even if Andy changes to Tim, the SID will
remain the same, so you’ll have to make just one change.
This SID has a specific pattern to ensure that every SID in the system is
unique. It always starts with the letter “S” followed by the version (starts
with 1) and an identifier authority value. This is followed by the domain or
local computer name that’s common for all SIDs located within the same
domain. Lastly, the domain name is followed by what’s called a relative
ID or RID.
Essentially, RID is the value that ensures uniqueness between different
objects in the active directory.
A SID will look like this: S-1-5-32365098609486930-1029. Here 1029 is
the RID that makes a SID unique while the long series of numbers is your
domain name.
But this can lead to conflicts, too. Let’s say we create two user accounts at
the same time. This can cause conflict as there’s a possibility for both
these objects to have the same SID.
To avoid this conflict, the RID master assigns blocks of 500 to each
domain controller. This way, DC1 gets RIDs from 1 to 500, DC2 gets
RIDs from 501 to 1,000, and so on. When a domain controller runs out of
RIDs, it contacts the RID master and in turn, this RID master assigns
another block of 500.

So, RID master is responsible for processing RID pool requests from DCs
within a single domain to ensure that every SID is unique.
PDC emulator

PDC stands for Primary Domain Controller and it comes from a time when
there was only one domain controller that had a read-write copy of the
schema. The remaining domain controllers were a backup for this PDC.
So, if you wanted to change a password, you’d have to go to the PDC.
Today, there are no more PDCs. But a few of its roles like time
synchronization and password management are taken over by a domain
controller called PDC emulator.
Let’s look at its password management first.
Let’s say I go to one domain controller and reset my password because it’s
expired. Then I log on to another machine for a different site and, let’s say,
it contacts a different domain controller for authentication. There’s a
chance that my login will fail because the first domain controller may not
have replicated my password change to other controllers.
A PDC emulator avoids these confusions by being the controller for
password resets. So, my client will contact the PDC emulator when a login
fails, to check if there was a password change. Also, all account lockouts
due to wrong passwords are processed on this PDC emulator.
Other than password management, PDC emulator syncs the time in an
enterprise system. This is an important functionality because AD
authentication uses a protocol called kerberos for security. This protocol’s
main task is to ensure that data packets are not taken off the network or
tampered while it’s getting transmitted.
So, when there is a difference of five minutes or more between a server
clock and your system during the authentication process, kerberos thinks
this is an attack and will not authenticate you.
Fine, but what’s the role of a PDC emulator here?
Well, your local system syncs its time with the domain controller, and the
domain controller, in turn, syncs its time with the PDC emulator. This
way, the PDC emulator is the master clock for all the domain controllers in
your domain.
When this controller is down, your security goes down a few notches and
makes passwords vulnerable to attacks.

Infrastructure master

The core functionality of an infrastructure master is to reference all local

users and references within a domain. This controller understands the
overall infrastructure of the domain including what objects are present it.
It is responsible for updating object references locally and also ensures that
it is up to date in the copies of other domains. It handles this update
process through a unique identifier, possibly a SID.
Infrastructure master is similar to another AD tool called Global Catalog
(GC). This GC is like an index that knows where everything is, inside an
active directory. The infrastructure master, on the other hand, is a smaller
version of GC, as it is restricted within a single domain.
Now, why is it important to know about GC here? Because GC and
infrastructure master should not be placed in the same domain controller.
If you happen to do that, the infrastructure master will stop working as the
GC gets precedence.
In general, if you have only one domain controller, this won’t matter so
much. But, if you have a large forest with multiple domain controllers, the
presence of both GC and infrastructure master will cause problems.
Let’s take a situation here. We have multiple domains that look up to a GC
server. Inside one domain, we make a change to the group membership
and the infrastructure master knows about this change. But it doesn’t
update the GC server because the change was not made to a universal
group. This means, there’s a chance for your GC and infrastructure master
to be out of sync, and in turn, this can cause authentication issues. That’s
why make sure you have either an infrastructure master or a GC for every
domain, but not both.

Summary
As you can see. FSMO roles prevent conflicts in an active directory and, at
the same time, give you the flexibility to handle different operations within
the active directory. They can be broadly divided into five roles, out of
which, the first two are for the entire forest while the remaining three
pertain to a particular domain.