Single master operations

Active Directory supports multimaster replication of the directory data store between all domain controllers in the domain. Some changes are impractical to perform in multimaster fashion, however, so only one domain controller, called the operations master, accepts requests for such changes.

Because the operations master roles can be moved to other domain controllers within the domain or forest, these roles are sometimes referred to as flexible single master operations.

In any Active Directory forest, there are five operations master roles that are assigned to one or more domain controllers. Some roles must appear in every forest. Other roles must appear in every domain in the forest.

Forest-wide operations master roles

Every Active Directory 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. At any time, 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 at any time.

Domain-wide operations master roles

Every domain in the forest must have the following roles:

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

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

Relative ID master

The relative ID master allocates sequences of relative IDs to each of the various domain controllers in its domain. At any time, there can be only one domain controller acting as the relative ID 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. The security ID consists of a domain security ID (that is the same for all security IDs created in the domain), and a relative ID that is unique for each security ID 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 relative ID master of the domain that currently contains the object.

PDC emulator

If the domain contains computers operating without Windows 2000 client software or if it contains Windows NT backup domain controllers (BDCs), the PDC emulator 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 in each domain in the forest.

In a Windows 2000 domain operating in native-mode, 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.

Infrastructure master

The infrastructure master is responsible for updating the group-to-user references whenever the members of groups are renamed or changed. At any time, there can be only one domain controller acting as the infrastructure master in each domain.

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. 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.

For information about where single master operations are installed by default and about how to optimize their placement in your network, see Planning operations master locations For information about transferring operations master roles, see Transferring operations master roles For information about what to do when an operations master fails, see Responding to operations master failures