What are FSMO Roles in Active Directory?

What are FSMO Roles in Active Directory?

Active Directory allows object creations, updates, and deletions to be committed to any authoritative domain controller. This is possible because every Active Directory domain controller maintains a writable copy of its own domain’s partition – except, of course, Read-Only Domain Controllers. After a change has been committed, it is replicated automatically to other domain controllers through a process called multi-master replication. This behavior allows most operations to be processed reliably by multiple domain controllers and provides for high levels of redundancy, availability, and accessibility within Active Directory.

An exception to this behavior applies to certain Active Directory operations that are sensitive enough that their execution is restricted to a specific domain controller. Active Directory addresses these situations through a special set of roles. Microsoft has begun referring to these roles as the Operation Masters roles, but they are more commonly referred to by their original name, Flexible Single-Master Operator (“FSMO”) roles.

What are FSMO Roles?

Active Directory has five FSMO (generally pronounced “FIZZ-mo”) roles, two of which are enterprise-level (i.e., one per forest) and three of which are domain-level (i.e., one per domain). The enterprise-level FSMO roles are called the Schema Master and the Domain Naming Master. The domain-level FSMO roles are called the Primary Domain Controller Emulator, the Relative Identifier Master, and the Infrastructure Master.

The following commands can be used to identify FSMO role owners. Command Prompt:

netdom query fsmo /domain:<DomainName>

PowerShell:

(Get-ADForest).Domains | `
ForEach-Object{ Get-ADDomainController -Server $_ -Filter {OperationMasterRoles -like "*"}} | `
Select-Object Domain, HostName, OperationMasterRoles 

In a new Active Directory forest, all five FSMO roles are assigned to the initial domain controller in the newly-created forest root domain.

When a new domain is added to an existing forest, only the three domain-level FSMO roles are assigned to the initial domain controller in the newly-created domain; the two enterprise-level FSMO roles already exist in the forest root domain.

FSMO roles often remain assigned to their original domain controllers, but they can be transferred if necessary.

The 5 FSMO Roles of Active Directory

What are the 5 FSMO Roles in Active Directory?

Schema Master

The Schema Master is an enterprise-level FSMO role; there is only one Schema Master in an Active Directory forest.

The Schema Master role owner is the only domain controller in an Active Directory forest that contains a writable schema partition. As a result, the domain controller that owns the Schema Master FSMO role must be available to modify its forest’s schema. This includes activities such as raising the functional level of the forest and upgrading the operating system of a domain controller to a higher version than currently exists in the forest, either of which will introduce updates to Active Directory schema.

The Schema Master role has little overhead and its loss can be expected to result in little to no immediate operational impact; unless schema changes are necessary, it can remain offline indefinitely without noticeable effect. The Schema Master role should only be seized when the domain controller that owns the role cannot be brought back online. Bringing the Schema Master role owner back online after the role has been seized from it may introduce serious data inconsistency and integrity issues into the forest.

Domain Naming Master

The Domain Naming Master is an enterprise-level role; there is only one Domain Naming Master in an Active Directory forest.

The Domain Naming Master role owner is the only domain controller in an Active Directory forest that is capable of adding new domains and application partitions to the forest. Its availability is also necessary to remove existing domains and application partitions from the forest.

The Domain Naming Master role has little overhead and its loss can be expected to result in little to no operational impact, as the addition and removal of domains and partitions are performed infrequently and are rarely time-critical operations. Consequently, the Domain Naming Master role should only need to be seized when the domain controller that owns the role cannot be brought back online.

RID Master

The Relative Identifier Master (“RID Master”) is a domain-level role; there is one RID Master in each domain in an Active Directory forest.

The RID Master role owner is responsible for allocating active and standby Relative Identifier (“RID”) pools to domain controllers in its domain. RID pools consist of a unique, contiguous range of RIDs. These RIDs are used during object creation to generate the new object’s unique Security Identifier (“SID”). The RID Master is also responsible for moving objects from one domain to another within a forest.

In mature domains, the overhead generated by the RID Master is negligible. As the PDC in a domain typically receives the most attention from administrators, leaving this role assigned to the domain PDC helps ensure reliable availability. It is also important to ensure that existing domain controllers and newly promoted domain controllers, especially those promoted in remote or staging sites, have network connectivity to the RID Master and are reliably able to obtain active and standby RID pools.

