Since the first days of Active Directory, the concept of FSMO (Flexible Single Master Operator, pronounced “fizmo”) roles has been a topic of endless discussion amongst IT Professionals. Furthermore, the five roles make for a quick and easy first question in an interview. As Active Directory has evolved over more than a decade, the duties of the FSMO role holders have changed very little, but broad understanding of the duties and optimal placement has not consistently matured.
The five FSMO roles are divided in to two categories: forest-wide and domain-wide. The two forest-wide roles, the Schema Master and the Domain Naming Master exist on a per-forest basis. Meanwhile, the three remaining domain-wide roles - the PDC (Primary Domain Controller) Emulator (PDCe), RID (Relative Identifier) Master, and Infrastructure Master - exist for each domain in the forest. So, for example, in a single domain forest, there are a maximum of five possible FSMO role holders. Meanwhile, in a three domain forest, there are a maximum of eleven FSMO role holders (two forest-wide roles, plus three domain-wide roles multiplied by three domains).
Forest-Wide FSMO Roles
Let’s first examine the forest-wide roles, beginning with the Schema Master. The duties of the Schema Master are well defined and very clear, especially in comparison to some of the other roles. Simply put, any change to the forest’s schema must be made directly on the Schema Master. These changes include adding new classes and attributes as well as modifications to existing classes and attributes (e.g. adding an additional attribute to an existing class or indexing an attribute). It’s important to note a common misconception, however. While any changes to the forest’s schema must be written on the Schema Master, a read-only copy of the schema is stored on every domain controller in the forest.
The second forest-wide role is the Domain Naming Master. The duties of the Domain Naming Master are brief and will not be invoked frequently in most organizations. Any time an administrator adds a new domain to the forest, or removes an existing domain, the Domain Naming Master is called upon. Similarly, adding or removing an application partition is also dependent on the Domain Naming Master.
Application Partitions were added to Active Directory in Windows Server 2003. You can use an application partition to replicate a set of objects to a defined group of domain controllers across the forest. Given the name “application partition”, you can infer that Microsoft was anticipating that many people and software companies would take advantage of the feature. Unfortunately, the only common real-world use of application partitions is Active Directory integrated DNS. Even then so, few organizations customize DNS’ use of application partitions beyond the defaults.
Domain-Wide FSMO Roles
The domain-wide FSMO roles are called upon to perform work much more often than the two forest-wide roles we have discussed so far. Let’s begin with the Infrastructure Master – perhaps the most misunderstood and often debated FSMO role. The duties of the Infrastructure Master are narrow and only called upon in a very specific set of circumstances. Simply put, the Infrastructure Master is only relevant when you have a domain with the following characteristics:
· More than one domain in the forest
· All of the domain controllers in the domain are not global catalogs
· Active Directory Recycle Bin is not enabled
If your forest has only one domain, all of the domain controllers in a given domain are global catalogs, or the AD Recycle Bin is enabled, then the Infrastructure Master has no day-to-day duties.
If your domain does not meet the criteria listed above, then the Infrastructure Master has an important task. The Infrastructure Master is responsible for maintaining hidden objects in the directory known as phantoms. Phantoms are used by the Active Directory database to track group members that are not from the local domain and are not present in the local database. If the domain controller is a global catalog, then every object in the forest is present in the database and a phantom is not necessary to track cross-domain group memberships.
Phantoms have a small number of attributes – the objectGUID value of the actual group member in the foreign domain, the group member’s objectSID (security identifier), and the distinguished name (DN) of the group member. Any time an object in another domain is moved or deleted, the phantom must be updated with the correct value or deleted. The Infrastructure Master is responsible for periodically processing each phantom object in the domain and ensuring that it is up-to-date and necessary.
The Infrastructure Master validates phantoms by connecting a global catalog and finding the corresponding object via its objectGUID. The mechanics of contacting a global catalog are why it is important that the Infrastructure Master is not hosted on a global catalog in a multi-domain forest if you have multiple domain controllers in the domain that are not also global catalogs. When the Active Directory Recycle Bin is enabled in a multi-domain forest, the duties of the infrastructure master are performed locally on each domain controller and the placement of the Infrastructure Master is no longer relevant.
Continuing our discussion, the RID Master has a much more straightforward set of duties. The RID Master distributes pools of RIDs – Relative Identifiers – to each writeable domain controller in the domain. Any time a security principal (user, computer, group, etc.) is created on a domain controller, the domain controller uses a RID to construct the security principal’s unique SID (security identifier). Placing the RID Master is not especially complicated – generally a central point in the network that domain controllers can easily contact is ideal.
The final FSMO role in our discussion is the PDC Emulator. The original need for PDC Emulator dates to Windows 2000 and the need to maintain backwards compatibility with Windows NT by way of having a domain controller that acts as the Windows NT Primary Domain Controller. While the fundamental need for this function has long passed, the PDC Emulator has a number of additional tasks that are still critical. The two most common and important tasks that the PDC Emulator continues to perform are time synchronization and password chaining.
In a given domain, the PDC Emulator is the root of the time synchronization hierarchy. All of the other domain controllers in the domain synchronize their clocks with the PDC Emulator (and in turn client computers and member servers synchronize their clocks with their local domain controllers). In a multi-domain forest, the PDC Emulator in the forest root domain serves as the reference for the PDC Emulators in each of the child domains. Ultimately, the PDC Emulator in the forest root domain should be configured to synchronize its clock with an authoritative external time source.
Password chaining is the second duty of interest for the PDC Emulator. Password chaining is important in environments where domain controllers are spread across multiple sites in a Wide Area Network (WAN). In this case, domain controllers attempt to immediately forward password changes and resets to the PDC Emulator. If a user attempts to authenticate, and the authenticating domain controller rejects the user’s password, the domain controller will first attempt to check with the PDC Emulator to see if the PDC Emulator’s copy of the user’s password matches the password the user is attempting to authenticate with.
In addition to these two tasks, the PDC Emulator is also responsible for a number of less frequent tasks such as executing the AdminSDHolder process and authorizing domain controller cloning operations.
Summary
The five FSMO roles are divided in to two categories: forest-wide and domain-wide. The two forest-wide roles, the Schema Master and the Domain Naming Master exist on a per-forest basis. Meanwhile, the three remaining domain-wide roles - the PDC (Primary Domain Controller) Emulator (PDCe), RID (Relative Identifier) Master, and Infrastructure Master - exist for each domain in the forest. So, for example, in a single domain forest, there are a maximum of five possible FSMO role holders. Meanwhile, in a three domain forest, there are a maximum of eleven FSMO role holders (two forest-wide roles, plus three domain-wide roles multiplied by three domains).