Q: What are the Windows Operations Master roles that are assigned to Windows Active Directory (AD) domain controllers (DCs)? What Operations Master roles perform security-related functions?

A: DCs can have special roles in a Windows AD domain or forest. In Windows Server 2003 these roles are called Operations Master roles; in Windows 2000 they were referred to as Flexible Single Master of Operations (FSMO) roles. Operations Master roles exist because some of the AD services must operate in a single-master modeā€”even though the bulk of the AD services (e.g., the AD data replication service) are built on a multi-master model.

Win2K and later server OSs support five Operations Master roles: Schema Master and Domain Naming Master (per Windows forest each of these roles can be assigned only to a single DC), PDC Emulator, Relative ID (RID) Master, and Infrastructure Master (Each of these roles must be assigned to one DC for each individual AD domain). A good tool to manage and control Operations Master roles on Windows DCs (e.g., to transfer and seize roles between different DCs) is the ntdsutil.exe command-line tool.

The PDC Emulator, RID Master, and Infrastructure Master roles are security-related Operations Master roles. I explain these three security-related Operations Master roles below.

Each AD domain has a single DC that's assigned the PDC Emulator role. The PDC Emulator role can be hosted on either a DC or a Global Catalog (GC) DC. The PDC Emulator role provides various features, the most obvious one being backward compatibility for downlevel clients and servers in the following ways:

  • It provides down-level client support for password updates.
  • It performs replication to down-level (Windows NT 4.0) backup DCs.
  • It acts as the Master Domain Browser, if the NT 4.0 Browser service is enabled.
The PDC Emulator also plays an important role regarding its peer DCs: A DC always attempts to replicate password changes to the PDC Emulator first. Each time a DC fails to authenticate a password, it contacts the PDC Emulator to see whether the password can be authenticated there, perhaps as a result of a change that hasn't yet been replicated down to the particular DC. The PDC Emulator also performs the following roles:

  • Domain functional level increases
  • Time synchronization
  • Distributed account lockout
  • Maintenance and coordination of shared secrets between trusted and trusting domains
  • Preferred DC for Group Policy updates
  • Default DC for updates of domain-based DFS metadata
Each AD domain has one DC that's assigned the RID Master role. The RID Master allocates a pool of RIDs for each of the DCs and keeps track of the sets of allocated RIDs. When a Windows account is created, it receives a domainwide Security ID (SID). A part of the SID is a domain-wide unique RID. The RID master can be hosted on either a DC or a GC.

Each AD domain has a single DC that is assigned the Infrastructure Master role. The DC holding the Infrastructure Master role is responsible for updating the SIDs and DNs in cross-domain object references for objects in the domain. When an AD object from another domain in the same AD forest is referenced (e.g., by making a user from one domain a member of a domain local group in another domain), DCs that aren't GCs create a phantom object in the domain database to allow this reference to occur in the AD database tables. The reference contains the GUID, the SID, and the distinguished name (DN) of the object. If the referenced object moves, the following will happen:

  • The object GUID doesn't change.
  • The Infrastructure Master will change the object SID if the move is cross-domain.
  • The Infrastructure Master will change the object DN.
The Infrastructure Master role should be located on a DC (this is a non-GC server). If all DCs in a domain are GCs, it doesn't matter which DC holds the Infrastructure Master role as there will be no phantom AD objects that need updating (since every GC will hold a real reference to all objects in the forest in its AD database).