5

Placing Operations Master Roles

In organizations, we use roles and responsibilities to maintain different levels of accountability. With roles and responsibilities in place, everyone knows what they are supposed to do in their job. This applies to applications/services as well. Within application/services we have different roles. These roles are also associated with different sets of privileges. While one role has read-only permissions, another has permission to do system-wide configuration changes. This helps to maintain the integrity of the application/services.

Active Directory is built upon a multi-master database model. This means that any writable domain controller in the domain can change the Active Directory configuration and it will replicate to all other domain controllers. But there are some operations that need to be controlled in a sensible manner in order to maintain the integrity of Active Directory Domain Services (AD DS). These operations are better managed in single-master mode rather than multi-master mode. These special roles are called Flexible Single Master Operation (FSMO) roles. These roles can run from one domain controller or be distributed among multiple domain controllers (according to the guidelines). But each role can appear only once in a domain or forest. This makes the operations master role holder important in an AD DS infrastructure. If the domain controller that holds the operations master role fails and can't recover, another domain controller will have to forcefully regain control over its operations master roles.

In this chapter, we are going to look into the following topics:

• FSMO roles and duties
• FSMO role placement
• Moving FSMO roles
• Seizing FSMO roles

Each FSMO role has its own part to play in the Active Directory environment. Before we look into FSMO role placement, let's go ahead and look into the responsibilities of each role.

FSMO roles

There are five FSMO roles in the Active Directory infrastructure. Each of the roles is responsible for performing specific Active Directory tasks that other domain controllers in the infrastructure are not permitted to perform. These five FSMO roles are divided into two categories based on their operation boundaries:

When we create the first Active Directory forest and the first Active Directory domain, all these FSMO roles will be installed in the domain's first domain controller (obviously; there's no other place). The majority of the "time," engineers leave the default configuration as it is, even though they keep adding domain controllers. Keeping FSMO roles in one domain controller is not a fault, but if you want to get the most out of it, role placement change is inevitable.

However, there are many different things that can have an impact on FSMO role placements, such as the size of the organization, the network topology, and infrastructure resources.

Schema operations master

This role boundary is the forest. This means that an Active Directory forest can have only one schema master. The owner of this role is the only domain controller in the forest who can update the Active Directory schema.

In order to make schema changes in the forest, it also needs to have a user account that is a member of the Schema Admins group. Once the schema changes are done from the schema master role owner, those changes will be replicated to other domain controllers in the forest.

In an Active Directory forest, the schema master role owner can be found using the following command:

Get-ADForest | select SchemaMaster

When you add a new version of Active Directory to the domain for the first time, it will need a schema modification. If you run the Active Directory configuration wizard with a user account that has Domain Admins permissions, it will fail. You need an account with Schema Admins privileges.

Domain-naming operations master

The domain-naming operations master role holder is responsible for adding and removing domain controllers to and from the Active Directory forest. In the Active Directory forest, the domain-naming operations master role owner can be found using the following command:

Get-ADForest | select DomainNamingMaster

When you add or remove a domain controller, the system will contact the domain-naming operations master role holder via the Remote Procedure Call (RPC) connection, and if it fails, it will not allow you to add or remove the domain controller from the forest. This is a forest-wide role, and only one domain-naming operations master role holder can exist in one forest.

PDC emulator operations master

The PDC operations master role is a domain-wide setting, which means each domain in the forest will have a PDC operations master role holder. One of the most common Active Directory-related interview questions is: Which FSMO role is responsible for time synchronization? The answer is PDC! In an Active Directory environment, it allows a maximum of a 5-minute time difference (time skew) between the server and client to maintain successful authentication. If it's more than 5 minutes, devices will not be able to be added to the domain, users will not be able to authenticate, and the Active Directory-integrated application will start throwing authentication-related errors.

It is important that domain controllers, computers, and servers in the Active Directory domain controller agree on one clock:

Figure 5.1: Time sources

Computers in a domain will sync their time with the domain controller they are authenticated with. Then, all of the domain controllers will sync their time with the domain PDC role holder. All the domain PDC role holders will sync the time with the forest root domain PDC role holder. Finally, the root domain PDC role holder will sync the time with an external time source.

The time accuracy of PDC is really important as the majority of resources in infrastructure will use PDC as the time source. We can use an external reliable time source for PDC to maintain the time accuracy. It is always recommended to use regulated sources such as NIST for the task. NIST has several stratum-1 network time servers (directly link to UTC) that we can use as time sources. The complete list of NIST time servers is available on https://bit.ly/3HLOQsG.

