Understanding FSMO Roles in Active Directory

If your organization runs on Microsoft Active Directory, you rely on one or more domain controllers to keep AD operations going. On the surface, Active Directory seems to run on a peer-to-peer models in which every domain controller (DC) has the authority to create, modify, and delete AD objects. That is because every domain controller holds a writable copy of its domain's partition, the only exception being read-only DCs. Once changes or additions are made, they are synchronized to other DCs through multi-master replication. However, some pivotal operations are confined to certain DCs assigned special roles known as Flexible Single Master Operations (FSMO) roles or operation master roles.

Below, we detail the importance of FSMO roles in Active Directory and share a few best practices for ensuring effective management and protection.

Introduction to FSMO Roles

FSMO stands for Flexible Single Master Operations, a term that originated from Microsoft's work to address the limitations of the multi-master replication model in AD. FSMO roles ensure the functioning and consistency of the Active Directory across a Windows domain by assigning a specific critical task to designated controllers and providing a single authority process change. By centralizing these operations within specific domain controllers, FSMO roles help maintain the integrity and stability of Active Directory environments.

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.

The Need for FSMO Roles

Before we delve into the actual FSMO roles, it is important to understand the multi-master architecture that creates the need for them.

Multi-master model vs. Single-master model

Microsoft's early network architecture was built on a Single-Master Model in which a single server held the writable database copy containing all user and computer object accounts. This server was solely responsible for making additions or modifications to the account database. Other servers in the network maintained read-only copies of the database. While these servers could authenticate users, they could not change the database. If the master went offline or malfunctioned, no new accounts could be created, and existing accounts could not be modified. This created a single point of failure.

To address the limitations of the Single-Master Model, Microsoft transitioned to a Multi-Master Model in Active Directory (AD), where each domain controller (DC) maintains a writable copy of the account database. This design ensures redundancy and resilience, as operations can continue even if one DC becomes unavailable. However, this multi-master approach introduced the potential for conflicts, where different DCs might attempt to make conflicting changes simultaneously. To prevent such inconsistencies and maintain AD's integrity and performance, Microsoft introduced Flexible Single Master Operations (FSMO) roles.

Importance of FSMO Roles in AD

By assigning FSMO roles, Active Directory ensures that essential operations-such as updates to the schema, domain naming, and time synchronization-are handled in an orderly and consistent manner. If the DC holding a specific FSMO role goes down, the role can be transferred to another DC, ensuring continuity. The distribution of FSMO roles is crucial for maintaining a balanced and efficient network, and organizations can customize this distribution based on their specific needs and best practices for performance and redundancy.

The 5 FSMO Active Directory Roles Explained

Active Directory has five unique FSMO roles:

• Schema Master (forest level)
• Domain Naming Master (forest level)
• Relative ID (RID) Master (domain level)
• Primary Domain Controller (PDC) Emulator (domain level)
• Infrastructure Master (domain level)

Let's learn more about each FSMO role and its specific function within the Active Directory infrastructure:

Schema Master

What is the schema master FSMO role?

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

When and how schema master is used

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

Domain Naming Master

Roles and responsibilities of 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.

Common scenarios involving Domain Naming Master

You may need to alter your AD forest as your business evolves, or additional domains may be added to your forest because of a merger or acquisition. Since the 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.

RID Master

What is the RID Master role?

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's order to ensure that each security principal (such as a user or group) has a unique security identifier.

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.

Functionality and usage of RID Master

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, guaranteeing each SID's uniqueness 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, losing 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)

Understanding the PDC Emulator role: explanation and history

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.

PDC Emulator functions in AD

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 login 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

Role of the Infrastructure Master FSMO

Infrastructure Master is a domain-level role whose primary function is handling the references of cross domain objects 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.

When and why Infrastructure Master is needed

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

FSMO Roles in Forest and Domain Contexts

Forest-level FSMO Roles

