What are Active Directory FSMO roles and How do they Work

The FSMO (Flexible Single Master Operations) roles are vital when it comes to Active Directory. The FSMO roles help keep Active Directory consistent among all of the domain controllers in a forest by allowing only specific domain controllers to perform certain operations. Additionally, Active Directory FSMO Roles are essential for your Active Directory environment’s stability and security.

Unless your pen testing or security consultants have expertise in these topics – not many Active directory security assessments (ADSA) take this feature into account during Domain Controller security reviews. Security is one of the primary benefits of FSMO roles. Microsoft came up with a solution to separate the DC tasks across multiple roles. In case something happens to one then other DC’s can take over to keep operations going – helping and providing the flexibility. Now you may remember why FSMO roles exist.

What is FSMO?

FSMO stands for Flexible Single Master Operations. Microsoft Active Directory is by far the most widely used domain authentication service across the globe ever since it was released in 1999 (in Windows Server 2000). Over the decades Microsoft has made many advancements in its Active Directory to transform it into the secure system we are using today.

One of these updates included the introduction of a “Single Master Model”. In this model, only one domain controller could make the required changes in a domain, while the other DCs would only complete authentication requests.

This model created a single point of failure, which means if the master or primary domain controller goes down, there is no way to make changes to the domain until the master DC is back up.

To remediate this issue, Microsoft separated the responsibilities of a DC into multiple roles. The administrators could then assign these roles to multiple domain controllers, and if one of the DCs would go down, the other DCs could take over the missing role and business continuity would remain intact.

This concept is named the Flexible Single Master Operation or FSMO for short, and the roles are known as FSMO roles.

FSMO roles in Active Directory

There are a total of five FSMO roles in the active directory, out of which two are forest-wide and three are domain-wide.

• Forest Wide:
• Schema master
• Domain naming master
• Domain-wide:
• PDC emulator
• RID master
• Infrastructure master

Schema Master role

The Schema Master is an enterprise-level FSMO role. In an Active Directory forest, only one Schema Master role is allowed per directory.

An Active Directory schema defines the attributes that can be associated with an object such as employee ID, phone number, email address, login name etc. Domain controllers that are assigned the Schema Master role, is the only DC that has read-write access to a schema partition, this means that the DC that owns the Schema Master FSMO role must be available to edit or modify its forest schema.

The Schema Master role can perform activities such as raising the functional level of the forest as well as upgrading the operating system of the primary domain controller, doing any of these tasks will result in updates being made to the AD Schema.

If for any reason the DC that owns the Schema Master roles is down or unavailable, this role can be seized. However, the role should only be seized if administrators have made sure that the original DC can not be brought back online. If in case the original DC is brought online after the role has been seized, critical data inconsistency and integrity issues will arise within the forest.

Domain naming master role

The Domain Naming Master is an enterprise-level FSMO role. In an Active Directory forest, only one role is allowed.

The domain controller that is assigned the Domain Naming Master role, is the only DC in the active directory which has permissions to add new domains and application partitions in the forest. Apart from creating new domains, this role is also required to remove an existing domain or application partition from the forest.

Similar to the Schema Master role, the Domain Naming Master role should also only be seized when it is made sure that the domain controller can not be brought back online, otherwise bringing the original domain controller online after seizing the role can result in data inconsistency and integrity issues.

RID master role

The Relative Identifier Master or RID master FSMO role is a domain level role. For each domain in the Active Directory forest, there is one RID Master.

Each RID Master role is responsible to allocate active and standby Relative Identifiers (RIDs) pools to the domain controllers within their domain. The RID pools generally consist of contiguous and unique ranges of RIDs, which can be used to create unique Security Identifiers (SIDs) in the object creation stage. Other than this the RID Master is also capable of moving objects between multiple domains within the same forest.

If a RID Master is lost or becomes unavailable, no new objects can be created within the forest, and the remaining RID pools will be depleted. Although this may seem like a significant loss, in a mature environment the instances for object creation are very low, thus a mature environment can easily tolerate the damages if its RID Master becomes unavailable for a long time.

As with the other FSMO roles, if the role is seized and the original domain controller is brought back online, duplication RIDs may be introduced in the domains resulting in data inconsistency.

Infrastructure master role

The Infrastructure Master is a domain level role. For each domain in the Active Directory forest, there is only one Infrastructure Master.

The responsibility of the Infrastructure Master role is to manage Phantom objects. These phantom objects are used to maintain, manage and keep track of persistent references to deleted objects as well as to track link-valued attributes used to refer to objects in other domains within the same forest.

The role of an Infrastructure Master can be assigned to any domain controller, except for the domain controllers that are global catalogue hosts. A domain controller can not be an Infrastructure Master and a global catalogue host simultaneously.

If an Infrastructure Master domain controller goes offline, the absence can be tolerated by the administrators for extended periods. The only issue that would arise as a result of the Infrastructure Master being down is that the names of cross-domain object links will fail to resolve in a timely and correct manner, however, the cross-domain group memberships will not be affected.

PDC Emulator role

The Primary Domain Controller Emulator or PDC Emulator is a domain level role. For each domain in the Active Directory forest, there is one PDC Emulator.

The PDC Emulator is responsible for several operations including:

