Learn AD in 15 Minutes a Week: Active Directory Single Masters of Operation

Learn AD in 15 Minutes a Week: Active Directory Single Masters of Operation


June 19, 2002

by Jason Zandri
www.2000trainers.com

Welcome to the eighth installment of Learn Active Directory Design and Administration in 15 Minutes a Week, a weekly series aimed at current IT professionals preparing to write the new Windows Active Directory Design and Administration exams (70-219 and 70-217 respectively), as well as newcomers to the field who are trying to get a solid grasp on this new and emerging directory service from Microsoft. This installment is going to discuss the Windows 2000 Active Directory Single Masters of Operation. This particular article is going to be a general overview and the next few, in the weeks to come, will break each individual role down in more detail.

 

Overview

In the Windows 2000 Active Directory, there are certain specific domain controllers that are assigned the extra role of Operations master. Sometimes referred to as Flexible Single Masters of Operation (FSMO) servers, these roles are special roles assigned to one or more domain controllers in an Active Directory domain and forest. The domain controllers assigned these roles perform single-master replication of the data they are in charge of (or, if they have more than one role placed on them, multiple replication, albeit, independently of one another). Some of these servers hold forest-wide operations master roles and others hold domain-wide operations master roles.

The Windows 2000 Active Directory design supports multimaster replication of the Active Directory domain database partition between all domain controllers in the domain. This basically means that you can make changes to the domain database partition at any given domain controller, such as functions at a user level like changing your domain password all the way up to a Domain Administrator adding new users to the domain at a remote site by hitting the local domain controller at that site.

[NOTES FROM THE FIELD] - Back in the NT4 days this was not the case. All changes from user passwords to new user creation happened only on the Primary Domain Controller. This meant that if your headquarters (and PDC) was in England and you were at the New York offices and changed your password, that change had to "travel" back to the PDC in London to take effect. The same would be true if you were a Domain Administrator temporarily working out of the Los Angeles office. You would have to "connect" to the PDC in London to perform the administration.

When you simply logged on to the domain in New York, LA, or wherever, you could authenticate against the Backup Domain Controller, which held a read-only Accounts database. The read-only database allowed the remote people to log on using it rather than requiring them to hit the PDC.

Other types of changes are impractical to perform in multimaster fashion, such as those to the Schema and Configuration Partitions. Since these partitions and other types of changes are too sensitive to be done in a multimaster fashion, specific domain controllers are assigned to handle these operations. Since these specific domain controllers handle these particular functions (sometimes referred to as single-master operations), these are the only places within the domain or forest where the copies of these databases are read/write. Everywhere else any copy of these databases reside, it is a read-only copy.

[NOTES FROM THE FIELD] - The read-only database copies of the Schema and Configuration partition operate just like the old domain (SAM) data did under NT4.

Any changes to the SAM database in NT4 had to go to the PDC. Any changes that need to be made to the Schema, for example, go to the Schema Master.

 


There are certain Flexible Single Masters of Operation (FSMO) roles that are Forest Wide Operations Master Roles. This means that no matter how many domains exist in the forest you will only have one of the following FSMO servers each in the forest.

The Schema Master Domain Controller handles all of the updates and modifications to the Windows 2000 Active Directory Schema, and you must have access to the Schema Master to make the changes. There can be only one Schema Master in the entire forest, and you must be a member of the Schema Administrators group to make changes to the Schema.

TheDomain Naming Master Domain Controller handles the adding and removing of domains in the forest as well as adding and removing any cross-references to domains in external directories. (e.g. external Lightweight Directory Access Protocol (LDAP) directories.) There can be only one Domain Naming Master in a single forest, and you must be a member of the Enterprise Administrators group to make changes to the Domain Naming Master, such as transferring the FSMO role or adding domains or removing them from the forest.

The image below shows a single forest structure with two domain trees. Each tree has a root domain and two child domains. There is ONE Schema Master Domain Controller and ONE Domain Naming Master Domain Controller in this forest.



There are certain Flexible Single Masters of Operation (FSMO) roles that are Domain Wide Operations Master Roles. This means that no matter how many domains exist in the forest, you will have one of the following FSMO servers each, in each and every domain in the forest.

The Relative ID Master Domain Controller performs the work of "handing out" relative identifiers (IDs) to each of the domain controllers in the local domain. There is only one Relative ID Master Domain Controller in each single domain in the forest. For every domain, including child domains, there is a Relative ID Master Domain Controller.

Whenever an administrator from a specific domain creates a user, group, or computer object in that domain, the Relative ID Master Domain Controller from that domain assigns the newly created object a unique security ID for that domain by way of the RIDs the creating Domain Controllers own. Remember, all of the Domain Controllers in the domain are assigned relative identifiers from the Relative ID Master Domain Controller. All of the objects created on the different Domain Controllers throughout the domain are IDed in this fashion. The object's security ID (SID) consists of a domain security ID (which is the same for all security IDs created in the domain) and a relative ID that is unique for each security ID created in the domain.

[NOTES FROM THE FIELD] - Think of it like this, the Relative ID Master Domain Controller hands out a block of IDs to the domain controllers so that no two domain controllers in the same domain can create the "same" RID. DC ONE is handed this domain's security ID of a1b and a block of relative IDs from 001 to 100. DC TWO is handed this domain's security ID a1b and a block of relative IDs from 101 to 200. (These are not actual values that are used; they are only examples.) When an Administrator creates a GROUP object at DC ONE it's given a RID of a1b-001. One second later another Administrator creates a user at DC ONE and it is given a RID of a1b-002. One second later another Administrator creates a user at DC TWO, and it is given a RID of a1b-101.

