Operations master roles {FSMO Roles}

Operations master roles
Active Directory supports multimaster replication of the directory data store between all domain controllers in the domain, so all domain controllers in a domain are essentially peers. However, some changes are impractical to perform in using multimaster replication, so, for each of these types of changes, one domain controller, called the operations master, accepts requests for such changes.
In every forest, there are at least five operations master roles that are assigned to one or more domain controllers. Forest-wide operations master roles must appear only once in every forest. Domain-wide operations master roles must appear once in every domain in the forest.
Note
•
The operations master roles are sometimes called flexible single master operations (FSMO) roles.


Forest-wide operations master roles
Every forest must have the following roles:

•Schema master
•Domain naming master

These roles must be unique in the forest. This means that throughout the entire forest there can be only one schema master and one domain naming master.


Schema master
The schema master domain controller controls all updates and modifications to the schema. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the entire forest.

Domain naming master
The domain controller holding the domain naming master role controls the addition or removal of domains in the forest. There can be only one domain naming master in the entire forest.

Note:
Any domain controller running Windows Server 2003 can hold the role of the domain naming master. A domain controller running Windows 2000 Server that holds the role of domain naming master must also be enabled as a global catalog server.

Domain-wide operations master roles
Every domain in the forest must have the following roles:

•Relative ID (RID) master
•Primary domain controller (PDC) emulator master
•Infrastructure master

These roles must be unique in each domain. This means that each domain in the forest can have only one RID master, PDC emulator master, and infrastructure master.

RID master
The RID master allocates sequences of relative IDs (RIDs) to each of the various domain controllers in its domain. At any time, there can be only one domain controller acting as the RID master in each domain in the forest.
Whenever a domain controller creates a user, group, or computer object, it assigns the object a unique security ID (SID). The SID consists of a domain SID, which is the same for all SIDs created in the domain, and a RID, which is unique for each SID created in the domain.
To move an object between domains (using Movetree.exe), you must initiate the move on the domain controller acting as the RID master of the domain that currently contains the object.


PDC emulator master
If the domain contains computers operating without Windows 2000 or Windows XP Professional client software or if it contains Windows NT backup domain controllers (BDCs), the PDC emulator master acts as a Windows NT primary domain controller. It processes password changes from clients and replicates updates to the BDCs. At any time, there can be only one domain controller acting as the PDC emulator master in each domain in the forest.

By default, the PDC emulator master is also responsible for synchronizing the time on all domain controllers throughout the domain. The PDC emulator of a domain gets its clock set to the clock on an arbitrary domain controller in the parent domain. The PDC emulator in the parent domain should be configured to synchronize with an external time source. You can synchronize the time on the PDC emulator with an external server by executing the "net time" command with the following syntax:

net time \\ServerName/setsntp:TimeSource

The end result is that the time of all computers running Windows Server 2003 or Windows 2000 in the entire forest are within seconds of each other.

The PDC emulator receives preferential replication of password changes performed by other domain controllers in the domain. If a password was recently changed, that change takes time to replicate to every domain controller in the domain. If a logon authentication fails at another domain controller due to a bad password, that domain controller will forward the authentication request to the PDC emulator before rejecting the log on attempt.

The domain controller configured with the PDC emulator role supports two authentication protocols:
•the Kerberos V5 protocol
•the NTLM protocol

Infrastructure master
At any time, there can be only one domain controller acting as the infrastructure master in each domain. The infrastructure master is responsible for updating references from objects in its domain to objects in other domains. The infrastructure master compares its data with that of a global catalog. Global catalogs receive regular updates for objects in all domains through replication, so the global catalog data will always be up to date. If the infrastructure master finds data that is out of date, it requests the updated data from a global catalog. The infrastructure master then replicates that updated data to the other domain controllers in the domain.
Important

•Unless there is only one domain controller in the domain, the infrastructure master role should not be assigned to the domain controller that is hosting the global catalog. If the infrastructure master and global catalog are on the same domain controller, the infrastructure master will not function. The infrastructure master will never find data that is out of date, so it will never replicate any changes to the other domain controllers in the domain.

In the case where all of the domain controllers in a domain are also hosting the global catalog, all of the domain controllers will have the current data and it does not matter which domain controller holds the infrastructure master role.

The infrastructure master is also responsible for updating the group-to-user references whenever the members of groups are renamed or changed. When you rename or move a member of a group (and that member resides in a different domain from the group), the group may temporarily appear not to contain that member. The infrastructure master of the group's domain is responsible for updating the group so it knows the new name or location of the member. This prevents the loss of group memberships associated with a user account when the user account is renamed or moved. The infrastructure master distributes the update via multimaster replication.

There is no compromise to security during the time between the member rename and the group update. Only an administrator looking at that particular group membership would notice the temporary inconsistency.