• Backwards compatibility – The PDCE replicates the single-master behaviour that a Windows NT primary DC behaves like. For systems that require backwards or legacy compatibility, the PDCE registers as the target domain controller and performs all read-write operations.
• Time synchronisation – The PDCE serves as the master time source with its domain. The PDCE, which is in the forest root domain, serves as the preferred Network Time Protocol (NTP) server.
• Password updating process- When a computer or user changes their password using a non-PDCE domain controller, this commit is replicated at the domain’s PDCE. However, if the replication has not taken place yet, and the user sends an authentication request, this request is then passed through the domain’s PDCE, where the PDCE requests the domain controller to accept or reject the request. This process ensures that the password can be reliably processed even if the changes have not been fully propagated.
• Group policy updates – All the GPO refreshers are committed to the domain’s PDCE. This mitigates the likelihood of conflicts.
• Distributed file system – DFS root servers often request updated DFS namespace information from the domain’s PDCE.

If a PDCE domain controller goes offline the resulting impact can be significant and would require immediate attention. However, unlike the rest of the FSMO roles seizing the PDCE role is a recommended best practice in case of failure, and if the original domain controller is brought back online there will be no data inconsistencies.

How to check FSMO roles

There are two methods generally used to quickly check FSMO roles.

Using PowerShell

To check FSMO roles using PowerShell is a very simple and easy process that hardly requires two to three commands.

1. Firstly open PowerShell on the Windows Server:
2. In PowerShell, type and execute the command to return the forest FSMO roles: Get-ADForest yourdomain | Format-Table SchemaMaster,DomainNamingMaster :
3. In PowerShell, type and execute the command to return the domain FSMO roles: Get-ADDomain your domain | format-table PDCEmulator, RIDMaster, InfrastructureMaster :

Using Netdom Query

The second method to retrieve FSMO roles is by using the Netdom command-line tool, which is used to manage AD domains and trusts. This tool is built-in in Windows Server 2003 and above.

1. On the Windows server, open up the command prompt:
2. In the command prompt, type netdom query fsmo and hit enter. This command would return the five FSMO roles, along with the name of the DC that they are on:

Transferring FSMO Roles

Sometimes the administrators are required to transfer the FSMO roles from one domain controller to another. One method of transferring the roles is by demoting the domain controller who owns the roles in the first place. When a DC is demoted, it will automatically transfer its roles to a suitable DC. The domain-level roles will be automatically transferred to a domain controller within the same domain, while the enterprise-level roles can be transferred to any domain controller on the forest.

Nevertheless, the ideal method for moving an FSMO is using the management console or PowerShell for active transfer.

Using PowerShell

In PowerShell, the following command can be used to transfer FSMO roles. The role that needs to be transferred is specified in the -OperationMasterRole Flag.

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

Using the management console

For transferring roles using the management console, three different snap-in modules are required.

Transferring the Schema Master Role

1. To transfer the Schema, the Active Directory Schema Management snap-in is required. If this module is unavailable, then it would need to be registered by entering the following command in an elevated command prompt: regsvr32 schmmgmt.dll
2. Once the DLL is loaded, open the management console and add the snap-in.
3. To transfer the role, right-click the Active Directory schema node and select “Change Active Directory Domain Controller” and choose the DC you want to transfer the role to and click “OK”.
4. Right-click the Active Directory schema node again and click “Operations Master”.
5. Click the “Change” button to start the transfer process.

Transferring the Domain Naming Master Role

1. To transfer the Domain Naming Master role, the Active Directory Domain and Trust Management snap-in are required.
2. To transfer the role, right-click the Active Directory Domain and Trust node and select “Change Active Directory Domain Controller” and choose the DC you want to transfer the role to and click “OK”.
3. Right-click the Active Directory schema node again and click “Operations Master”.
4. Click the “Change” button to start the transfer process.

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

1. To transfer the RID Master, Infrastructure Master and PDC emulator role, the Active Directory Users and Computers Management snap-in is required.
2. To transfer the role, right-click the Active Directory Users and Computers node and select “Change Active Directory Domain Controller” and choose the DC you want to transfer the role to and click “OK”.
3. Right-click the Active Directory schema node again and click “Operations Master”.
4. Click the “Change” button to start the transfer process.

Seizing FSMO roles

As discussed earlier, if a domain controller that owns one or more FSMO roles becomes unavailable or lost for a long time, the FSMO associated with that domain controller can be seized to another domain controller. It should be noted here that, transferring a role takes place when both domain controllers are active and online, whereas seizing takes place when the original FSMO role owner domain controller is no longer active.

However, it should be taken into account that an FSMO role should only be seized if the original domain controller can not be brought back online. The reason for this is when a role is seized to another domain controller, and the previous domain controller with the same roles is brought back into the environment the chances of data inconsistency, and loss of data integrity increase significantly. This can cause substantial damage to the domain as well as the entire forest. The risk increases even more if the role in question is with the Schema Master of the RID master role.

The Move-ADDirectoryServerOperationMasterRole PowerShell command discussed earlier, for transferring roles, has a -Force switch that can be used to seize FSMO roles.

Conclusion

You know that it’s important to keep your Active Directory secure, but you don’t have the time or expertise to do it. Many organisations underline the importance of such crown jewel that is responsible for authentication and authorisation across the estate.

Active directory is a gold mine for threat actors that opens flood gates to pretty much every account, associated service and underlying system in an organisation. You must validate your security controls and analyse the gaps on a continuous basis through focussed network penetration tests, that cover Active Directory architecture and security settings (domain and global group security policies).