All of these objects are unique because they all end in different identifiers, yet they are also all "marked" relative via their domain security ID of a1b.

An object created in another domain may have the unique number of -001 but it will have a domain security ID of that domain, something different than a1b of the domain in our example.

When an administrator moves objects from one domain to another (using the MOVETREE.EXE utility or the Active Directory Object Manager; you cannot use Active Directory Users and Computers for this), the move must be made via the Relative ID Master domain controller that "houses" that object, not the Relative ID Master Domain Controller where the object is going. For all intents and purposes, that Relative ID Master Domain Controller knows nothing of this object at this point,

The PDC Emulator Domain Controller acts as a Windows NT Primary Domain Controller when there is a domain environment that contains both NT4 BDCs and Windows 2000 DCs. It processes all of the NT4 password changes from clients and replicates domain updates to the down-level BDCs. Once any and all upgrades to the domain controllers have been performed and the last of the BDCs are either upgraded or otherwise removed from the environment, the Windows 2000 domain can be switched to Native Mode. Once the domain is in Native Mode the PDC emulator still performs certain singular duties that no other DCs in the domain handle.

The PDC Emulator receives preferential replication of password changes performed by other domain controllers in the domain. When passwords are changed, that change takes time to replicate to every domain controller in the domain, and that synchronization delay might cause an authentication failure at a domain controller that hadn't yet received the change. Before that domain controller denies access to whatever is trying to perform the access, it will forward the authentication request to the PDC Emulator before rejecting the logon attempt, as the PDC Emulator may have different information (e.g. a new password. Think of it like a domain controller double check. Making sure it's proper to deny access before actually doing it.)

There is only one PDC Emulator Domain Controller in each single domain in the forest. For every domain, including child domains, there is a PDC Emulator Domain Controller.

The Infrastructure Master Domain Controller handles all of the cross-domain (between domains) data updates for users and groups and their memberships. Whenever groups or user names are renamed or changed, and whenever group memberships change, it is the single Infrastructure Master Domain Controller that is handling the single-master operation. There is only one Infrastructure Master Domain Controller in each single domain in the forest. For every domain, including child domains, there is a Infrastructure Master Domain Controller.

 


Best Practices dictate that the Infrastructure Master Domain Controller role should NOT be (it is allowed, but it should not be) on a Domain Controller that is also a Global Catalog Server. Because the global catalog server holds a partial replica of every object in the forest, the Infrastructure Master, in this example, will never perform any updates because it does not contain any references to objects that it does not hold. Remember, the job of the Infrastructure Master Domain Controller is to handle all of the cross-domain (between domains) data updates for users and groups and their memberships. If it does not "see" these changes due to the fact that it access all of the objects through the local copy of the Global Catalog (rather than replicated changes over the network), it will not perform its function.

There are exceptions to these best practices, as identified below.

In a forest that contains a single Active Directory domain the Infrastructure Master has no real work to do because there are no other domains. The Infrastructure Master may be placed on any domain controller in the domain.

In a forest that contains a single Active Directory domain and only a single domain controller, all of the FSMO roles are going to be on the single server by default. Since there are no other servers to migrate these roles to and also since there are no other domains to contend with, the Infrastructure Master may be placed on the single domain controller in the domain.

[NOTES FROM THE FIELD] - While this is possible in that there is nothing preventing you from running a domain via a single Domain Controller, is it HIGHLY unadvisable. No matter how small the domain and how few the users, there should always be a second DC to function as an alternate. In the scenario of a single DC and the loss of that DC, your users will not be able to access network resources, and if the backups of the DC should be bad or far out of date, it would be almost as much work as starting from scratch.

The other exception to the rule would be in a forest that contains multiple domains, where every domain controller in the forest holds a copy of the Global Catalog. In this case, the Infrastructure Master may be placed on any domain controller in the forest because there is no other option. Only a DC can be a FSMO server, and if they all have a copy of the Global Catalog, you are not left with any other option. There would be little update work for the Infrastructure Master to do at any rate, since all of the data from other domains would be contained in the local copy of the Global Catalog.

The image below shows a single forest structure with two domain trees. Each tree has a root domain and two child domains. There are SIX Relative ID Master Domain Controllers, SIX PDC Emulator Domain Controllers and SIX Infrastructure Master Domain Controllers in this forest. There are a total of six domains; therefore, there is a total of six of each of the three types of Domain Wide Operations Master Roles, one in each domain.




 

 

Well, that wraps up this section of Learn Active Directory Design and Administration in 15 Minutes a Week - Active Directory Single Masters of Operation Overview. I hope you found it informative and will return for the next installment.

If you have any questions, comments or even constructive criticism, please feel free to drop me a note.

I want to write good, solid technical articles that appeal to a large range of readers and skill levels and I can only be sure of that through your feedback.

Until then, best of luck in your studies and remember,


"The fact that the grass is greener on the other side of the fence is directly proportional to how much manure is being used on the property."


Jason Zandri
Jason@Zandri.net

www.2000trainers.com