The loss of a domain’s RID Master will eventually lead to result in an inability to create new objects within the domain as the remaining domain controllers’ RID pools are depleted. While the unavailability of the domain controller that owns the RID Master role may appear as though it would cause significant operational disruption, the relatively low volume of object creation events in a mature environment tends to result in the impact of such an event being tolerable for a considerable length of time. Bringing a RID Master back online after having seized its role can potentially introduce duplicate RIDs into the domain. Consequently, this role should only be seized from a domain controller if the domain controller that owns the role cannot be brought back online.

Infrastructure Master

The Infrastructure Master is a domain-level role; there is one Infrastructure Master in each domain in an Active Directory forest.

The Infrastructure Master role owner is the domain controller in each domain that is responsible for managing phantom objects. Phantom objects are used to track and manage persistent references to deleted objects and link-valued attributes that refer to objects in another domain within the forest (e.g., a local-domain security group with a member user from another domain).

The Infrastructure Master may be placed on any domain controller in a domain unless the Active Directory forest includes domain controllers that are not global catalog hosts. In that case, the Infrastructure Master must be placed on a domain controller that is not a global catalog host.

The loss of the domain controller that owns the Infrastructure Master role is only likely to be noticeable to administrators and can be tolerated for an extended period. While its absence will result in the names of cross-domain object links failing to resolve correctly, the ability to utilize cross-domain group memberships will not be affected.

PDC Emulator

The Primary Domain Controller Emulator (“PDC Emulator” or “PDCE”) is a domain-level role; there is one PDCE in each domain in an Active Directory forest.

The PDCE role owner is responsible for several crucial operations:

  • Backward Compatibility. The PDCE mimics the single-master behavior of a Windows NT primary domain controller. To address backward compatibility concerns, the PDCE registers as the target domain controller for legacy applications that perform writable operations and certain administrative tools that are unaware of the multi-master behavior of Active Directory domain controllers.
  • Time Synchronization. Each PDCE serves as the master time source within its domain. The PDCE in forest root domain serves as the preferred Network Time Protocol (“NTP”) server in the forest. The PDCE in every other domain within the forest synchronizes its clock to the forest root PDCE, non-PDCE domain controllers synchronize their clocks to their domain’s PDCE, and domain-joined hosts synchronize their clocks to their preferred domain controller.

    NOTE: The Kerberos authentication protocol includes timestamp information and is an example of the importance of time synchronization within an Active Directory forest. Kerberos authentication will fail if the difference between a requesting host’s clock and the clock of the authenticating domain controller exceeds 5 minutes (this tolerance is configurable, but Microsoft’s best practice recommendation is to maintain the default 5-minute value on the Maximum tolerance for computer clock synchronization setting). This behavior is intended to counter certain malicious activities, such as “replay attacks”.
  • Password Update Processing. When computer and user passwords are changed or reset by a non-PDCE domain controller, the committed update is immediately replicated to the domain’s PDCE. If an account attempts to authenticate against a domain controller that has not yet received a recent password change through scheduled replication, the request is passed through to the domain PDCE. The PDCE will attempt to process the authentication request and instruct the requesting domain controller to either accept or reject the authentication request. This behavior ensures that passwords can reliably be processed even if recent changes have not fully-propagated through scheduled replication. The PDCE is also responsible for processing account lockouts, as all failed password authentications are passed through to the PDCE.
  • Group Policy Updates. All Group Policy Object (“GPO”) updates are committed to the domain PDCE. This prevents the potential for versioning conflicts that could occur if a GPO was modified on two domain controllers at approximately the same time.
  • Distributed File System. By default, Distributed File System (“DFS”) root servers will periodically request updated DFS namespace information from the PDCE. While this behavior can lead to resource bottle-necking, enabling the Dfsutil.exe Root Scalability parameter will allow DFS root servers to request updates from the closest domain controller (see https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/hh341472(v=ws.10) for more information).

As a consequence of its responsibilities, the PDCE should be placed on a highly-accessible, well-connected, high-performance domain controller. Additionally, the forest root domain PDC Emulator should be configured with a reliable external time source.

