Active Directory (AD) is a directory service that provides central authentication and authorization services. Organizations host AD on domain controllers (DCs) that replicate information between them in a multi-master configuration. Flexible Single Master Operation (FSMO) roles ensure consistent and reliable data across all data sources.
Not a reader? Watch this related video tutorial!FSMO roles help AD replication run smoothly and ensure so many other critical services operate as intended. In this article, you’ll learn what FSMO roles are, how they impact AD and how you can manipulate them safely in an AD forest.
By the end of this article, you’ll better understand FSMO roles and how to manage them for a healthy AD environment.
What are FSMO Roles?
FSMO roles are services each hosted independently on a DC in an AD forest. Each role has a specific purpose, such as keeping time in sync across devices, managing security identifiers (SIDs), and so on.
FSMO roles are scoped at either the forest or domain level and are unique to that scope, as shown below. For example, a forest with two domains will have one DCs in each domain (two total) hosting the RID Master role while only one DC hosting the Schema Master role.
| FSMO Role | Scope |
| Schema Master | Forest |
| Domain Naming Master | Forest |
| Primary Domain Controller Emulator | Domain |
| RID Master | Domain |
| Infrastructure Master | Domain |
A DC can hold multiple roles at one time.
Schema Master
A critical component of AD is the database. The database, like all other databases, has a schema that dictates its structure with various partitions or naming contexts. The AD schema is a database partition that contains metadata about AD objects. For example, it contains classes like person, group, or msPKI-Key-RecoveryAgent and attributes like phone number, badPwdCount, or dNS-HostName.
The AD schema is the most “delicate” partition in the Active Directory database.
AD needs a service to manage the schema thus the Schema Master role. The Schema Master role has the duty of controlling changes to the AD schema. If you’ve ever extended the AD schema to install products like Exchange or raising a forest functional level, you’ve worked with the Schema Master role.
You should perform any changes to the AD schema via the Schema Master role only under strict conditions on a single DC. You don’t want to make changes on two DCs and wait for replication to see which change “wins” via replication.
Domain Naming Master
An AD database contains multiple partitions both at the forest and domain scope. AD occasionally makes changes to these partitions and needs a service to do that thus the Domain Naming Master FSMO role.
When you make changes to the forest domain space (add partitions to the forest), the Domain Naming Master writes these changes in Configuration\\Partitions This activity happens when a domain controller is promoted or demoted, for example.
Primary Domain Controller Emulator (PDCe)
Arguably, the most essential FSMO role in AD is the PDCe. The PDCe role is responsible for tasks like password change synchronizations, account lockouts (and unlocks), time sync, and many more.
Back in the early days of Active Directory (Windows NT), the Primary Domain Controller (PDC) was the only writable DC in an AD domain. All other DCs were Backup Domain Controllers (BDCs) used only for authentication requests
Starting with Windows 2000, all DCs became writable excluding read-only domain controllers (RODCs), which were introduced in Windows Server 2008. Because AD still needed the functionality of the PDC but didn’t technically have a PDC anymore, Microsoft introduced the PDC emulator (PDCe) role.
Redirecting Legacy Applications
One of the PDCe role’s most basic features is to be available for legacy applications notifying them the DC it’s hosted is where AD can write changes to. For example, if you’re unlucky enough to still be working with a Windows NT service and that service doesn’t know where to write changes to the AD database, it will contact the PDCe for assistance.
Time Synchronization
It’s important for all devices joined to a domain to maintain a consistent time. Kerberos authentication (the default authentication mode) requires a maximum gap of five minutes between a client and a DC or between DC replication partners.
The PDCe role is the central time source for all other computers in an AD forest.
- All client computers synchronize time from the DC they log on to.
- All DCs synchronize time from the PDCe in their domain.
- In multi-domain AD forests, DCs hosting the PDCe role synchronize their time from the PDCe in the parent domain.
- The PDCe role in the root domain then uses a reliable external time source to sync from.
Managing Password Changes
When an AD change is made, that change does not replicate immediately to all DCs; it follows the AD replication schedule instead. However, password changes are replicated a bit differently. Password changes always first replicate from the originating DC to the DC holding the PDCe role and then off to the other DCs in the topology.
If, for example, a DC does not currently have the latest password and a user attempts to authenticate with the old password, the authenticating DC first contacts the DC holding the PDCe role to check for an updated password before denying authentication.
You’ll notice problems with the PDCe immediately when you discover users that have changed the password have issues connecting to other DCs that have not yet replicated the new password.
Processing Account Lockouts
The PDCe role also processes account lockouts. As opposed to password changes, account lockouts do not follow the regular replication intervals. Account lockouts are immediately replicated to the other DCs through a mechanism called replicate single object. This is a security measure to make sure that a locked-out account cannot log on to another DC that hasn’t replicated yet.
Default Target for the Group Policy Management Console (GPMC)
Managing Group Policy is done with the Group Policy Management Console (GPMC) tool. To make changes to AD, the GPMC needs to connect to a DC. By default, the GPMC will always connect to the DC holding the PDCe role even if it’s located in a different AD site. If the PDCe is not reachable, you’ll receive a warning stating the PDCe role is not reachable and the GPMC will prompt you to pick a different DC.
Related: What is Group Policy and How Does it Work (In Detail)
Serving Up Distributed File System (DFS) Namespace Information
To round out the PDCe FSMO role’s functionality, the PDCe role serves up DFS namespace information. Periodically, DFS root servers will request updated DFS namespace information from the PDCe which holds authoritative DFS information.
While normally not an excessive load for the PDCe FSMO role, you change the default DFS namespace lookup behavior in environments with a large number of DFS servers.
RID Master
Every object in an AD domain must have a unique ID to differentiate it from all other similar objects. It’s critical that AD always assign a unique ID to every new object called a security identifier or SID.
Each SID is composed of several components: S (for SID), the Revision number, I -the Identifier Authority-, the domain ID, and the relative ID. The domain ID is unique to each domain in a forest. The relative ID is unique to each object in a domain. A SID looks like below with an DomainId representing the domain ID and RelativeId representing the relative ID.
S-Revision-I-DomainId-Rid
Example: S-1-5-12-7273811915-2261004348-033256673-515
The string identifies this value as a SID. The string starts with an "S";
And has a revision level of 1;
An identifier authority value of 5 (NT Domain);
The domain identifier is a four-part value,
The RID has a value of 515. The value of the RID is fixed and will never be generated; it's hard-coded and won't be repeated. (In this example, this is the well-known SID for the Domain Computers security group).
The Relative ID (RID) Master role ensures the SID assigned to each AD object is unique.
Some RIDs are reserved for special accounts and well-known groups.
The first DC in the domain automatically becomes the RID Master, to keep RID issuance under control.
The DC holding the RID Master role comes into play primarily in three different events:
DC Promotion/Demotion
Each time a new DC is promoted, the RID Master assigns it a block of 500 RIDs. These RIDs are then assigned (in incremental order) when a new account that needs a SID is created on that DC.
For example, if the last block of RIDS assigned was from 5501 to …6000, the next DC that needs a block (either a newly-promoted DC or a DC that has depleted its current block) will receive …6001 to …6500 and so on.
When a DC is removed from the AD database, the RID Master sees this and ensures not to assign any of the RIDs that DC had as a safety measure to prevent duplicate SIDs.
RID Exhaustion
When a DC reaches 50% RID capacity, it will go to the RID Master and request a new block of RIDs. DCs request new RIDs at 50% on the off chance the RID Master is offline which gives it plenty of buffer time to ensure its RID allocation isn’t exhausted.
RID Master Role Seizure
Administrators can move roles from one DC to another via FSMO role seizure or transfer. When an administrator moves the RID Master role from one DC to another, its next available RID # is incremented by 10000.
Related: How to Transfer FSMO Roles (GUI and PowerShell)
Incrementing the next available RID by 10000 is a safety mechanism put in place to avoid duplicate SIDs. If an administrator seizes the RID Master role, for example, and the old RID Master comes back online, it may begin issuing duplicate SIDs along with the new RID Master.
Infrastructure Master
Every AD object has a SID assigned by the RID Master FSMO role. When you view users, groups and other AD information, we humans want to see a name and not a SID; this is where the Infrastructure Master role comes in.
By default, each DC is configured as a global catalog (GC). A GC hosts information from all domains in a forest. One way to reduce replication traffic between sites was to configure some DCs to not be GCs.
If you were authenticated to a DC that was not a GC, the Infrastructure Master was responsible for translating SIDs from other domains into human-friendly names.
For example, from a domain-joined computer, check the Security or Sharing tab of a folder in Windows Explorer with permissions set up for accounts in another domain. You’ll see the names of users, computers, and groups; not their SIDs. If your computer cannot find the Infrastructure Master role in the domain, you’ll only the SIDs of accounts in other domains.
If you enable Active Directory Recycle Bin, all DCs technically behave like they hold the Infrastructure Master role. The AD Recycle Bin renders the Infrastructure Master role in Microsoft’s words not important.
Related: How to Save Your Bacon with the Active Directory Recycle Bin
Conclusion
AD FSMO roles are a critical component to ensuring AD continues to function as designed. Although most of the time, you don’t need to be concerned about FSMO roles, it’s still important to understand how they function when the time comes!
