A multi-master enabled database, such as the Active Directory, provides the flexibility of allowing changes to occur at any DC in the enterprise, but it
also introduces the possibility of conflicts that can potentially lead to problems once the data is replicated to the rest of the enterprise. One way
Windows deals with conflicting updates is by having a conflict resolution algorithm handle discrepancies in values by resolving to the DC to which changes
were written last (that is, "the last writer wins"), while discarding the changes in all other DCs. Although this resolution method may be acceptable in
some cases, there are times when conflicts are just too difficult to resolve using the "last writer wins" approach. In such cases, it is best to prevent
the conflict from occurring rather than to try to resolve it after the fact.
To prevent conflicting updates the Active Directory performs updates to certain objects in a single-master fashion.
In a single-master model, only one DC in the entire directory is allowed to process updates. In a forest, there are five FSMO roles that are assigned to
one or more domain controllers. The five FSMO roles are:
PDC Emulator FSMO Role
The PDC emulator is necessary to synchronize time in an enterprise. Windows includes the W32Time (Windows Time) time service that is required by the
Kerberos authentication protocol. All Windows-based computers within an enterprise use a common time. The purpose of the time service is to ensure that the
Windows Time service uses a hierarchical relationship that controls authority and does not permit loops to ensure appropriate common time usage.
The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the root of the forest becomes authoritative for the enterprise, and
should be configured to gather the time from an external source. All PDC FSMO role holders follow the hierarchy of domains in the selection of them
in-bound time partner.
In a Windows domain, the PDC emulator role holder retains the following functions:
• Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.
• Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator before a bad password
failure message is reported to the user.
• Account lockout is processed on the PDC emulator.
• The PDC emulator performs all of the functionality that a Microsoft Windows NT 4.0 Server-based PDC or earlier PDC performs for Windows NT 4.0-based or
earlier clients.
RID Master FSMO Role
The RID master FSMO role holder is the single DC responsible for processing RID Pool requests from all DCs within a given domain. It is also responsible
for removing an object from its domain and putting it in another domain during an object move.
When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain
SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain.
The RID master gives every DC a pool of 500 RIDs at a time. When a new domain account or group is created, the DC assigns the new account a SID and a RID
that's taken from its local allocated RID pool. When a DC's RID pool begins to run low (Pre–Windows 2000 SP4 20%, Post–Windows 2000 SP4 50%), it
automatically asks the RID master for another block of RIDs. Therefore, a post–Windows 2000 SP4 DC with a default pool size of 500 requests a new pool when
250 RIDs have been consumed. To check the RID allocation with Dcdiag, type the following at a command prompt:
dcdiag.exe /test:ridmanager /v
Infrastructure FSMO Role
When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to
security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is the DC responsible for updating an object's SID and
distinguished name in a cross-domain object reference.
NOTE: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog server(GC). If the Infrastructure Master runs
on a Global Catalog server, it will stop updating object information because it does not contain any references to objects that it does not hold. This is
because a Global Catalog server holds a partial replica of every object in the forest. As a result, cross-domain object references in that domain will not
be updated and a warning to that effect will be logged on that DC's event log.
If all the domain controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is not important which
domain controller holds the infrastructure master role.
When the Recycle Bin optional feature is enabled, every DC is responsible to update its cross-domain object references when the referenced object is moved,
renamed, or deleted. In this case, there are no tasks associated with the Infrastructure FSMO role, and it is not important which domain controller owns
the Infrastructure Master role.
Domain Naming Master FSMO Role
The domain naming master FSMO role holder is the DC responsible for making changes to the forest-wide domain name space of the directory (that is, the
Partitions\Configuration naming context or LDAP://CN=Partitions, CN=Configuration, DC=<domain>). This DC is the only one that can add or remove a
domain from the directory. It can also add or remove cross references to domains in external directories.
Schema Master FSMO Role
The schema master FSMO role holder is the DC responsible for performing updates to the directory schema (that is, the schema naming context or
LDAP://cn=schema,cn=configuration,dc=<domain>). This DC is the only one that can process updates to the directory schema. Once the Schema update is
complete, it is replicated from the schema master to all other DCs in the directory. There is only one schema master per directory.
