Understanding and Identifying the Operations Masters within Your Active Directory Environment
Introducing the Operations Masters / FSMO (Flexible Single Master Operations) Roles
FLEXIBLE WHOS THAT DO WHAT?! That was my initial response when I first encountered these roles a few years back while preparing for an interview with Microsoft. Since then, I have been getting warmer and cozier with them, coming to understand their functions as well as their implications/impact upon an Active Directory environment. The Microsoft Windows 2000 Server and above architecture revolves around the concept of distributed environments and “multi-master” replication. Essentially, Microsoft did away with the single master architecture (PDCs and BDCs) of Windows NT 4.0 Server, right?
Well, mostly yes…
What it comes down to is this – There are some things better left with one single Domain Controller being responsible for making the changes in a given Active Directory forest or domain. In Windows 2000 environments, we refer to these responsible Domain Controllers as Flexible Single Master Operations (FSMO) role owners. In Windows 2003 Server environments, we refer to these Domain Controllers as Operations Masters. The terminology changed, but the essential roles didn’t.
There are five Operations Masters:
- The Schema Master
- The Domain Naming Master
- The RID Master
- The PDC Emulator
- The Infrastructure Master
These roles exist because not everything in a well-constructed environment lends itself to a multi-master replication model. My favorite example for this is the governing of Schema changes. What if you had multiple servers capable of making changes to the Active Directory Schema at any given time? In a multi-master environment, generally speaking, the last change written wins. Effectively, if two people are editing the Schema and their efforts overlap, somebody’s changes will be lost. Let’s take that scenario a step further. What if multiple simultaneous changes cause corruption in the Schema or what if the Schema contents across the Domain Controllers gets out-of-synch? Envision strange replication errors at best and/or your Active Directory forest getting trashed at worst. Imagine long hours working to rebuild Domain Controllers and restoring System States from backups in an effort to rebuild your Active Directory environment. Personally, in my mind, it brings up visions of a villeage being brutally attacked by Genghis Kahn and his warriors. I can see the fires, destruction, and chaos reigning supreme. And usually in those stories, somebody’s head ends-up on a chopping block. Luckily, Microsoft foresaw the necessity of the establishing the five single master roles.
In this paper, we will review the Operation Masters / FSMO roles and become familiar with some of their characteristics from an Active Directory perspective. Understanding and locating these role owners now may help in assessing the performance of your network operations later as well as help by being a precursor step for evaluating the impact of a “server-down” situation.
Let’s begin.
The Schema Master
The Schema Master role owner is the only Domain Controller in an Active Directory forest which can process changes to the Schema. These changes are commonly referred to as extensions to the Active Directory Schema. These extensions could be either objects or properties being added to the Schema. Some examples of when a Schema would be extended include the introduction of Microsoft Exchange, the introduction of Microsoft Live Communications Server, or even an upgrade of an Active Directory domain from Windows 2000 to Windows 2003.
So where do the changes take place? Where is the Schema actually held? Well, when referring to the Schema we are refering to an Active Directory database partition known as the Schema Naming Context located at LDAP://cn=schema,cn=configuration,dc=. Changes are made to this database partition on the Schema Master and are then replicated out to all of the other Domain Controllers in the forest.
A few caveats to remember:
- Forest role (1 per forest)
- Default role owner is the first server promoted to Domain Controller within a Active Directory forest
- To manipulate the Schema you must be a member of the Schema Admins group
- Responsible for making changes to the Active Directory Schema
- Maintains the Schema Naming Context LDAP://cn=Schema,cn=configuration,dc=
The Domain Naming Master
The Domain Naming Master role owner is the only Domain Controller in a forest which can create or delete Active Directory domains within the forest. This role owner is also responsible for maintaining cross-references to domains in other external Directories.
The information this Domain Controller maintains is located in the Partitions\Configuration Naming Context, or LDAP://cn=partitions,cn=configuration,dc=. As with the Schema Master, changes are made to this database partition and are then replicated out to all of the other Domain Controllers forest-wide.
A few caveats to remember:
- Forest role (1 per forest)
- Default role owner is the first server promoted to Domain Controller within a Active Directory forest
- A Domain Admin can manipulate this role if the Active Directory forest contains only a single domain
- Only an Enterprise Admin can manipulate this role if the AD forest contains multiple domains
- In Windows 2000 Native Mode, this role owner must also be a Global Catalog server. In Windows 2003 Functional Level, this role owner does not have to be a
- Global Catalog server but it is recommended that one be present in the same site/subnet.
- Maintains the Partitions\Configuration Naming Context LDAP://cn=partitions,cn=configuration,dc=
- Manages the addition or deletion of domains in the Active Directory forest as well as cross-references to domains in other external Directories
The RID (Relative ID) Master
The RID Master role owner is the only Domain Controller in an Active Directory domain responsible for assigning RID pools to the other Active Directory Domain Controllers within that domain. NT 4 BDCs in a mixed-mode domain are not assigned RID pools as they rely on the PDC Emulator for the creation of security principals. Security principals are objects such as users or groups which have permissions and/or rights assigned to them.
In a Windows 2000 or above domain, all Domain Controllers can create security principals. When a security principal is generated, the Domain Controller creating the object attaches a SID to it. This SID is comprised of a domain SID and a RID value (which ensures the SID’s uniqueness). During the logon process, credentials such as a SAM account name or a UPN (Universal Principal Name) are presented to the system. These credentials are resolved to their respective SID, which is used to uniquely identify that object. The SID is then evaluated for the purposes of authentication and resolving security permissions.
To ensure that each Domain Controller has a unique RID pool, the RID Master role owner, by default, allocates 500 RIDs for each Domain Controller in it’s domain. As new Domain Controllers are brought up in the domain, RID pool allocations are also made for those.
Starting with Windows 2000 Server Service Pack 4, Domain Controllers begin requesting a new RID pool when they reach a threshold value of 50% remaining RID values. Prior to SP4, the threshold value was 20%. This means that a SP4 or Windows 2003 Server Domain Controller using the default RID block size of 500 will start requesting a new pool when 250 RIDs (50%) remain. In contrast, a pre-SP4 Windows 2000 Server Domain Controller using the same RID block size will start requesting a new pool when only 100 RIDs (20%) remain.
The RID Master is also responsible for ensuring that when an Active Directory object is moved from one domain to another, the move is performed appropriately (that the object does not end-up existing in multiple domains simultaneously). To move an object via movetree.exe, initiate the move on the RID Master role owner in the Domain in which the object currently resides. After the move is complete, that RID Master will then delete that object from it’s Active Directory domain.
A few caveats to remember:
- Domain role (1 per every domain contained in the Active Directory forest)
- Default role owner is the first server promoted to Domain Controller within an Active Directory domain
- To manipulate this role you must be a member of the Domain Admins group
- Every security principal in a domain has a SID (Security Identifier), comprised in part by a RID
- Object moves between domains are initiated at/performed by the originating domain’s RID Master
The PDC Emulator
The PDC Emulator role owner in an Active Directory domain is the Domain Controller with the final authority regarding password issues and is largely responsible for mitigating Kerberos authentication issues by providing an authoritative time-synch within a domain/forest. Any user authentication failure due to a password issue at a Domain Controller is passed-back to the PDC Emulator for a final determination before a password failure message is reported to the user. The PDC Emulator also functions as the Master Browser and processes the account lockout functions for it’s domain. There are some variations, however, in this role owner’s scope of responsibilities depending upon the functional level (or mode) of the Domain and the PDC Emulator’s location within the Active Directory forest.
Tip: In an enterprise, to assist a user with a password change and avoid the inconvenience of initiating Active Directory replication/s to synchronize changes, make the change on the Domain Controller which is the PDC Emulator for the user’s Active Directory domain.
The Domain Controller in an Active Directory forest which holds the PDC Emulator role is the authoritative time server for that forest. This is important and necessary because Kerberos uses time synchronization as one of it’s checks during the authentication process for security principals. By default, Kerberos authentication will fail if the clocks are more than 5 minutes apart.
Tip: It is strongly recommended that the PDC Emulator for the Active Directory forest be synchronized to an outside time source such as:
tock.usno.navy.mil
time.nist.gov
ntp2.usno.navy.mil
If the PDC Emulator role is transferred to another Domain Controller, then that Domain Controller should be pointed to an external time source to maintain the consistent, uniform time synch across the forest.
As mentioned before, the PDC Emulator role within an Active Directory domain also varies depending upon the functional level (or mode) of the domain it is in. In Mixed Mode, the PDC Emulator provides backward-compatibility, performing functions necessary to support NT 4.0 BDCs within the domain. These functions include processing account changes for the BDCs, the creation of security principals, and providing a centralized SAM for the BDCs to update themselves with. This Domain Controller also would be the referenced when establishing trust relationships with external NT 4.0 networks.
In a pure Windows 2000/2003 Server environment (aside from the possibility of Windows NT 4.0 Member Servers), all Domain Controllers are capable of creating security principals as well as processing account changes. Password changes, however, are treated preferentially. A password change can be processed by any Domain Controller within an Active Directory domain; however once that change is made, it is replicated immediately to the PDC Emulator. This action supports the PDC Emulator as being the final authority in password authentication.
The PDC Emulator role owner is the default location where Group Policy Objects are edited to reduce any risk of conflict.
A few caveats to remember about the PDC Emulator:
- Domain role (1 per every domain contained in the Active Directory forest)
- Default role owner is the first server promoted to Domain Controller within an Active Directory domain
- To manipulate this role you must be a member of the Domain Admins group
- Role varies somewhat depending upon the functional level or mode of the domain it is in
- Final Authority for password authentication
- Should be time synched across the forest; forest-level PDC should be synced to an external standard
- Default Domain Controller on which Group Policy Objects are edited
The Infrastructure Master
The Infrastructure Master role owner is responsible for keeping track of all of the objects within it’s own domain as well as maintaining phantom objects found in cross-domain references. Let’s dissect this. “Keeping track of all objects in it’s own domain” – right on! Somebody has to know who’s on first, what’s on second, etc. No problem. “Maintaining phantom objects found in cross-domain references” – hmm, the whole phantom thing brings thoughts of Scooby-Doo and the Mystery Mobile to mind. Ruht-Roh! Let’s clarify this a bit.
Phantom objects are objects which do not exist in the Infrastructure Master’s domain, but they exist elsewhere and they are being referenced in this domain. A good example would be a person, whose user object exists in one domain, being included in a group which exists in your domain. That person’s user object is not present in your domain, but it’s essence is – thereby constituting a phantom object.
The essence analogy is my term for it. To be specific, the phantom object attributes maintained/tracked by the Infrastructure Master include the object’s GUID (Globally Unique Identifier), SID (if the object is a security principal), and the object’s DN (Distinguished Name). A phantom object reference is termed stale if the original object has been moved or renamed since the last update of the Infrastructure Master.
The Infrastructure Master within an Active Directory domain updates it’s phantom object references based on any changes found on it’s nearest Global Catalog Server. The Infrastructure Master writes any object updates it finds to it’s database and then replicates those changes out to the non-Global Catalog Domain Controllers within it’s domain.
Note: Global Catalogs contain all objects in an Active Directory forest; however they only contain a subset of the attributes for each object
Note: Global Catalog servers are updated regularly
Tip: Windows 2000 Global Catalog Servers rely on a full replication of the Global Catalog, which may prove to be a bandwidth burden depending upon how your remote sites are connected and how large your Global Catalog becomes. In contrast, Windows 2003 Servers hosting the Global Catalog only replicate changed objects and their attributes, yielding lesser bandwidth consumption and better performance.
In a single domain scenario, the Infrastructure Master role owner has nothing to do so it makes no difference on which Domain Controller this role exists. In a multiple domain Active Directory forest, the Infrastructure Master cannot sit on a Global Catalog server. Ideally, the Infrastructure Master should be sitting in a well-connected site which contains one or two Global Catalog servers (for redundancy), but the Infrastructure Master role owner itself should not be on a Global Catalog server.
Note: If the Infrastructure Master role is sitting on a Global Catalog server, it will never notice that changes have been written by the Global Catalog. Any changes that server has recorded will never be replicated out to the other non-Global Catalog Domain Controllers within it’s domain. Effectively, only the Global Catalog servers will be up-to-date.
This role owner maintains the Domain Naming Context partition of Active Directory. The LDAP location for this information is LDAP:// cn=domain,dc=. Changes are made to this database partition and then replicated out to all of the other Domain Controllers within that Active Directory domain.
A few caveats to remember:
- Domain role (1 per every domain contained in the Active Directory forest)
- Default role owner is the first server promoted to Domain Controller within an Active Directory domain
- To manipulate this role you must be a member of the Domain Admins group
- Maintains the Domain Naming Context partition of Active Directory LDAP:// cn=domain,dc=
- The Infrastructure Master role owner is responsible for keeping track of all of the objects within it’s own domain as well as maintaining phantom objects used in cross-domain references
- In a single domain scenario, the Infrastructure Master role owner has nothing to do so it makes no difference on which Domain Controller this role exist
- In an Active Directory forest with multiple domains, the Infrastructure Master role owner can not be a Global Catalog Server
How to Identify the Operations Master Role Owners within Your Environment
To identify the Domain Controllers holding the various Operations Master roles, there are various methods at our disposal; however, for the purpose of this paper, we will simply cover working through the various GUIs.
Identifying the Schema Master
Identifying the Domain Naming Master
Identifying the RID Master
Identifying the PDC Emulator
Identifying the Infrastructure Master
Conclusion
SO WHAT DOES THIS MEAN TO ME? Simple. In either a Small Business Server environment or compact, single domain environment – it may not mean much. It would still be a good idea to at least identify the Operations Master role owners in your environment so that you can have an idea of the impact in the event of a “server-down” or “network-down” situation. Review the locations of the role holders. Do they make sense? What is your contingency in the event of an outage? To that end, I must say that NTDSUTIL is a terrific utility to keep accessible.
For Small Business Server owners, the identification is much simpler and your options are much narrower in scope. By design, all roles are held on the Small Business Server itself and cannot be transferred. Be diligent in performing backups and ensure that the System State as well as all necessary data is being backed-up appropriately.
Enterprise operations have the biggest gains (or losses) to be encountered in light of understanding the Operations Master roles, role placement, and contingency planning. Some roles can even be absent from an environment for a period of time before the effects become noticeable. The more we understand the roles and their interactions, the more “bullet-proof” we can design our Active Directory environment.
Bibliography
- Windows Server 2003: The Complete Reference, Kathy Ivens, ISBN: 0-07-219484-7
- Active Directory, Allen & Lowe-Norris, ISBN: 0-596-00466-4
- Exam Cram 2: Windows Server 2003 Active Directory Infrastructure, Will Willis & David Watts, ISBN: 0-7897-2950-4
- “‘Domain controller has failed to obtain a new identifier pool’ error event in Windows 2000 Server SP3 and earlier”, Article #316201, Microsoft Support Knowledge Base
- “Windows 2000 Active Directory FSMO Roles”, Article #197132, Microsoft Support Knowledge Base
- “How to View and Transfer FSMO Roles in the Graphical User Interface”, Article #255690, Microsoft Support Knowledge Base
- “How to Find Servers That Hold Flexible Single Master Operations Roles”, Article #234790, Microsoft Support Knowledge Base