Also, before we configure the time source, there are certain TCP/UDP ports that need to be open in the edge firewall. More information about this is available on https://bit.ly/3xf1ZFW.

Once firewall rules are in place, we can configure the PDC by using the following steps:

1. Log in to PDC as a domain administrator.
2. Launch Command Prompt as an administrator.
3. Run w32tm.exe /config /syncfromflags:manual /manualpeerlist:132.163.97.1,0x8 /reliable:yes /update.

   In the preceding command, 132.163.97.1 is one of the NIST time servers; you can change this and choose any external source.

4. Then, to update the config, run w32tm.exe /config /update:

   

Figure 5.2: Configuring the external time source

Apart from time synchronization, the PDC role holder is also responsible for maintaining password change replications.

Also, in the event of authentication failures, PDC is responsible for locking down the account. All the passwords changed in other domain controllers will be reported back to the PDC role holder. If any authentication failure occurs in a domain controller before it passes the authentication failure message to the user, it will check the password saved in the PDC, as that will prevent errors due to password replication issues.

In the Active Directory domain, the PDC role owner can be found using the following command:

Get-ADDomain | select PDCEmulator

The PDC is also responsible for managing the Group Policy Object (GPO) edit. Every time a GPO is viewed or updated, it will be done from the copy stored in the PDC's SYSVOL folder. Due to the importance of the role, it is recommended to choose the most reliable domain controller to hold the PDC role.

RID operations master role

The RID master role is a domain-level role, and each domain in the forest can have RID role owners. It is responsible for maintaining a pool of RIDs that will be used when creating objects in the domain. Each and every object in a domain has a unique security identifier (SID). The RID value is used in the process of SID value creation. The SID is a unique value to represent an object in Active Directory. The RID is the incremental portion of the SID value. Once the RID value is being used to generate a SID, it will not be used again. Even after deleting an object from Active Directory, we will not able to reclaim the RID value back.

This ensures the uniqueness of the SID value. The RID role owner maintains a pool of RIDs. When the domain has multiple domain controllers, it will assign a block of 500 RID values for each domain controller. When pool usage is more than 50%, domain controllers will request another block of RIDs for the RID role owner.

In the Active Directory domain, the RID role owner can be found using the following command:

Get-ADDomain | select RIDMaster

In the event of a RID role owner failure, its impact will be almost unnoticeable until all domain controllers run out of allocated RID values. It will also not allow you to move objects between domains or add new domain controllers.

Infrastructure operations master

This role is also a domain-level role, and it is responsible for replicating SID and distinguished name (DN) value changes to cross-domains. SID and DN values get changed based on their location in the forest. If objects are moved between domains, their new values need to be updated in groups and Active Control Lists (ACLs). This is taken care of by the infrastructure operations master. This will ensure that the moved objects have access to their resources without interruptions.

In the Active Directory domain, the infrastructure operations master role owner can be found using the following command:

Get-ADDomain | select InfrastructureMaster

The infrastructure operations master role owner checks its database periodically for foreign group members (from other domains), and once it finds those objects, it checks its SID and DN values with the global catalog server. If the value in the global catalog is different from the local value, it will replace its value with the global catalog server's value. Then, it will replicate it to other domain controllers in the domain.

By design, the global catalog server holds a partial copy of every object in the forest. It does not have the need to keep a reference of cross-domain objects. If the infrastructure master is in place in a global catalog server, it will not know about any cross-domain objects. Therefore, the infrastructure operations master role owner should not be a global catalog server. However, this is not applicable when all the domain controllers are global catalogs in a domain because, that way, all the domain controllers will have up-to-date information about objects.

FSMO role placement

The first domain controller in the first Active Directory forest will hold all five FSMO roles. All these roles are critical in the Active Directory infrastructure. Some of them are heavily used and some roles are only used on specific occasions. Some role owners will not be able to afford any downtime, and some roles will still be able to have downtime. So, based on features, impact, and responsibilities, these can be placed on different domain controllers. However, FSMO role placement is heavily dependent on Active Directory design.

Active Directory's logical and physical topology

If it's a single forest-single domain environment, it is not wrong to keep all the FSMO roles in one domain controller. According to the best practices, the infrastructure operations master role should not be held by a global catalog server. But, this is only if the environment has multiple domains. In a single forest-single domain environment, on most occasions, all servers are global catalog servers as well.

