Category: Windows Server

Active Directory (AD) allows object creations, updates and deletions to be committed to any authoritative domain controller (DC). This is possible because every DC (except read-only DCs) maintains a writable copy of its own domain’s partition. Once a change has been committed, it is replicated automatically to other DCs 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 in Active Directory.Handpicked related content:

• [Free eBook] What is Active Directory?

An exception 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 operations master roles, but they are more commonly referred to by their original name: flexible single-master operator (FSMO) roles.

What are FSMO Roles?

The 5 FSMO Roles

Active Directory has five FSMO roles:

• Schema Master
• Domain Naming Master
• Infrastructure Master
• Relative ID (RID) Master
• PDC Emulator

In every forest, there is a single Schema Master and a single Domain Naming Master. In each domain, there is one Infrastructure Master, one RID Master and one PDC Emulator. At any given time, there can be only one DC performing the functions of each role. Therefore, a single DC could be running all five FSMO roles; however, in a single-domain environment, there can be no more than five servers that run the roles.

In a multi-domain environment, each domain will have its own Infrastructure Master, RID Master and PDC Emulator. When a new domain is added to an existing forest, only those three domain-level FSMO roles are assigned to the initial domain controller in the newly created domain; the two enterprise-level FSMO roles (Schema Master and Domain Naming Master) already exist in the forest root domain.

Schema Master

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 DC that owns the Schema Master FSMO role must be available to modify its forest’s schema. Examples of actions that update the schema include 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 Schema Master role has little overhead and its loss can be expected to result in little to no immediate operational impact. Indeed, unless schema changes are necessary, it can remain offline indefinitely without noticeable effect. The Schema Master role should be seized only when the DC 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 can introduce serious data inconsistency and integrity issues for the forest.

Domain Naming Master

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, since the addition and removal of domains and partitions are performed infrequently and are rarely time-critical operations. Consequently, the Domain Naming Master role should need to be seized only when the DC that owns the role cannot be brought back online.

RID Master

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 DCs in its domain. RID pools consist of a unique, contiguous range of RIDs, which 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. Since the primary domain controller (PDC) in a domain typically receives the most attention from administrators, leaving this role assigned to the domain PDC helps ensure its availability. It is also important to ensure that existing DCs and newly promoted DCs, 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 in the domain as the RID pools in the remaining DCs are depleted. While it might seem that unavailability of the DC owning the RID Master role would cause significant operational disruption, in mature environments the impact is usually tolerable for a considerable length of time because of a relatively low volume of object creation events. Bringing a RID Master back online after having seized its role can introduce duplicate RIDs into the domain, so this role should be seized only if the DC that owns it cannot be brought back online.

Infrastructure Master

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

The Infrastructure Master synchronizes objects with the global catalog servers. The Infrastructure Master will compare its data to a global catalog server’s data and receive any data not found in its database from the global catalog server. If all DCs in a domain are also global catalog servers, then all DCs will have up-to-date information (assuming that replication is functional). In such a scenario, the location of the Infrastructure Master role is irrelevant since it doesn’t have any real work to do.

The Infrastructure Master role owner is also 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 DCs 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 DC that owns the Infrastructure Master role is likely to be noticeable only 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.Handpicked related content:

• [Free Guide] Active Directory Group Management Best Practices

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 PDC Emulator controls authentication within a domain, whether Kerberos v5 or NTLM. When a user changes their password, the change is processed by the PDC Emulator.

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 DC for legacy applications that perform writable operations and certain administrative tools that are unaware of the multi-master behavior of Active Directory DCs.
• 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 DCs synchronize their clocks to their domain’s PDCE; and domain-joined hosts synchronize their clocks to their preferred DC. One example of the importance of time synchronization is Kerberos authentication: Kerberos authentication will fail if the difference between a requesting host’s clock 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 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 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. The PDCE is also responsible for processing account lockouts, since all failed password authentications are passed to the PDCE.
• Group Policy updates. All Group Policy object (GPO) updates are committed to the domain PDCE. This prevents versioning conflicts that could occur if a GPO was modified on two DCs 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 bottlenecks, enabling the Dfsutil.exe Root Scalability parameter will allow DFS root servers to request updates from the closest DC.

The PDCE should be placed on a highly-accessible, well-connected, high-performance DC. Additionally, the forest root domain PDC Emulator should be configured with a reliable external time source.

While the loss of the DC that owns the PDC Emulator role can be expected to have an immediate and significant impact on operations, the seizure of the PDCE role has fewer implications to the domain than the seizure of other roles. Seizure of the PDCE role is a recommended best practice if the DC that owns that role becomes unavailable due to an unscheduled outage.

