09/06/2024 | News release | Distributed by Public on 09/06/2024 11:58
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.
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.
Before we delve into the actual FSMO roles, it is important to understand the multi-master architecture that creates the need for them.
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.
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.
Active Directory has five unique FSMO roles:
Let's learn more about each FSMO role and its specific function within the Active Directory infrastructure:
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.
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.
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.
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.
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.
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.
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:
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 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.
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:
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.
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.
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.
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:
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.
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.
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.
While there are no hard and fast rules concerning FSMO placement within Active Directory, the following recommendations will garner you the best results:
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:
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.
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.
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.
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:
This proactive approach can help AD administrators maintain the health and stability of an AD infrastructure and strengthen the organization's overall security posture.
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.
Active Directory is based on a multi-master model in which FSMO assigns designated authority to designated domain controllers.
The 5 FSMO roles are as follows:
Using standard Active Directory tools and PowerShell, you can find which domain controllers are the role holders of these FSMOs.
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.
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.
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.
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.
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.
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.