As you can see from the list above, the last two FSMO roles operate forest-wide, meaning only one DC in the forest can be the role holder. In other words, every Active Directory Forest has a single Schema Master and a single Domain Naming Master.

Domain-level FSMO Roles

The other three FSMO roles operate within the jurisdiction of a single domain. In each domain, there is one Infrastructure Master, one RID Master, and one PDC Emulator. Each domain will host these three FSMO roles in environments with multiple domains on one or more DCs.

Managing FSMO Roles

Identifying FSMO role holders

Knowing which DCs in your AD environment host the 5 FSMO roles is important. There are multiple ways of identifying the DCs that own FSMO roles. One quick way is using command prompt using the following command:

netdom query fsmo /domain:

Here is an example:

You can also use PowerShell using the following script:

(Get-ADForest).Domains |

ForEach-Object{ Get-ADDomainController -Server $_ -Filter {OperationMasterRoles -like "*"}} | `

Select-Object Domain, HostName, OperationMasterRoles

Here is an example below using PowerShell:

You can also find which DC's are assigned FSMO roles using Windows Active Directory Tools. Using Active Directory Users and Computers, right-click on your domain and select Operations Masters as shown below:

Then click on each tab to find the three domain FSMOs.

You can use Active Directory Domains and Trusts to find which DC holds the Domain Naming Master role by right-clicking on Active Directory Domains and Trust and then selecting OperationsMaster, as shown below.

Which will then pull up the following pop up to identify the current role holder.

The process of identifying the Schema Master FSMO is a little more involved. You can find its identity using the Active Directory Schema snap-in, however, the snap-in does not appear by default within Windows Server. To gain access to it you need to register it using the Schmmgmt.dll file. To do this, click Start > Run, and type regsvr32 schmmgmt.dll in the Open box. Then click OK as shown below.

Once successfully registered, you need to do the following:

1. On the Console menu, click Add/Remove Snap-in, click Add, double-click Active Directory Schema, click Close, and then click OK.
2. Right-click Active Directory Schema in the top-left pane, and then click Operations Masters to view the server holding the schema master role.

An example is shown in the screenshot below:

This will give you access to the snap-in from which you can right click on Active Directory Schema and choose Operations Master.

Transferring and Seizing FSMO Roles

When and how to transfer FSMO Roles

While Active Directory will automatically assign the FSMO roles to your DCs, there are times when you may want to transfer a role to another DC. For instance, you may need to take a DC down for maintenance that currently holds an assigned role. Both domain and enterprise admins have the discretion to move these roles between domain controllers as needed.

Seizing FSMO roles

For FSMO role transfers, both the current holder and the target domain controller roles must be active and network connected. If the current FSMO role holder is unavailable and can't be restored, a domain or enterprise admin will need to seize the role. As this is a more abrupt move, seizing an FSMO role should only be conducted when necessary.

Best Practices and Troubleshooting

Optimizing FSMO role placement for greater efficiency

While there are no hard and fast rules concerning FSMO placement within Active Directory, the following recommendations will garner you the best results:

• Place the PDC Emulator and RID Master on a reliable domain controller with good connectivity, that is readily available to other domain controllers, as their roles are critical for day-to-day Active Directory activities.
• If possible, the Infrastructure Master should not be placed on a global catalog server. This is not possible, of course, if all DCs are global catalog servers.
• Place the two forest-side roles (Schema Master and Domain Naming Master) on the same DC, as they are not utilized very often.

Common issues and solutions

There are some key instances that might indicate that an FSMO is unavailable. For instance, any attempt to update the AD schema will result in an error if the Schema Master is down. You will also be unable to add or remove domains in the forest if the Domain Naming Master is not accessible. In these circumstances, you need to confirm which DC has that role and verify that it is accessible.

The inability to access a DC with an assigned FSMO role can result from multiple factors, including:

• The server being offline or powered down
• Network connectivity issues
• DNS configuration errors or failures

Troubleshooting these issues may require you to use network diagnostic tools to verify connectivity throughout the network, verify DNS settings including SRV records, and ensure the physical and logical health of the server holding the FSMO role. If the problem persists, consider transferring the role to another healthy DC or, as a last resort, seizing the role if the current holder is permanently unavailable.

Monitoring and auditing FSMO roles

Because these FSMO roles are so critical, you should regularly monitor the servers that hold these roles. At a very basic level, you can check the event logs on your domain controllers. Specific events can indicate when the FSMO roles were transferred or seized. Your organization may also use monitoring or management software that might have historical data or alerts related to FSMO role changes. There are also third-party tools out there that offer far more functionality. One example is Netwrix Auditor for Active Directory automates the monitoring of FSMO roles and can alert you to any suspicious or unforeseen changes. It is also considered best practice to document when these FMSO role changes take place so that this type of history can be accessed if necessary.

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.

Conclusion

The FSMO roles in AD are an example of how much happens under the surface. While forest-level FSMO roles may not be critical every day, your business does depend on your domain FSMO roles and services. In addition to the threat of expected failures that periodically occur, these roles make ideal targets for malicious threat actors who aim to disrupt business operations. This means you need visibility into the complexities of your AD environment.

AD support teams are increasingly adopting automated monitoring tools to address these challenges. These solutions can provide:

• Enhanced visibility into the status and performance of FSMO role-holders
• Ream time alerts concerning any changes or anomalies in FSMO role assignments
• Proactive identification of potential issues before they can escalate
• Extensive auditing capabilities that can track historical changes.

This proactive approach can help AD administrators maintain the health and stability of an AD infrastructure and strengthen the organization's overall security posture.

FAQ

What is FSMO?

FSMO stands for Flexible Single Master Operations. These operations are special responsibilities assigned to specific domain controllers to prevent conflicts and ensure the smooth operation of the network.

What are FSMO and its roles?

Active Directory is based on a multi-master model in which FSMO assigns designated authority to designated domain controllers.

What are the 5 FSMO roles, and how would you check the role holders?

The 5 FSMO roles are as follows:

• Schema Master: Responsible for updates to the AD schema.
• Domain Naming Master: Controls adding or removing domains in the forest.
• RID (Relative ID) Master: Allocates RID pools to DCs to create unique security identifiers (SIDs).
• PDC (Primary Domain Controller) Emulator: This handles password changes and time synchronization and acts as a fallback for certain types of authentication.
• Infrastructure Master: Manages references to objects in other domains

Using standard Active Directory tools and PowerShell, you can find which domain controllers are the role holders of these FSMOs.

Where are FSMO roles located?

By default, the first domain controller of an Active Directory Forest root domain hosts the Schema Master and the Domain Naming Master. The first domain controller of each domain hosts the PDC Emulator, RID Master, and Infrastructure Master. Active Directory administrators can move these roles to other DCs if they want.

Why do we seize FSMO roles?

Should a domain controller go offline suddenly, its FSMO role becomes unavailable. A role transfer is not possible if there is no connectivity to the original role holder. In that case, the role will have to be seized and assigned to another DC.

What is the most important FSMO role?

While all of the FSMO roles are important, the PDC Emulator is the most crucial as it manages the time for the domain, password changes, and group policy configuration. In some cases, legacy systems may depend on it for the sole means for handling authentication requests.

How do I find FSMO roles?

There are multiple ways to find out which domain controllers have the Active Directory FSMO roles. One is to use the "netdom query fsmo" command using command prompt. You can also use Active Directory tools and PowerShell to find which server hosts each role.

Where should FSMO roles be placed?

If you only have one or two domain controllers in your AD environment, you don't have much choice in the matter. All FSMO roles should be assigned to a DC that has good connectivity with all the other DCs in the forest. If possible, the Infrastructure Master should not be placed on a global catalog server.

What FSMO roles should be together?

The two forest-level FSMO roles of the Schema Master and the Domain Naming Master should be placed on the same DC, but it is only a recommendation.