While the loss of the domain controller that owns the PDC Emulator role can be expected to have an immediate and significant impact on operations, the nature of its responsibilities results in the seizure of the PDCE role having fewer implications to the domain than the seizure of other roles. The seizure of the PDCE role is considered a recommended best practice in the event a domain controller that owns the PDCE role becomes unavailable as a result of an unscheduled outage.

Transferring FSMO Roles

As mentioned earlier in this post, FSMO roles are necessary to perform certain important operations and they are not redundant. As a result, it can be either desirable or necessary to move FSMO roles from one domain controller to another.

One method of transferring FSMO roles is to demote the domain controller that owns the roles. When a domain controller is demoted it will attempt to transfer any FSMO roles it owns to suitable domain controllers in the same site. Domain-level roles can only be transferred to domain controllers in the same domain, but enterprise-level roles can be transferred to any suitable domain controller in the forest. While there are rules that govern how the domain controller being demoted will decide where to transfer its FSMO roles, there is no way to directly control where its FSMO roles will be transferred.

The ideal method of moving an FSMO role is to actively transfer them using either the Management Console, PowerShell, or ntdsutil.exe. During a manual transfer, the source domain controller will synchronize with the target domain controller before transferring the role.

The account performing a Schema Master role must be a member of the Schema Admins and Enterprise Admins group. Membership in the Enterprise Admins group is necessary to transfer the Domain Naming Master role. The PDCE, RID Master and Infrastructure Master roles can be transferred by an account with membership in the Domain Admins group of the domain where the roles are being transferred.

Management Console

Transferring FSMO roles using the Management Console can require the use of up to three different snap-in modules.

Transferring the Schema Master Role

The Schema Master role can be transferred using the Active Directory Schema Management snap-in.

If the is not among the available Management Console snap-ins, it will need to be registered. To register the Active Directory Schema Management Console, open an elevated command prompt, type regsvr32 schmmgmt.dll, and press Enter:

Register the Active Directory Schema Management Console

Once the DLL has been registered, run the Management Console as a user who is a member of the Schema Admins group and add the Active Directory Schema snap-in to the Management Console:

Add the Active Directory Schema snap-in to the Management Console

Right-click the Active Directory Schema node and select “Change Active Directory Domain Controller”. Choose the domain controller that the Schema Master FSMO role will be transferred to and click the “OK” button to bind the Active Directory Schema snap-in to the target domain controller (a warning may appear explaining that the snap-in will not be able to make changes to the schema because it is not connected to the Schema Master):

Change Active Directory Domain Controller

Right-click the Active Directory Schema node again and select “Operations Master”:

Operations Master

Click the “Change” button to begin the transfer of the Schema Master role to the targeted domain controller:

Transfer of the Schema Master role to the targeted domain controller

Transferring the Domain Naming Master Role

The Domain Naming Master role can be transferred using the Active Directory Domains and Trusts Management Console snap-in.

Run the Management Console as a user who is a member of the Enterprise Admins group and add the Active Directory Domains and Trusts snap-in to the Management Console:

Active Directory Domains and Trusts

Right-click the Active Directory Domains and Trusts node and select “Change Active Directory Domain Controller”. Choose the domain controller that the Domain Naming Master FSMO role will be transferred to and click the “OK” button to bind the Active Directory Domains and Trusts snap-in to the target domain controller:

Change Active Directory Domain Controller to transfer FSMO Role

Right-click the Active Directory Domains and Trusts node again and select “Operations Master”:

Operations Master

Click the “Change” button to begin the transfer of the Domain Naming Master role to the targeted domain controller:

Change Domain Naming Master role

Transferring the RID Master, Infrastructure Master, or PDC Emulator Roles

The RID Master, Infrastructure Master, and PDC Emulator roles can all be transferred using the Active Directory Users and Computers Management Console snap-in.

Run the Management Console as a user who is a member of the Domain Admins group in the domain where the FSMO roles are being transferred and add the Active Directory Users and Computers snap-in to the Management Console:

Active Directory Users and Computers Management

Right-click either the Domain node or the Active Directory Users and Computers node and select “Change Active Directory Domain Controller”. Choose the domain controller that the FSMO role will be transferred to and click the “OK” button to bind the Active Directory Users and Computers snap-in to the target domain controller:

Change Active Directory Domain Controller

Right-click the Active Directory Users and Computers node and click “Operations Masters”:

Operations Masters

Select the appropriate tab and click the “Change” button to begin the transfer of the FSMO role to the targeted domain controller:

