FSMO Roles in Active Directory
In Flexible Single Master Operation, the responsibilities of the single-master are split into separate roles. These roles can be distributed to any domain controller in the enterprise, based on the requirements. This in turn overcomes the drawbacks faced by the multi-master model. These single-master roles are called Flexible Single Master Operation (FSMO) roles and the domain controller is referred to as the FSMO or Operations Master.
There are five basic FSMO roles, of which two are forest-wide and the remaining three are domain-wide. While the forest-wide roles are supposed to be limited to one per forest, the domain-wide roles are limited to one per domain. The five FSMO roles are listed as follows.
- Schema Master
- Domain Naming Master
- RID Master
- PDC Emulator
- Infrastructure Master
The Schema Master and Domain Naming Master are forest-wide roles, whereas the RID Master, PDC Emulator and the Infrastructure Master are domain-wide roles.
Schema Master
The Schema Master role is assigned to one domain controller per forest. The schema partition is called the “schema naming context” and is located in CN=schema, CN=configuration, DC=<domain>. Only the Schema Master is allowed to update the directory schema and these changes are replicated to all the other domain controllers in the forest.
Domain Naming Master
The Domain Naming Master role is also assigned to only one domain controller per forest, similar to the Schema Master. The domain naming partition is called the “configuration naming context” and is located in CN=partitions, CN=configuration, DC=<domain>. The Domain Naming Master is the one that is responsible for changes in the domain name space throughout the forest. Only the domain controller holding this role is allowed to add or remove domains and cross references to domains in external directories.
RID Master
The RID Master role is assigned to one domain controller per domain and is responsible for processing RID Pool Requests from all the domain controllers within a domain. In Active Directory, all the security principal objects are identified by their Security Ids (SIDs). Each SID is composed of a Domain SID and a Relative ID (RID). The Domain SID is the same for all objects within the domain, whereas the RID is unique for each object. The RIDs are allocated by the designated domain controller, from a pool of RIDs. The DC requests for additional RIDs from the RID Master, when the RID pool falls below the threshold. The function of the RID Master is to assign unallocated RIDs to the requesting domain controller. In addition to this, it also removes and replaces an object in different domains during an object move.
PDC Emulator
The PDC Emulator role is domain-wide and hence is assigned to only one domain controller per domain. It performs the following functions. It provides time service for synchronizing time in an enterprise. Password changes performed by other domain controllers are replicated to the PDC Emulator in a preferential manner. Authentication failures due to incorrect passwords are forwarded to the PDC Emulator. This is done before the user is given a password failure message. It also processes account lockouts. It handles all the functionality provided by an NT4-style PDC.
Infrastructure Master
The Infrastructure Master role is assigned to only one domain controller per domain. It handles tasks such as updating an object’s GUID, SID and domain name in a cross-domain object reference. The Infrastructure Master must be a domain controller which is not a Global Catalog Server (GC).
Global Catalog (GC)
In addition to the five basic FSMO roles, the Global Catalog (GC) role is designated to a domain controller as an unofficial sixth role. The Global Catalog Server stores a partial, read-only replica of all the objects in a forest. It is commonly used for searching and locating objects using their attributes.
Placement of Active Directory FSMO Roles
The roles are initially allocated to the specific domain controllers by the Active Directory Installation Wizard. All of the roles are usually installed on one server by default. This practice is applicable for single domain forests, where the roles are placed in the forest root domain.
However, in large organizations containing multiple domain controllers (or in multi-domain forests), the roles must be installed on separate domain controllers. It is recommended that all the forest-wide roles are placed on one domain controller, and all the domain-wide roles are placed on a different domain controller. There are several guidelines and practices to be followed while placing FSMO roles in Active Directory. They are discussed as follows.
The Schema Master and Domain Naming Master should be placed on the same domain controller in the forest root domain. In other words, they should be placed on the forest root domain Primary Domain Controller (PDC). This domain controller should also host a copy of the Global Catalog.
However, if the forest functional level is raised to Windows Server 200, the Domain Naming Master need not be placed on a Global Catalog. But it should at least be a direct replication partner with a GC that resides in the same site. The RID Master and PDC Emulator should be placed on the same domain controller in every domain. This is because, the PDC Emulator utilizes RIDs. The PDC Emulator should be placed on the best hardware in a reliable subnet, which contains replica DCs in the same site and domain. This domain controller need not host the Global Catalog, since this might cause an increase in the load handled by the DC. The Infrastructure Master should be placed on a domain controller that does not host the Global Catalog. However, if all the DCs in the domain are assigned the Global Catalog role, then the Infrastructure Master can be placed on any domain controller.
These are the three basic rules for placing the FSMO roles on domain controllers.
Best Practices for Active Directory FSMO Roles
In addition to the rules for placing and assigning FSMO roles to domain controllers, some general guidelines have to be followed while selecting DCs and delegating to them the role of Operations Masters. Some of these best practices are discussed as given below.
The FSMO roles should be checked regularly for availability, and to check which domain controllers hold FSMO roles. This is helpful for troubleshooting any issues with the domain controllers. A standby domain controller should be configured to take over as an FSMO role owner, in case the original role owner encounters a failure. The roles can be transferred to or seized by the standby domain controller. The standby DC should be an intra-site replication partner with the current role holder.
The FSMO roles should be hosted on a minimum number of domain controllers. This makes it easier to track them down in case they go offline or undergo a failure. The domain controller that holds an FSMO role should be a server that is highly available at all times. This is to make sure that the FSMO role holder does not go offline, as it may lead to serious losses and implications. For example, if the PDC Emulator goes offline even for a few minutes, there is a huge loss of data which cannot be replicated easily. Hence the DC should employ suitable hardware that enables it to operate even if one hard disk fails. However, it need not be a high capacity server.
The FSMO roles should be placed on domain controllers that are accessible by other computers. For instance, to access an RID Pool, the RID Master has to be accessed by the other domain controller. The FSMO roles should not be transferred or moved on a regular basis. The difference between transferring and seizing roles has to be understood. The roles should be transferred only if the current role holder is online and the role is to be moved to a different domain controller. But, the roles are seized if the current role holder experiences a failure or goes offline unexpectedly.
Thus, the best practices and guidelines that were listed above should be followed in order to ensure that the FSMO roles are assigned and managed properly, while preventing errors and failure.