Flexible Single-Master Operations (FSMO) Roles

From SambaWiki


Multi-Master Model

Active Directory was designed as a multi-master enabled database. The great advantage is, that changes are possible on every DC. But it also carries the responsibility, to handle possible conflicts. One way to handle conflicts is, that the latest write procedure win, while earlier ones are discarded.

But there are cases, where it is necessary to avoid such conflicts. Imagine a network, with DCs in different locations and the network connections gets temporarily disconnected. If during this split a new security object, like an user account will be created in both locations, they may get the same RID, which is part of the objects SID. But the SID is used everywhere to reference to this object, like in ACLs. Duplicate SIDs would cause serious trouble right up to security vulnerabilities. This is just one situation, where it's necessary to avoid the occurance of conflicts, than resolving them afterwards.

Single-Master Model

In an NT4-domain, there was just one master responsible for all changes: The PDC. Changes done on the PDC were replicated to all BDCs.

In an Active Directory, some updates are performed in a single-master fashion, too. This means that they are done always on one special DC and then replicated to all other. Active Directory uses roles, that are assigned to DC(s), for these special tasks. Because this single-master roles are not tied to one DC, they are named Flexible Single Master Operation (FSMO) roles.

Active Directory knows seven FSMO roles with different scopes:

  • PDC Emulator (One per domain)
  • RID Master (One per domain)
  • Schema Master (One per forest)
  • Domain Naming Master (One per forest)
  • Infrastructure Master (One per domain)
  • Domain DNS Zone Master role (one per domain)
  • Forest DNS Zone Master role (one per forest)

The seven FSMO roles

In the following, we describe the FSMO roles, their functions and availability requirements. This allows to deduce the consequences, when the DC owning this role, is offline.

PDC Emulator

The holder of the PDC Emulator role is responsible for the following tasks within a domain where it is authorative for:

  • Provide time service. An accurate time syncronisation is necessary for Kerberos authentication. Per default, all Windows clients in a domain retrieve their time from the DC owning the PDC Emulator role in their domain. In a multi-domain environment, each PDC Emulator in a domain syncronizes its time with the PDC Emulator at the root of the AD forest. The root PDC Emulator is configured to gather the time from an external source. Windows DCs automatically follow this hierarchy, while Samba DCs ntpd must be configured accordingly.
  • Password changes performed by other DCs in a domain are replicated preferentially to the PDC Emulator.
  • All functionality provided by an NT4-style PDC, is handled by the PDC Emulator. Nevertheless, an AD DC owning this role, is something completely different than an NT4-style PDC! Windows 2000 or later clients don't use that functions.
  • Account lockouts are processed by the PDC Emulator.
  • Authentication failures on any DC in a domain caused of a wrong password are forwarded to the PDC emulator, before the password failure message is reported to the user.
  • The Group Policy Management Console contact the DC owning this rule per default.

In large environments, the DC owning the PDC Emulator role, can have high CPU utilization because of pass-thru authentication, password changes and time sycronisation.

There is one PDC Emulator per domain.

This DC should, if possible, be available all the time, because an accurate time on all machines in a domain is required for Kerberos. If your clients are configured to use a different time source and you don't have pre-Windows 2000 clients, then the temporary absence may be less critical.

RID Master

The RID Master role owner is responsible for answering RID pool requests from all DC within a domain. It is also responsible for moving objects into another domain and removing them from a domain.

All security objects like e. g. user/machine accounts and groups are identified by an SID. The objects SID containts the domain SID, which is equal for all objects within a domain, and an RID, that is unique in a domain.

To allow security objects to be created on all DCs, each contain a so-called RID pool. This is a range of, per default, 500 domain-wide unique RIDs, assigned from the RID Master to each DC. If a security object is created on a DC, then the RID is taken from this pool, to ensure, that it's unique in the domain. If the threshold falls below 50%, then the DC send a RID pool request to the RID Master. This assignes unallocated RIDs and responds them to the requesting DC.

There is one RID Master per domain.

This DC must be online when a new DC is promoted in a domain, to assign a RID pool. Also it must be available, when existing DCs update their standby RID pool.

On the other side, if the RID Master is offline, then it's only possible to create new security objects on each DC, until it's local RID pool is empty. If the RID pools on all DC gets empty, then no further objects can be created. Also it's not possible to join additional DCs while the RID Master of a domain is offline.

Schema Master

The DC holding the role Schema Master is the only one in an Active Directory forest, that is allowed to update the directory schema. Once the update is completed, the changes are replicated to all other DCs in the forest.

The schema partition, which is existing on all DCs, is named „schema naming context“ and located in CN=schema,CN=configuration,DC=<domain>. Updates are done only on the Schema Master.

There is one Schema Master per forest.

This DC must be online when schema updates are performed.

Domain Naming Master

The holder of this role is the only DC, that is responsible for changes in the forest-wide domain name space. This means that this DC is the only one which can add or remove a domain, trusts to external directories and application partitions to/from the forest.