In the following example, in the rebeladmin.com single forest-single domain environment, there are three domain controllers in the infrastructure:

Figure 5.3: FSMO role placement example 1

PDC01 is recognized as the most powerful (capacity) and most reliable domain controller. Therefore, PDC01 holds all five FSMO roles. SDC01 and SDC02 are also two global catalog servers. In this case, just moving the infrastructure operations master role to one of the domain controllers will not have a significant impact.

In the event of a PDC01 failure, secondary domain controllers will be able to claim ownership of FSMO roles (this process is called seizing FSMO roles and will be described later in the chapter).

In a multiple-domain environment, this will change. Forest-wide roles and domain-wide roles will need to be placed properly in order to maintain high availability.

In the following example, Rebeladmin Corp. has three domains. The rebeladmin.net domain is the forest root domain. The rebeladmin.com domain is used at its headquarters in the USA and rebeladmin.ca is used at its Canadian branch:

Figure 5.4: FSMO role placement example 2

All three domains share one forest. Therefore, forest-wide roles, which are the Schema master and the Domain-naming master, will be placed in the forest root domain, rebeladmin.net. It has three domain controllers. PDC01 is identified as the most reliable domain controller.

The Schema master and the Domain-naming master roles use relatively lower amounts of processing power as forest-wide changes will not happen frequently. But high availability is a must, as other domain activities will depend on it.

PDC is the most consumed FSMO role, as it will replicate password changes, control time synchronization, and manage GPO edits. So, it's important for PDC to run on the domain controller that has the most processing power. Domain controllers depend on the RID master role. Therefore, reliable communication between domain controllers and the RID master role holder is crucial.

It is advised that you keep PDC and RID together in one domain controller in order to avoid network latency-related issues. So, in the end, we can place four FSMO roles in PDC01. In a multi-domain environment, cross-domain referencing is important. If the user account in the forest root domain changes its name, it will immediately be replicated to all the domain controllers in the forest root domain. But, if the user is part of a group in the other domains, they also need to know about these new values. Therefore, SDC01 is made as a non-global catalog server and it holds the Infrastructure master role. SDC02 is kept as a backup domain controller; if any of the FSMO role holders are dead, it can use it to claim role ownership. In some infrastructures, the forest root domain is not used for active operations. In such situations, keeping multiple domain controllers is management overhead.

The rebeladmin.ca domain is used in a regional office infrastructure. It has less than 25 users, and most of them are salespeople. Therefore, keeping multiple domain controllers cannot be justified based on capacity or reliability facts. The setup is limited to two domain controllers, and PDC01 hosts all three domain-wide FSMO roles. SDC01 is kept as a backup domain controller, to be used in a Disaster Recovery (DR) scenario.

Connectivity

Healthy replication between domain controllers is a must for the Active Directory infrastructure. FSMO role holders are designated to do specific tasks in the infrastructure. Other domain controllers, devices, and resources should have a reliable communication channel with FSMO role holders in order to get these specific tasks done when required.

In Active Directory infrastructures, there can be regional offices and remote sites that are connected using WAN links. Most of the time, these WAN links have limited bandwidth. These remote sites can host domain controllers, too. If replication traffic between sites is not handled in an optimized way, it can turn into a bottleneck. Rebeladmin Corp. is a managed services provider and it has two offices. The headquarters is located in Toronto and the operation center is based in Seattle, USA. It is connected via a 512 KB WAN link. In the Toronto office, there are 20 users and in the Seattle office, there are 500 users. It runs on a single-domain Active Directory infrastructure.

As I mentioned earlier, among all these FSMO roles, the PDC is the highly used FSMO role. Devices and users keep communicating with the PDC more frequently than other FSMO role holders. In this scenario, if we place the PDC in the Toronto office, 500 users and associated devices will need to go through the WAN link in order to communicate with the PDC. But if we place it in the Seattle site, then the traffic that will pass through the WAN link will be lower. In a regional office scenario, make sure you always place the PDC near the site that hosts the greatest number of users, devices, and resources.

The network topology design for inter-site connectivity also has an impact on the FSMO role placement. In the following example, the Active Directory setup has three Active Directory sites with a single domain infrastructure. Site Canada connects to Site USA and Site USA connects to Site Europe. But Site Canada does not have a direct connection with Site Europe:

