Transferring and Seizing FSMO Roles

2019-10-11 about 1090 words 6 min

Contents

Introduction

Within a Active Directory environment there are 5 Flexible single master operation (FSMO) roles that are present, they can either all be on a single domain controller or can be distributed between multiple. There are 2 FSMO roles that are forest wide and 3 that are domain wide.

This post will describe the steps taken in order to either transfer a FSMO role to another server, or seize a FSMO role.

FSMO roles are transferred when an administrator wants the FSMO role to be present on a different domain controller, and the domain controller from which the FSMO role is being transferred from is operational.

FSMO roles are seized when the domain controller on which the FSMO role used to be on is no long operational, this process will allow the FSMO role to be restored on a different domain controller that is operational.

Schema Master (Forest Wide)

The schema master is responsible for performing schema updates to the forest, once the schema is updated on the schema master it will be replicated to all the other domain controllers.

The schema is not something that is updated very frequently, it may be altered when something such as Exchange is installed. As a result if the schema master goes down it will not be an issue unless the schema needs to be altered.

Domain Naming Master (Forest Wide)

The domain naming master is responsible for processing any changes to the domains within the forest. For example, if a domain is created, renamed, or removed it will be processed through the domain controller with the domain naming master FSMO role.

This FSMO role is only needed when performing actions related to domains, in the case where it is down and nothing needs to be done with the domains it will not be an issue.

Relative ID (RID) Master (Domain Wide)

Every user, computer, and service account in active directory is given a security identifer (SID). A SID usually looks like the following:

1

S-1-5-21-2985903027-398661703-2424895149-2103

The last four numbers, 2103 uniquely identify a security principle in the domain. So when a check is being made whether a user is apart of a specific security group the SID is used.

Every domain controller has a RID pool available to them locally that they use when a new user, computer, or service account is created. When this pool drops lower than 50% the domain controller will contact the RID master in order to request more.

The RID master is a pretty important role, however, if it goes down it will not show its effects immediately. If it is down and a lot of accounts are being created there is a chance that a domain controller will run out of RIDs and will not be able to request more.

This means that if the RID master goes down it must be brought up before making many changes that require new RIDs.

Primary Domain Controller (PDC) Emulator (Domain Wide)

One of the most important functions of the PDC is its ability to manage the latest password of a user. For example, if a user changes their password it may not be replicated to all the domain controllers. If a domain controller fails to validate a password it will perform the same check on the PDC in order to verify if the password is indeed invalid or the regular domain controller did not have an updated list. This process is called PDC chaining.

Furthermore, the PDC also acts as the main source of time within a domain and provides backward compatibility features as a Windows NT primary domain controller.

If the PDC is down there may be issues with time synchronization and the PDC chaining cycle will not be able to be completed.

Infrastructure master (Domain Wide)

The infrastructure master comes into play when groups from one domain are used in another. For example, if a user in Domain A is a member of a group in Domain B the infrastructure master will be responsible for keeping track of the group located in the foreign domain. In general the infrastructure master keeps track of objects located in other domains, which are usually called phantoms.

In a single domain environment if the infrastructure master goes down it will have no effect. In a environment where it is needed to keep track of phantoms there may be issues with group memberships being incomplete in the case where this FSMO role goes down.

Seizing FSMO Roles

Before performing the seizer of a FSMO role list them using the netdom, as can be seen below all the FSMO roles are on dc1.test.net. We will assume that dc1.test.net has disappeared and cannot be restored, now we must transfer these FSMO roles onto dc2.test.net.

Begin the process by running ntdsutil. This can be launched on any computer, it does not matter if it is done on a domain controller or workstation. However, proper administrative credentials are needed.

After launching ntdsutil run the following commands.

Run roles:

1

C:\Windows\system32\Ntdsutil.exe: roles

Run connection:

1

fsmo maintenance: connection

Run connect to server TARGET_DC_HOST, where TARGET_DC_HOST is the domain controller on which you want the FSMO role to be transfered to.

1
2
3


server connections: connect to server dc2.test.net
Binding to dc2.test.net ...
Connected to dc2.test.net using credentials of locally logged on user.

Run quit:

1

server connections: quit

Now the FSMO roles can be seized. From the list below run the commands that are needed in order to transfer the FSMO roles you require.

1
2
3
4
5


fsmo maintenance: seize pdc
fsmo maintenance: seize infrastructure master
fsmo maintenance: seize rid master
fsmo maintenance: seize naming master
fsmo maintenance: seize schema master

In order to confirm that the seizer was successfully use netdom to check where the FSMO roles are located, as can be seen below they are all on dc2.test.net.

Transferring FSMO Roles

In the case where a FSMO role is being transferred from a domain controller that is operational a seizer does not have to be made. In this case the Move-ADDirectoryServerOperationMasterRole PowerShell command can be used.

The following shows all the FSMO roles being transferred onto the domain controller dc1.test.net.

In order to confirm that the transfer was successfully use netdom to check where the FSMO roles are located, as can be seen below they are all on dc1.test.net.