Identifying Role Owners

You can use either the command prompt or PowerShell 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

Transferring FSMO Roles

FSMO roles often remain assigned to their original domain controllers, but they can be transferred if necessary. Since FSMO roles are necessary for certain important operations and they are not redundant, it can be desirable or even necessary to move FSMO roles from one DC to another.

One method of transferring a FSMO role is to demote the DC that owns the role, but this is not an optimal strategy. When a DC is demoted, it will attempt to transfer any FSMO roles it owns to suitable DCs in the same site. Domain-level roles can be transferred only to DCs in the same domain, but enterprise-level roles can be transferred to any suitable DC in the forest. While there are rules that govern how the DC 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 it using either the Management Console, PowerShell or ntdsutil.exe. During a manual transfer, the source DC will synchronize with the target DC before transferring the role.

To transfer an FSMO role, an account must have the following privileges:

How to Transfer FSMO Roles using the Management Console

Transferring the Schema Master Role

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

If this snap-in is not among the available Management Console snap-ins, it will need to be registered. To do so, open an elevated command prompt and enter the command regsvr32 schmmgmt.dll.

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:

Right-click the Active Directory Schema node and select Change Active Directory Domain Controller. Choose the DC that the Schema Master FSMO role will be transferred to and click OK to bind the Active Directory Schema snap-in to that DC. (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.)

Right-click the Active Directory Schema node again and select Operations Master. Then click the Change button to begin the transfer of the Schema Master role to the specified DC:

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:

Right-click the Active Directory Domains and Trusts node and select Change Active Directory Domain Controller. Choose the DC that the Domain Naming Master FSMO role will be transferred to, and click OK to bind the Active Directory Domains and Trusts snap-in to that DC.

Right-click the Active Directory Domains and Trusts node again and select Operations Master. Click the Change button to begin the transfer of the Domain Naming Master role to the selected DC:

Transferring the RID Master, Infrastructure Master or PDC Emulator Role

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:

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 OK button to bind the Active Directory Users and Computers snap-in to that DC.

Right-click the Active Directory Users and Computers node and click Operations Masters. Then select the appropriate tab and click Change to begin the transfer of the FSMO role to the selected DC:

How to Transfer FSMO Roles using PowerShell

You can transfer FSMO roles using the following PowerShell cmdlet:

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

How to Transfer FSMO Roles using ntdsutil.exe

To transfers an FSMO role using ndtsutil.exe, take the following steps:

1. Open an elevated command prompt.
2. Type ntdsutil and press Enter. A new window will open.
3. At the ntdsutilprompt, type roles and press Enter.
4. At the fsmo maintenanceprompt, type connections and press Enter.
5. At the server connectionsprompt, type connect to server <DC> (replacing <DC> with the hostname of the DC that the FSMO role is being transferred to) and press Enter. This will bind ntdsutil to the specified DC.
6. Type quit and press Enter.
7. At the fsmo maintenance prompt, enter the appropriate command for each FSMO role being transferred:
   • transfer schema master
   • transfer naming master
   • transfer rid master
   • transfer infrastructure master
   • transfer pdc
8. To exit the fsmo maintenanceprompt, type quit and press Enter.
9. To exit the ntdsutilprompt, type quit and press Enter.

Seizing FSMO Roles

Transferring FSMO roles requires that both the source DC and the target DC be online and functional. If a DC that owns one or more FSMO roles is lost or will be unavailable for a significant period, its FSMO roles can be seized, rather than transferred.

In most cases, FSMO roles should be seized only 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 forest. This is especially true of the Schema Master and RID Master roles.

To seize FSMO roles, you can use the Move-ADDirectoryServerOperationMasterRole cmdlet with the ?Force parameter. The cmdlet will attempt an FSMO role transfer; if that attempt fails, it will seize the roles.

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.

However, FSMO roles are just one part of your security strategy — you need to understand and control what is happening across your core systems. Netwrix Auditor for Active Directory goes far beyond protecting FSMO roles and facilitates strong management and change control across Active Directory.

By automating Active Directory change tracking and reporting, Netwrix Auditor empowers you to reduce security risks. You can improve your security posture by proactively identifying and remediating toxic conditions like directly assigned permissions, before attackers can exploit them to gain access to your network resources. Moreover, you can monitor changes and other activity in Active Directory changes to spot emerging problems and respond to them promptly — minimizing the impact on business processes, user productivity and security.

Source :
https://blog.netwrix.com/2021/11/30/what-are-fsmo-roles-active-directory/