What Are FSMO Roles?
In a Microsoft Active Directory (AD) environment, any authoritative domain controller (DC) can create, modify and delete AD objects, since every domain controller (except for read-only DCs) holds a writable copy of its domain’s partition. Once changes are made, they are synchronized to other DCs through multi-master replication.
However, some pivotal operations are confined to certain DCs that have been assigned special roles known as Flexible Single Master Operations (FSMO) roles, or operation master roles. There are five unique FSMO roles. By default, when you create an Active Directory domain, all FSMO roles are assigned to the first domain controller in the forest. Domain admins can reassign FSMO roles to other domain controllers if needed.
Purpose of FSMO Roles
In a single-domain controller (DC) environment, AD management is straightforward, since the sole DC handles all object changes. But if there are multiple domain controllers, a potential tug-of-war emerges, as each DC could vie for the authority to make changes.
Initially, Microsoft solved this problem using a single master model in which one domain controller held the exclusive rights to make changes while the other DCs fulfilled authentication requests. However, this approach had a clear vulnerability: If the primary domain controller went down, no changes could be made to AD until it was back up.
To improve the resiliency of AD while maintaining the integrity of the directory, Microsoft introduced a more synchronized model in 2003 to prevent such conflicts. This model incorporated Flexible Single Master Operation roles that allocated certain responsibilities to different domain controllers so that if one DC goes down, another DC takes over the missing role.
What are the 5 FSMO Roles in Active Directory?
Active Directory has five FSMO roles:
- Relative ID (RID) Master (domain level)
- Primary Domain Controller (PDC) Emulator (domain level)
- Infrastructure Master (domain level)
- Domain Naming Master (forest level)
- Schema Master (forest level)
As you can see, the last two FSMO roles in the list operate forest-wide, which means that only one DC in the forest can be the role holder. In other words, in every Active Directory forest, there is a single Schema Master and a single Domain Naming Master.
The other three FSMO roles operate within the jurisdiction of a single domain. That is, in each domain, there is one Infrastructure Master, one RID Master and one PDC Emulator. In environments with multiple domains, each domain will host these three FSMO roles on one or more DCs.
A single DC can have multiple (or even all five) FSMO roles. The DC that is assigned a particular FSMO role is called the role owner.
RID Master
Relative Identifier Master (RID Master) is a domain-level role; there is one RID Master in each domain in an AD forest. It is responsible for allocating RID pools to the DCs in its domain in order to ensure that each security principal (such as a user or group) in the domain has a unique security identifier (SID).
A SID is a variable-length alphanumeric string that looks like this:
`S-1-5-21-1234567890-1234567890-1234567890-1001`The first part of the string is the domain SID, which is the same for all SIDs in a domain. The last part is the RID, which is unique for each SID in the domain. In the example above, 1001 is the RID assigned to a particular security principal in the domain.
The RID Master assigns RID pools to DCs. Each pool consists of a unique, contiguous range of RIDs, which the DC can use to generate a unique SID when it creates a security principal. By centrally managing the distribution of RIDs, the RID Master ensures that no two domain controllers allocate the same RID to different security principals, which guarantees the uniqueness of each SID within the domain.
Once a DC is assigned a RID pool from the RID Master, it does not need to communicate with the RID Master every time it creates an AD object. However, the loss of a domain’s RID Master will eventually lead to an inability to create new objects in the domain, since the pools on the DCs will be depleted. In mature AD environments, this would take a considerable length of time as there are relatively few objects created.
Generally, the RID Master role is assigned to the primary domain controller (PDC) in a domain because the PDC typically receives the most attention from administrators and therefore has high availability. In mature domains, the overhead generated by the RID Master role is negligible. Though this role is not as critical as some of the other roles, it is still important to ensure connectivity to the RID Master.
PDC Emulator (PDCE)
Primary Domain Controller (PDC) is a term from the days of Windows NT, when a single DC had a writable copy of the directory. Today, most DCs in a domain are writable, but there is still one designated DC that emulates the role of a PDC. Each domain in an Active Directory forest contains one DC with the PDCE role.
The Primary Domain Controller Emulator is responsible for the following:
- Time synchronization — The PDCE is the authoritative time source for the domain; all workstations and member servers sync their time with the PDC emulator. In a multi-domain forest, the PDCE in the forest root domain is the timekeeper for all the other PDC emulators in the forest. To maintain accurate timekeeping throughout the forest, the PDC emulator in the root domain should be configured to synchronize with an external reliable time source. Time is a very big deal. For instance, Kerberos authentication will fail if the difference between the clock of a requesting host and the clock of the authenticating DC exceeds the specified maximum (5 minutes by default); this helps counter certain malicious activities, such as replay attacks.
- Password changes and authentication —When a user’s password is changed, the change is initially made on the DC that authenticated the user. This committed password update is immediately replicated to the domain’s PDCE. If an account attempts to authenticate against a DC that has not yet received a recent password change through scheduled replication, the request is passed to the domain PDCE, which will process the authentication request and instruct the requesting DC to either accept or reject it. This behavior ensures that passwords can reliably be processed even if recent changes have not fully propagated through scheduled replication.
- Account lockout status — Similarly, if an account gets locked out due to multiple failed logon attempts, the lockout is processed at the PDC emulator immediately, and the lockout status is replicated to all DCs in the domain to ensure that a locked-out account cannot log on to another DC. When an administrator unlocks an account, that change is immediately replicated through the domain.
- Group Policy updates — If updates are made to a Group Policy object (GPO), they are initially committed to the DC with the PDC Emulator role. This prevents versioning conflicts that could occur if a GPO happened to be modified on two DCs at approximately the same time.
- Backward compatibility — In organizations that still have legacy devices or software that are dependent on Windows NT, the PDCE emulator can serve as a PDC. This includes functioning as the Master Browser, which collects and distributes information about applications and devices on a network.
- Distributed file system (DSF) — By default, DFS root servers will periodically request updated DFS namespace information from the PDCE. This behavior can lead to resource bottlenecks, but enabling the Dfsutil.exe RootScalability parameter will allow DFS root servers to request updates from the closest DC.
The PDC Emulator role should be placed on a highly accessible, well-connected, high-performance DC, since the loss of the DC with this role can have an immediate and significant impact on operations.
Infrastructure Master
Infrastructure Master is a domain-level role whose primary function is handling cross-domain object references in a multi-domain forest. The Infrastructure Master compares objects in its domain against objects in other domains in the same forest and synchronizes them with the global catalog servers.
These actions are not needed in certain cases. Obviously, in environments with only one AD domain, there are no cross-domain references to handle. And if all the DCs in a domain are global catalog hosts (which is common today because of better network bandwidth), they will all have up-to-date information without relying on the Infrastructure Master.
The Infrastructure Master is assigned the following responsibilities:
- Cross-domain object references — In a multi-domain forest, objects from one domain might be referenced in another domain. A common example is when a user from one domain is added to a security group in another domain. In this scenario, a placeholder (called a “phantom object”) is created in the group’s domain to represent the user from the other domain. Phantom objects are used to track and manage persistent references to deleted objects and link-valued attributes that refer to objects in another domain in the forest.
- Updating group-to-user references —The Infrastructure Master is responsible for updating an object’s SID and distinguished name (DN) in a cross-domain object reference and translating GUIDs, SIDs and DNs between domains in a forest.
- Stale object cleanup — The Infrastructure Master regularly checks its domain for objects that are no longer valid (such as objects from deleted trusts) and removes them.
If a DC with the Infrastructure Master role fails, the impact is mainly administrative. Though cross-domain object link names might not resolve correctly during its absence, cross-domain group memberships will still function.
Domain Naming Master
The Domain Naming Master is an enterprise-level role; there is only one Domain Naming Master in an Active Directory forest. It is the only DC capable of adding new domains and application partitions to the forest or removing existing ones from the forest.
Since addition and removal of domains and partitions are infrequent and rarely time-critical operations, the Domain Naming Master role has little overhead, and its loss can be expected to result in little to no operational impact.
Schema Master
Schema Master is an enterprise-level FSMO role, so there is only one Schema Master in an Active Directory forest. The schema defines the object classes (types of objects, like users, groups, and computers) and their attributes that can exist in the AD database. Sometimes, the schema needs to be changed, for example, to add a required new object type or attribute. To prevent overlapping or conflicting updates, only the DC with the Schema Master role can process changes to the AD schema. Whenever a schema update is made, the Schema Master ensures that the changes are replicated to all other DCs in the forest.
If a schema update is required, the Schema Master must be available. However, schema changes are relatively infrequent in most environments. Circumstances that can require a schema change include upgrading Active Directory, integrating certain types of enterprise software, raising the functional level of the forest, and upgrading the operating system of a DC to a higher version than currently exists in the forest.
Identifying FSMO Role Owners
It is important to know which DCs in your AD environment host the 5 FSMO roles. There are multiple ways of identifying the DCs that own FSMO roles.
Using the command prompt
You can quickly see which DCs hold the FSMO roles by running the following command:
netdom query fsmo /domain:<DomainName>
Using PowerShell
Another option is to run this PowerShell script:
(Get-ADForest).Domains |
ForEach-Object{ Get-ADDomainController -Server $_ -Filter {OperationMasterRoles -like "*"}} | `
Select-Object Domain, HostName, OperationMasterRoles
Using Windows Active Directory Tools
You can find the DCs that hold the three domain-level FSMOs using Active Directory Users and Computers (ADUC). First, right-click on your domain and select Operations Masters, as shown below:
Then click on each tab to see the corresponding DC:
To find out which DC holds the Domain Naming Master role, right-click on Active Directory Domains and Trusts and select Operations Master, as shown below.
The resulting pop-up will identify the current role holder:
To identify the DC that holds the Schema Master FSMO role, you can use the Active Directory Schema snap-in. However, this snap-in does not appear by default in Windows Server, so before you can use it, you need to take the following steps:
- Click Start and then Run, and type regsvr32 schmmgmt.dll in the Open box, as shown below. Then click OK.
- On the Console menu, click Add/Remove Snap-in, click Add, double-click Active Directory Schema, click Close, and then click OK.
The Active Directory Schema snap-in will then be available. To view the server holding the schema master role, open the snap-in, right-click Active Directory Schema in the top-left pane, and then click Operations Master. An example of the result is shown below:
Transferring and Seizing FSMO Roles
While Active Directory automatically assigns FSMO roles upon the creation of an AD domain or forest, both domain and enterprise admins have the discretion to transfer these roles between DCs as needed. Note that to transfer an FSMO role, both the current role holder and the target DC must be active and connected to the network.
If the current FSMO role holder is unavailable and can’t be restored, a domain or enterprise admin will need to seize the role instead.
It is a best practice to document when FSMO roles are transferred or seized.
How Netwrix Can Help
As we have seen, FSMO roles are important for both business continuity and security. Therefore, it’s vital to audit all changes to your FSMO roles. Netwrix Auditor for Active Directory automates this monitoring and can alert you to any suspicious change so you can take action before it leads to downtime or a data breach.
Of course, safeguarding FSMO roles is just one part of a security strategy. Netwrix Auditor for Active Directory delivers comprehensive visibility and control over the core systems that you need. It continuously monitors and analyzes changes and other activity in Active Directory to spot emerging threats and empowers you to respond promptly and effectively to minimize the impact on business processes, user productivity and security.
