INFO: FSMO (Flexible Single-Master Operation) Roles

This article discusses and explains the five flexible single-master operation roles of a Domain Controller. This article will also briefly discuss the placement of these roles and will also, where applicable, provide links to Microsoft knowledgebase documents.

What is a flexible single-master operation role?

There are certain situations whereby the Active Directory has to use a single-master approach, because the multi-master approach would either cause conflicts, or be almost impossible to implement.

The situations are administered by Domain Controllers with special roles, called Flexible Single-Master Operation (FSMO) roles. There are five roles in total: two are forest wide and the other three are domain wide.

There's a simple formula for calculating how many role holders exist in ones forest:

Number of roles = 2 + (3 x number of domains in the forest)

These roles are assigned to the first Domain Controller in the forest (hence the name of the forest root controller) by default. However, they can be moved which means that any given Domain Controller can contain 0 - 5 roles at any time.

What are these roles?

The five FSMO roles are:

Schema
Domain Naming
PDC
RID
Infrastructure.

The Schema and Domain Naming are the forest-wide roles; the PDC, RID and Infrastructure are the domain specific roles.

The remainder of this article explains the roles and discusses the placement of these roles.

Schema master

The Active Directory is a database. A database is defined by what is called its schema. The basic (base) Active Directory schema consists of 863 properties. If you need to make changes to any of these properties, or you wish to extend the schema, you make all changes to the domain controller that holds the schema master role. Once the schema master changes the Active Directory schema, these changes are replicated to all Domain Controllers (forest wide).

You have to be a member of Schema Admins to be able to modify the Active Directory schema. The Enterprise Admins group is, by default, a member of the Schema Admins group.

An example of extending the Active Directory schema can be found with the installation of Exchange 2000 and/ or ISA Server 2000 (Enterprise Ed.). For example, exchange adds the mailbox property to users.

Domain naming master

The domain naming master performs the forest wide changes to the Directory Name Space (the partitions\configuration naming context) of adding a domain to the forest; removing a domain from the forest; and adding or removing a cross-reference to a domain in an external directory.

In a Windows Server 2003 Active Directory, the domain naming master is also responsible for renaming a domain; a new feature in Server 2003 that cannot be achieved in a Windows 2000 Active Directory.

PDC emulator

The PDC emulator has functions for both native Windows 2000 domains and mixed mode domains; that is, even in a pure Windows 2000 environment, the PDCe has specific roles.

Mixed mode

As the name describes, the PDC emulator emulates the PDC for down level clients. BDCs pull their read-only copies of the domain configuration from the PDCe; the Browser Service requires the PDCe as the PDC is the domain master browser.

Native Mode

The PDC emulator is the authoritative, trusted time source in any domain, and the authoritative time source for the forest. Time that is synchronised from the PDC is considered accurate. Domain Controllers synchronise with the PDC in their domain. PDC emulators synchronise with PDC emulators in parent domains, etc.

The PDC Emulator in the forest root domain is the authorative time source for the forest. The PDC Emulator in each domain is considered a reliable time source, and other DCs and member servers will synchronise time with it. As a security measure against delegated users modifying the permissions on administrative user objects, the PDC Emulator runs a thread that resets the security on all members of protected groups to that of the adminSDHolder object every sixty minutes. For more information on this process, the adminSDHolder object and protected groups, please refer to the following article

Protected groups and the adminSDHolder object

The PDC Emulator is the ultimate authority for passwords in its domain. The PDC Emulator performs two roles with regards to passwords:

Password changes are automatically ‘replicated' to the PDC Emulator via a one-off RPC call over the NETLOGON secure channel. This is different to urgent replication, which only occurs with intrasite replication, and still obeys site-link replication schedules. Password changes are always pushed to the PDC Emulator regardless of replication schedule. This is so that authentication doesn't suffer as a result of a password change.
Because password changes are always replicated to the PDC Emulator, other DCs can hold an out-of-date password for a user at any given time. Therefore when a user logs on and provides a password that is different to what the authenticating DC holds, that request is forwarded onto the PDC Emulator. The PDC Emulator always holds the most up-to-date password, therefore is authorative in the case whereby a user enters an incorrect password.

An example of why the PDC Emulator has this authority

A user at a remote site changes her password before leaving the office. An hour later, the user dials in because she's been phoned and told to look at her urgent e-mail from the boss. The RAS server is located at the central site. When the user authenticates with a DC at the central site she inputs her new password. Because the password was changed at the remote site, which has the default intersite replication schedule of three hours, the authenticating DC in question doesn't hold the new password. Without the PDC Emulator being the password authority, the user's logon would fail and she wouldn't be able to see the urgent e-mail from her boss -which could lead to a drive back into the office. Urgent replication triggers wouldn't help in this scenario as they don't cross site boundaries by default (see the msresource.net tip: how to enable intersite change notifications, for information on how you can actually enable change notifications to cross site boundaries). However, due to the way the PDC Emulator has been implemented, in this scenario the DC in question would query the password with the PDC Emulator, and if the PDC Emulator OKs this password, the DC would process the logon and then replicate the new password from the PDC Emulator.