Transfer FSMO role to the targeted domain controller

PowerShell

The Move-ADDirectoryServerOperationMasterRole PowerShell cmdlet can be used to transfer FSMO roles. The roles being transferred are specified using the -OperationMasterRole parameter:

Move-ADDirectoryServerOperationMasterRole -Identity TargetDC -OperationMasterRole pdcemulator, ridmaster, infrastructuremaster, schemamaster, domainnamingmaster

ntdsutil.exe

ndtsutil.exe is a lightweight command-line tool that can perform a number of useful functions, including the transfer of FSMO roles.

FSMO roles can be transferred using the following steps:

  1. Open an elevated command prompt.
  2. Type ntdsutil and press Enter. A new window will open.
  3. At the ntdsutil prompt, type roles and press Enter.
  4. At the fsmo maintenance prompt, type connections and press Enter.
  5. At the server connections prompt, type connect to server <DC> (replacing <DC> with the hostname of domain controller that the FSMO roles are being transferred to) and press Enter. This will bind ntdsutil to the target domain controller.
  6. Type quit and press Enter.
  7. At the fsmo maintenance prompt, enter the appropriate commands for each FSMO role being transferred:
    • To transfer the Schema Master FSMO role, type transfer schema master and press Enter.
    • To transfer the Domain Naming Master FSMO role, type transfer naming master and press Enter.
    • To transfer the RID Master FSMO role, type transfer rid master and press Enter.
    • To transfer the Infrastructure Master FSMO role, type transfer infrastructure master and press Enter.
    • To transfer the PDC Emulator FSMO role, type transfer pdc and press Enter.
  8. To exit the fsmo maintenance prompt, type quit and press Enter.
  9. To exit the ntdsutil prompt, type quit and press Enter.
FSMO Role transfer using ndtsutil.exe

Seizing FSMO Roles

Transferring FSMO roles requires that both the source domain controller and the target domain controllers be online and functional. If a domain controller that owns one or more FSMO roles is lost or will be unavailable for a significant period, its FSMO roles can be “seized” to another domain controller.

In most cases, FSMO roles should only be seized if the original FSMO role owner cannot be brought back into the environment. The reintroduction of a FSMO role owner following the seizure of its roles can cause significant damage to the domain or the forest. This is especially true of the Schema Master and RID Master roles.

The Move-ADDirectoryServerOperationMasterRole cmdlet allows the use of a -Force parameter that can be used to seize FSMO roles. Using the -Force parameter will direct the cmdlet to attempt an FSMO role transfer and then to seize the roles if the transfer attempt fails.

The following instructions can be used to seize FSMO roles with the ntdsutil.exe utility:

  1. Open an elevated command prompt.
  2. Type ntdsutil and press Enter. A new window will open.
  3. At the ntdsutil prompt, type roles and press Enter.
  4. At the fsmo maintenance prompt, type connections and press Enter.
  5. At the server connections prompt, type connect to server <DC> (replacing <DC> with the hostname of domain controller that the FSMO roles are being seized to) and press Enter. This will bind ntdsutil to the target domain controller.
  6. Type quit and press Enter.
  7. At the fsmo maintenance prompt, enter the appropriate commands for each FSMO role being transferred:
    • To transfer the Schema Master FSMO role, type seize schema master and press Enter.
    • To transfer the Domain Naming Master FSMO role, type seize naming master and press Enter.
    • To transfer the RID Master FSMO role, type seize rid master and press Enter.
    • To transfer the Infrastructure Master FSMO role, type seize infrastructure master and press Enter.
    • To transfer the PDC Emulator FSMO role, type seize pdc and press Enter.
  8. To exit the fsmo maintenance prompt, type quit and press Enter.
  9. To exit the ntdsutil prompt, type quit and press Enter.

Summary

As each role only exists once in a forest or domain, it is important to understand not only the location of each FSMO role owner and the responsibilities of each FSMO role but also the operational impact introduced by the unavailability of a FSMO role-owning domain controller. Such information is valuable in situations where a domain controller is unavailable, whether due to unanticipated events or while scheduling and performing planned upgrades and maintenance.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Start a Free StealthAUDIT® Trial!

No risk. No obligation.

Privacy Preference Center

      Necessary

      Advertising

      Analytics

      Other