FSMO roles in Active Directory: What they are and how they work

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.

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.

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

Have you implemented FSMO roles in your organization? Please share your thoughts with us.

Photo credit: Wikimedia