Note. This behaviour can be disabled on a per-DC basis if you so wish. Please refer to the following msresource.net knowledgebase article:

How to disable NETLOGON from pushing password changes to the PDC

Additional little known functions of the PDCe

The PDCe is responsible for managing well-known security principals, which is why it is recommended that the PDCe role resides on a 2003 DC in a mixed-mode domain.
When establishing an external trust with an NT 4 domain, the PDC Emulator is always used to create the necessary objects in the directory.
By default, all GPOs are created and edited on the PDCe.

The PDCe is also needed when changing the domain functional level.

The PDCe also plays an important part in domain-based DFS roots.

Account lockouts are processed by the PDCe. This way there is no delay with the settings of lockouts and any subsequent releases.

RID master

Every security principle in a domain has a unique ID called a SID. The SID is made up of a domain part (which is the same for all SIDs created in a domain) and a unique relative ID (RID). The RID master allocates Domain Controllers with a Pool of RIDs to enable the multi-master model to work.

A Domain Controller is allocated an initial pool of 500 RIDs. Originally, in the Windows 2000 realease, when a Domain Controllers RID pool falls below 100 (20%), the Domain Controller sends a request to the RID master for additional RIDs; the RID master will then allocate a further 500 RIDs. However, Service Pack 4 changed this behaviour to 250 (50%) RIDs.

Note. The new default renewal threshold (introduced in Windows 2000 SP4) is 50% (250). kb316201 mentions this change

The RID master is also responsible for moving objects between domains. The RID master removes the object from the first domain and creates it in the second. The RID master disallows the illegal situation of having two objects (duplicate GUIDs) in the same forest. It is because of this that you have to perform cross domain moves using the movetree.exe command on the RID master (or at least, you have to be able to contact the RID master for this to work).

However, there can be a security issue with restoring an old RID master that will affect this. Therefore the RID master DC won't start unless it can replicate (to get the latest RID pool status).

Infrastructure master

The infrastructure keeps track of local (to its domain) phantoms, and modifies their DN, and where applicable, SIDs if they change.

When objects reference objects that reside in other domains a special record called a phantom is used to represent the referenced object. A phantom consists of the object's GUID, the object's DN, and if the object is a security principle its SID as well. The DN and SID will change if the object moves or is renamed. The infrastructure master role holder keeps track of these phantoms so that external (to the domain) objects can be referenced and used. The IM is responsible for updating the phantoms after they are moved or renamed and notifying the other DCs. It does this by periodically checking its directory database and checking objects that are not in its domain against those referenced by a GC.

If a security group contained users from another domain, and some of those users were moved from one OU to another, those user's DNs would change. The IM would therefore realise this and update the phantom accordingly.

A DC that holds the role of a GC does not require the use of phantoms as a GC holds a partial replica of every object in the forest. Only non-GC Domain Controllers need to be updated by the IM. For information on the infrastructure master - Global Catalog server conflict, please see the following msresource.net knowledgebase article.

When, and when not, to make the Infrastructure Master (FSMO role) a Global Catalog Server

FSMO Placement Recommendations

Generally the roles can stay in the default location of the first DC in the domain. Only a very heavy load necessitates moving these roles to other DCs, and then it is recommended that only the PDCe and RID master are moved; the other three suffer very little to zero load.

The IM role holder must not reside on a DC that holds the role of Global Catalog if the following conditions are both true:

here are multiple domains in the forest; and
Not all Domain Controllers in the domain hold the role of Global Catalog servers

The IM is defunct in a single domain environment. The IM also serves no purpose, and indeed does not function, in an environment whereby all DCs in the same domain as the IM are GCs.

It is recommended that you designate (in your documentation, there is not feature to do this) standby FSMO role holders in the event of a failure.

However, since the release of Windows 2003 Server, there's a new addition to the placement recommendations. The PDCe needs to sit on 2003 box. This is because of the new Well Known Security principals introduced by Windows Server 2003.

For more information, please refer to kb827016 for more info.

Summary

There are five FSMO roles: Schema, Domain Naming, PDC, RID and Infrastructure. There are a minimum of five FSMO roles held in a forest at any one time. These roles perform certain features that necessitate an authority, so that multi-master replication can work.

Two of the roles are forest wide; the other three are specific to each domain. The PDC and then RID master roles receive the most traffic, and should therefore possibly be moved onto alternate (higher spec) DCs in very busy environments. The two forest-wide roles (schema and domain naming) have zero loads, and can always be left where they are.

In a multi-domain forest where not all DCs hold the role of GC, the IM role holder must reside on a non-GC DC. If all DCs are GCs, or there is only one domain, this rule is void, as the IM is not used.

Document information

Author: Paul Williams
Date: 25-06-2004
Version: 2.0
Last updated: 01-08-2007
Last updated by: Paul Williams