The domain naming information are stored in the partition „Configuration Naming Context“ in CN=Partitions,CN=Configuration,DC=<domain>. This partition exists on all DCs, but is only updated on the Domain Naming Master.

There is one Domain Naming Master per forest.

This DC must be online when trusts are established with external directories and domains and application partitions are added/removed to/from the forest.

Infrastructure Master

The DC owning the Infrastructure Master role is responsible for updating objects SID and Distinguished Names in a cross-domain object reference. This is used for example, if a user from one domain is added to a security group of a different domain.

There is one Infrastructure Master per domain.

Even if a Infrastructe Master is irrelevant in a forest with just one domain, the role exists. If this DC is temporary offline, then cross-domain changes aren't possible.

Domain DNS Zone Master

The DC owning the Domain DNS Zone Master role is responsible for coordinating the adding or deleting of any AD-integrated DNS zones on the DCs with DNS servers that host the domain.

There is one Domain DNS Zone Master per domain.

Forest DNS Zone Master

The DC owning the Forest DNS Zone Master role is responsible for coordinating the adding or deleting of the forest-wide records on the DNS servers that host the top-level DNS zone. These records contain the names of the Global Catalog (GC) servers.

There is one Forest DNS Zone Master per forest.

Difference of transfering and seizing FSMO roles

Whenever it's possible, you should transfer FSMO roles and do not seize them! Transfering is the recommended and cleaner way. But it requires that the DC, which is currently owning the role you want to transfer, is still working and connected to the network. Transfering makes the old DC know, that he's not owning the role(s) any more.

If the DC is broken (e. g. hardware defect) and surely will never come back, then you seize the role on a remaining DC. But it's very important, that the old DC will really never be connected to the network again, as it may cause conflicts and lead into an inconsitent AD, because the old DC did not notice the change and still feels responsible for tasks related to the role.

How to handle situations where a DC with FSMO roles is offline

There are three situations to distinguish:

1. The downtime is planed and the DC comes back soon (reboot, hardware replacement, etc.):

In this case, you have to decited, if you temporary transfer the roles to a different DC or avouch that you know the effects during the downtime. See The seven FSMO roles.

2. The DC should be demoted:

Transfer the roles to a different DC, before you demote.

3. The DC is offline caused by a problem:

1. Don't panic!
2. Depending on the kind of role(s) that was/were on the DC, the consequences may be different. Make sure, that you find out which roles are affected and what it means for your forest. See The seven FSMO roles.
3. Try repairing the broken DC and connect it to the network again. But never restore it from a backup, if at least one DC in the domain is still working. The replication could mix up your directory!
4. If there is no chance to get the DC back again, seize the roles on a remaining DC and demote the broken one.

FSMO role management using samba-tool

Show current FSMO role owners

On a Domain Controller of your choice, run the following command, to print the owner of the different FSMO roles:

# samba-tool fsmo show
InfrastructureMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
RidAllocationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
DomainNamingMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
SchemaMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com

Unfortunately samba-tool only shows five of the fsmo roles and that these five roles are owned by DC1 at the moment.

To see all the fsmo roleowners, you will need to do something like this:

ldbsearch --cross-ncs -H /var/lib/samba/private/sam.ldb '(fsmoroleowner=*)' | grep 'dn:' | sed 's|dn: ||'

This should produce a list of where the role owners are stored:

CN=RID Manager$,CN=System,DC=samdom,DC=example,DC=com

To find out the fsmo role owner for a specific dn, you will need to do something like this:

ldbsearch --cross-ncs -H /var/lib/samba/private/sam.ldb -b "CN=Infrastructure,DC=DomainDnsZones,DC=samdom,DC=example,DC=com" \
-s base fsmoroleowner

Which should produce something similar to this:

# record 1
dn: CN=Infrastructure,DC=DomainDnsZones,DC=samdom,DC=example,DC=com
fSMORoleOwner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com

Transfering a FSMO role

  • Log on to the DC, that should be the new owner of the role you want to transfer.
  • Transfer the role to the DC, by executing the following command:
# samba-tool fsmo transfer --role=...
FSMO transfer of '...' role successful
  • Ensure that the role was transfered ('samba-tool fsmo show').

Note: samba-tool has a bug, that prevents a successful transfer of roles, even if „samba-tool fsmo show“ prints that the roles are transfered to the new host. See Bug #10734, to see if it is fixed in the version you're running.

Seizing a FSMO role

  • Log on to the DC, that should be the new owner of the role you want to transfer.
  • Seize the role to the current DC, by executing the folloging command:
# samba-tool fsmo seize --role=...
Attempting transfer...
Transfer unsuccessful, seizing...
FSMO seize of '...' role successful
  • Ensure that the role was transfered ('samba-tool fsmo show').
  • Make sure, that the old DC will never be connected to the network again!

Note: samba-tool has a bug, that prevents the seizure of the Domain Naming Master role. See Bug #10924. If you encounter this problem in your version, consider adding the „--force“ parameter, to workaround this issue.

FSMO role management using the Windows GUI

See https://support.microsoft.com/kb/255690/en