FSMO stands for Flexible Single Master Operations, and these roles (also known as operations master roles) help you prevent conflicts in your Active Directory.
In an Active Directory environment, some of your domain controllers (DCs) must be assigned certain special roles for your network to function properly. These special roles are called flexible single master operations (FSMO) roles, and DCs that hold such roles are called FSMO role holders. If you don’t assign these roles properly, bad things can happen, so the focus of this article is on rules for proper placement of FSMO roles on AD-based networks. But before we summarize the rules, let’s briefly review what the different roles are and the consequences when a role fails or isn’t placed properly.
Windows 2000 and later, all use the Multi-Master Model. For most Active Directory objects, the task of updating can be performed by any Domain Controller except those Domain Controllers that are read-only. Things such as computer object properties, renamed organizational units, and user account password resets can be handled by any writable domain controller.
After an object is changed on one domain controller, those changes are propagated to the other domain controllers through replication. During replication all of the Domain Controllers share their updates. So a user that has their password reset in one part of the domain may have to wait until those changes are replicated to the Domain Controller that they are signing in from.
This model works very well for most objects. In the case of any conflicts, such as a user’s password being reset by both the central helpdesk as well as an administrator working at the user’s site, then conflicts are resolved by whichever made the last change. However, there are some changes that are too important, and are not well suited to this model.
Each domain in an AD-based network has three FSMO roles that must be assigned to domain controllers within the domain:
- PDC Emulator. The DC holding this role plays PDC for any legacy Windows NT BDCs you may still have running. But even if you’ve migrated all your legacy DCs and your domains are running in Windows 2000 mixed functional level or higher, the PDC Emulator role is still important because the PDC Emulator enforces account lockout, handles password changes, and synchronizes time for all DCs in the domain.
- RID Master. When an administrator creates a new security principle in Active Directory (typically a new user or group) the SID for the new object is constructed from the domain SID and a relative ID (RID) selected from a pool of RIDs on the domain’s DCs. If this pool starts running low (under 50% remaining) the RID Master replenishes it.
- Infrastructure Master. Ensures cross-domain object references are handled properly, such as when objects in one domain are referenced by objects in a different domain.
The forest root domain also has two additional FSMO roles that must be assigned to domain controllers in that domain:
- Domain Naming Master. Handles changes to the namespace, for example when a new child domain is added to a parent domain.
- Schema Master. Handles changes to the schema and replicates these changes to all other DCs throughout the forest.
There are a number of ways you can determine which DCs are FSMO roles holders on your network, but the simplest is to install the Support Tools from the \Support\Tools folder on your Windows 2003 product CD and type
netdom query fsmo at a command prompt. (Windows 2008 has it built in already)
In a forest, there are five FSMO roles that are assigned to one or more domain controllers. The five FSMO roles are:
The schema master domain controller controls all updates and modifications to the schema. Once the Schema update is complete, it is replicated from the schema master to all other DCs in the directory. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the whole forest.
Domain naming master:
The domain naming master domain controller controls the addition or removal of domains in the forest. 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. There can be only one domain naming master in the whole forest.
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. At any one time, there can be only one domain controller acting as the infrastructure master in each domain.
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.
Relative ID (RID) Master:
The RID master is responsible for processing RID pool requests from all domain controllers in a particular domain. 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. Each DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC’s allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain’s RID master. The domain RID master responds to the request by retrieving RIDs from the domain’s unallocated RID pool and assigns them to the pool of the requesting DC. At any one time, there can be only one domain controller acting as the RID master in the domain.
The PDC emulator is necessary to synchronize time in an enterprise. Windows 200 and later, includes the W32Time (Windows Time) time service that is required by the Kerberos authentication protocol. All Windows based computers within an enterprise will 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 their in-bound time partner.
In a Windows Active Directory 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.
- Editing or creation of Group Policy Objects (GPO) is always done from the GPO copy found in the PDC Emulator’s SYSVOL share, unless configured not to do so by the administrator.
- 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.
This part of the PDC emulator role becomes unnecessary when all workstations, member servers, and domain controllers that are running Windows NT 4.0 or earlier are all upgraded to Windows 2000/2003. The PDC emulator still performs the other functions as described in a Windows Active Directory environment.
At any one time, there can be only one domain controller acting as the PDC emulator master in each domain in the forest.
Here is what you need to know about the different FSMO roles.
• All Schema Changes and Updates to Active Directory are Processed by the DC with the Schema Master Role
Whenever the schema is modified at all, those updates are always completed by the domain controller with the schema master role. Schema is updated during the normal replication, and the schema updates are replicated throughout all the domains in the forest. Since the schema master role is only needed once in the forest, it is kept in the forest root domain. It’s advisable to place the schema master role on the same domain controller (DC) as the primary domain controller (PDC) emulator.
• Changes to Which Domains are Part of the Forest are Processed by the DC with the Domain Naming Master Role
As domains join or leave the forest, the domain naming master makes the updates into active directory. Only this DC actually commits those changes into the directory. The domain naming master also commits the changes to application partitions. Like the schema master role, this role is a forest level FSMO, and it is only needed once across all domains in a forest. Also like the schema master, it is suggested to let this role be handled by the same domain controller – the PDC emulator in the forest root.
• Each Domain in a Forest Translates Names for Other Domains Through Their Infrastructure Master
The infrastructure master is a translator, between globally unique identifiers (GUIDs), security identifiers (SIDs), and distinguished names (DNs) for foreign domain objects. If you’ve ever looked at group memberships of a domain local group which has members from other domains, you can sometimes see those users and groups from the other domain listed only by their SID. The infrastructure master of the domain of which those accounts are in is responsible for translating those from a SID into their name.
Each domain has their own infrastructure master, including the forest root and every child domain. Usually, you do not put the infrastructure master role on a domain that holds the global catalog. However, if you’re in a single domain forest, the infrastructure master has no work to do, since there is no translation of foreign principals. In that case it’s acceptable to place the infrastructure master it on any domain controller (DC), even if it has the global catalog. For a forest with multiple domains, if there’s even one domain controller that doesn’t have the global catalog on it, then you need to put the infrastructure master role on a domain controller that does not have the global catalog.
• The Unique Part of a Security Identifier is Assigned from the Relative ID (RID) Master
One of the first things understood about a security identifier (SID) is that they are unique. There are two parts of a SID: the domain identifier (domain ID), and the relative ID (RID). The domain identifier part of the SID is uniform among all security principals in the domain. When looking at a list of SIDs in a domain, it’s easy to identify the domain SIDs – they all look the same. On the contrary, the relative ID part of the SID is the unique part. The two parts together make up what we commonly identify as a SID.
It is conceivable, then, that if two or more domain controllers were responsible for determining the relative IDs for the SIDs that two domain controllers may come up with the same relative ID for two different objects before they’ve replicated with each other.
That is impossible when only one DC in a domain is responsible for the creation of the relative IDs for SIDs. The relative ID master, or RID master, hands out batches of relative IDs to individual domain controllers, then each domain controller can use their allotment to create new users, groups, and computers. When domain controllers need more relative IDs in reserve, they request them from, and are assigned by, the domain controller with the RID master FSMO role.
Every domain in a forest must have a domain controller with the RID master FSMO role assigned to it. It is recommended that the RID master FSMO role be assigned to whichever domain controller has the PDC emulator FSMO role.
• The Domain Controller (DC) That is the Primary Domain Controller (PDC) Emulator is the Authoritative DC in a Domain
The domain controller that has the PDC emulator FSMO role assigned to it has many duties and responsibilities in the domain. For example, the DC with the PDC emulator role is the DC that updates passwords for users and computers. When a user attempts to login, and enters a bad password, it’s the DC with the PDC emulator FSMO role that is consulted to determine if the password has been changed without the replica DC’s knowledge. The PDC emulator is also the default domain controller for many administrative tools, and is likewise the default DC used when Group Policies are updated.
Additionally, it’s the PDC emulator which maintains the accurate time that the domain is regulated by. It’s the time on the PDC emulator which identifies when the last write time for an object was (to resolve conflicts, for example.) If it’s a forest with multiple domains, then the forest root PDC is the authoritative time source for all domains in the forest. Each domain in the forest needs its own PDC emulator.