Figure 5.5: Inter-site connectivity

Now, if the FSMO roles are placed in Site Canada, Site Europe will have issues communicating with it. Site Europe will not be able to perform any FSMO-related tasks. According to the network topology, the best option will be to place the FSMO roles in Site USA, as both sites have a direct connection to it.

The number of domain controllers

The number of domain controllers that can be deployed on an Active Directory infrastructure depends on the budget and available resources (computer resources, space, power, and connectivity).

Based on the number of domain controllers, engineers will need to decide to either run all FSMO roles together or distribute them among domain controllers. It is recommended that you have at least two domain controllers on a site. One will be holding the FSMO roles, and the other one will be kept as a standby domain controller. In the event of a primary server failure, FSMO roles can be hosted on the standby domain controller.

Capacity

The capacity of the Active Directory domain controllers also affects the FSMO role placement. When the number of users, devices, and other resources increases, it also increases FSMO role-related activities. If it's a multi-site environment, it's recommended that you place FSMO roles on sites that run with a high capacity of Active Directory objects in order to lower the impact of replication and latency issues.

FSMO role holders are also involved in typical Active Directory tasks, such as user authentication. In large Active Directory environments (10,000+ objects), it is important to prioritize FSMO-related tasks over regular Active Directory tasks. This mainly impacts the PDC emulator, as it is the most active FSMO role. It is possible to prioritize domain controller operations by editing the weight value of the DNS SRV record. The default value is 100, and reducing it will reduce the number of user authentication requests. The recommended value is 50. The domain controller with the highest weight value has more authentication referrals than other domain controllers. As an example, let's assume we have two domain controllers in place and one has a weight of 100 and the other one has a weight of 150. The domain controller with the highest weight value (150) will have more authentication referrals.

This can be done by adding a new registry key under HKLMSYSTEMCurrentControlSetServicesNetlogonParameters. The key should have a DWORD value with the entry name LdapSrvWeight.

Best practices

In previous sections, I have explained things we need to consider for FSMO role placement. Here, I'd like to summarize the points we discussed so far:

• Domain controllers in the forest should be able to reach FSMO role holders without any network layer connection barriers. If domain controllers are in a segmented network, make sure traffic is routed correctly.
• We can distribute FSMO roles to multiple servers; however, more servers means more management overhead. Unless it is a real requirement, try to keep FSMO roles to a fewer number of computers.
• Place the PDC role in the most reliable and powerful domain controller. Avoid installing applications and other Windows Server roles in PDC to reduce unnecessary resource usage.
• Keep the RID master and PDC roles in the same domain controller (same domain). Communication between these roles is crucial and keeping this in the same domain controller ensures reliable connectivity. Resource usage of the RID master role is small and it will not make a significant impact.
• Place the schema master role and domain-naming master role in the PDC of the forest root domain. In a mature Active Directory forest, we will rarely change the schema or add/remove domain controllers. But when it comes to that, it needs to be done in a controlled manner. When these critical changes happen in a domain, both of these role holders need to be available.
• If possible, keep the infrastructure master role in a non-global catalog server. This is because a global catalog server keeps a partial copy of every Active Directory object in the forest. The infrastructure master role will not update any object as it will not have any information about objects it doesn't hold. However, if the Active Directory recycling bin feature is enabled, every domain controller is responsible for updating cross-domain object references. In that case, it doesn't matter where the infrastructure role is placed.

Moving FSMO roles

In the Active Directory setup, sometimes, FSMO roles will need to be moved from one domain controller to another. Here, I have listed a few scenarios where it will be necessary to consider FSMO roles transfers:

• Active Directory upgrades: When there is the requirement for an Active Directory upgrade, first we need to introduce the new domain controllers to the existing setup and then move the FSMO roles. After that, the domain controllers that run older versions can be decommissioned.
• Active Directory logical and physical topology: When installing the first domain controller in the infrastructure, it will automatically hold all five FSMO roles. But, based on the Active Directory topology design, the roles can be transferred to ideal locations, as discussed in the previous section. This can be based on the initial design or an extended design.
• Performance and reliability issues: FSMO role owners are responsible for specific tasks in an Active Directory infrastructure. Each role can appear in only one domain controller in a domain. Some of these roles are focused on more processing power, and other roles are more concerned about the uptime. Therefore, in general, FSMO roles should be running on the most reliable domain controllers in the infrastructure. If the allocated resources are not enough for the FSMO role operations or if the servers have reliability issues, it will be necessary to move on to another host. This happens mainly when these roles are running on physical servers. If it's a virtual server, it will just be a matter of increasing the allocated resources. Some businesses also have infrastructure refreshment plans, which will kick off every 3 or 5 years. In such situations, the FSMO roles will need to move into the new hardware.

Let's look at how we can transfer the FSMO roles.

Before we start, we need to check the current FSMO role holder. This can be done by running the following command:

netdom query fsmo

In the infrastructure, there is a new domain controller added with the name REBEL-SDC02, and I'd like to move the domain-wide FSMO roles, which are the PDC, RID, and infrastructure roles, to the new server:

Move-ADDirectoryServerOperationMasterRole -Identity REBEL-SDC02 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster

Once the move is completed, we can check the role owners again:

Figure 5.6: Migrating the selected number of FSMO roles

If we need to move all five FSMO roles to a new host, we can use the following command:

Move-ADDirectoryServerOperationMasterRole -Identity REBEL-SDC02 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

The following screenshot shows the output for the netdom query fsmo command:

Figure 5.7: Migrating FSMO roles

If we need to move a single FSMO role, the Move-ADDirectoryServerOperationMasterRole command can be used with the individual role.

Once the transfer is completed, the system will create an event in the event viewer under the directory service log with the event ID 1458.

Seizing FSMO roles

In the previous section, I explained how to transfer FSMO roles from one domain controller to another. But there are certain situations where we will not be able to transfer the FSMO roles, such as the following:

• Hardware failures: If the domain controller that holds the FSMO roles failed due to hardware issues and there is no other way to bring it back online using a backup/DR solution, we need to use the seize method to recover FSMO roles
• System operation issues: If the domain controller has issues, such as operating system corruption, viruses, malware, or file corruption, it may not be allowed to transfer the FSMO role to another domain controller, which will also lead to an FSMO role seize
• Forcefully removed domain controller: If the FSMO role holder is forcefully decommissioned using the /forceremoval command, we need to use the seize method from any other available domain controller to recover FSMO roles

The FSMO role seize process should be used only in a disaster where you cannot recover the FSMO role holder. Some of the FSMO roles (RID, domain-naming master, and schema master) can still afford a few hours of downtime with minimum business impact. Therefore, we do not use the seize option as the first option if the FSMO role holder can still be recovered or fixed.

Once the seize process is completed, the old FSMO role holder should not be brought online again. It is recommended that you format and remove it from the network. At any given time, it is not possible to have the same FSMO role appear in two servers on the same domain.

In the following example, there are two domain controllers in the infrastructure. REBEL-SDC02 is the FSMO role holder and REBEL-PDC-01 is the additional domain controller. Due to hardware failure, I cannot bring REBEL-SDC02 online and I need to seize the FSMO roles:

Figure 5.8: Domain controller ping test

In order to seize the roles, the following command can be used:

Move-ADDirectoryServerOperationMasterRole -Identity REBEL-PDC-01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force

This command will take a few minutes to complete in the background, as it will try to connect to the original FSMO role holder first.

The only change in the command from the FSMO role transfer is the -Force parameter at the end. Otherwise, it's the exact same command. You also can seize the individual role using Move-ADDirectoryServerOperationMasterRole -Identity REBEL-PDC-01 -OperationMasterRole <FSMO Role> -Force.

<FSMO Role> can be replaced with the actual FSMO role value.

Once the command is completed, we can check the status of the new FSMO role holder:

Figure 5.9: Seizing FSMO roles

As we can see, REBEL-PDC-01 becomes the new FSMO role holder.

Summary

This is the end of another Active Directory infrastructure design chapter that was focused on FSMO role placements. FSMO roles are designated to do specific tasks in an Active Directory infrastructure in order to maintain integrity. In this chapter, you learned about FSMO roles and their responsibilities. Then, we moved on to FSMO role placement in the infrastructure, where you learned about techniques and best practices that need to be followed in order to maintain the best performance and availability. After that, we looked at how to transfer the FSMO roles from one domain controller to another using PowerShell, followed by a guide for seizing FSMO roles in the event of a disaster where you cannot recover the original FSMO role holder.

In the next chapter, we will look at actual Active Directory deployment scenarios and explore how to migrate from older versions of Active Directory to AD DS 2022.