Learning Windows Server 2003
5.3. Understanding Operations Master Roles
As I mentioned earlier, all domain controllers are nearly equal in Active Directorythat is, any one of them can be updated and can replicate changes to the others. This decentralization is in direct contrast to Windows NT 4.0-style domains, which had only one PDC that accepted directory object modifications and any number of BDCs that held read-only copies of the accounts database. BDCs could authenticate users, but any changes to any attributes of domain accounts had to take place in direct communication with the PDC. Because the PDC pushed out copies of the accounts database, known as the SAM database, to the BDCs for a domain, this sort of replication was known as single-master replication because one master computer communicated changes to slaved, less-capable computers. Enter Active Directory onto the scene, where there are effectively no distinctions between domain controllers in most operations. Unless your domain is functioning at the NT interim functional level (more on that in the migration section later in this chapter), all domain controllers for a domain can accept changes for data in their domain, and domain controllers have peers to which they replicate changes to those objects. This sort of setup typically is called multimaster replication because each domain controller acts as a master, passing changes to other domain controllers until those changes are replicated fully. Replication is covered in detail in the next section, but that introduction serves as an adequate segue to this fundamental issue: this decentralized approach has problems. Some actions taken within forests and domains could cause havoc if performed simultaneously on two separate domain controllers before replication has occurred. What if:
Clearly, some domain controllers need to have greater control over others, simply because sometimes, all computers need a bit of authority. Active Directory is not entirely self-governing. Microsoft took care of this problem by implementing special roles for some domain controllers in Active Directory, called operations master roles. (These roles also can be called flexible single master of operations roles, pronounced fizz-moh, but the proper term is operations masters.) There are five specific operations master roles, and each is listed here in the order in which it corresponds with the scenarios discussed earlier:
These roles are distributed one per domain, except for the schema and domain-naming roles, which are allotted one per forest. After all, schema changes affect the forestwide Active Directory, and you shouldn't have two domains named exactly the same within the same Active Directory forest. However, RIDs are specific to domains, PDCs are specific to individual domains, and infrastructure masters account for changes within domains only, not the whole forest.
5.3.1. Schema Master
The schema master in a forest carries out a very important functionensuring that changes to the schema, or to the actual structure of the Active Directory database, are made in a consistent manner. The schema master prevents change collisions across the forest, which is a bigger problem than you might imagine and one that grows with the size of your Active Directory-based network. Although you might not think the schema would change often, a few operations actually do this: for one, installing Exchange 2000 or 2003 into a domain will extend the forestwide schema even if some domains are not using Exchange. Other Active Directory-aware applications are likely to modify the schema as well, such as Microsoft's ISA Server firewall and some network and user management applications, such as those from NetIQ. Also recall that the forest Active Directory schema and the global catalog are intertwined. Recall also that the global catalog contains a subset of information from all domains within a forest. If you added new attributes to the schema and wanted to include those in the global catalog, all your domain controllers that act as global catalog servers will need to receive the change. For Windows 2000-based domain controllers, the entire global catalog must be flushed and rebuilt on each domain controller; for Windows Server 2003-based domain controllers, only the change needs to be propagated. For large organizations, this is a big bandwidth saver if most of your GC-based domain controllers are on Windows Server 2003. It is just something to keep in mind. To identify the schema master on Windows 2000 Server and Windows Server 2003, computers use the Schema Management console. You will find the DLL that enables the Schema MMC snap-incalled schmmgmt.dllunder the \WINDOWS\system32 directory. Open a command-line window, navigate to that directory, and then do the following:
To change the schema master (you must be a member of the Schema Admins group to do this), from within the Schema Management console you loaded in the previous procedure, right-click the root node labeled Active Directory Schema in the left pane, and select Change Domain Controller from the context menu. In the dialog box that appears, type the name of the domain controller to which you want to move the schema master role, and then click OK. Then, proceed from step 7 in the previous exercise, and click the Change button in the Change Schema Master dialog box. Confirm your choice, and once the processing is complete, click Close. The schema master role has been moved. Figure 5-41. The Change Schema Master dialog box
5.3.2. Domain-Naming Master
The domain-naming master role is one of the forest-specific roles, meaning that only one domain controller in the entire forest has this role. This role protects against the creation of identically named domains in the same forestif this were to happen, Active Directory could not cope with the same names and panic would result. Keep in mind that this role is designed to be placed on a global catalog server, and not just a standalone server. It would seem that this role uses some information contained in the GC (excerpts of the directories of other domains in the forest) to fulfill its responsibilities. However, if you are operating in the Windows Server 2003 forest functional level, this placement is unnecessary. To change the domain-naming master role (you must be a member of the Enterprise Admins group to do this), use the Active Directory Domains and Trusts tool. Open it from the Administrative Tools menu and then right-click the root node in the left pane of the window and select Change Domain Controller from the pop-up context menu. Type the name of the domain controller to which you want to move the role, and then click OK. The focus of the management console will switch to this domain controller. Then follow these steps:
5.3.3. RID Master
The RID master role handles the assignment and distribution of the latter portion of SIDs for objects within Active Directory. You know that when objects are created in Windows, a unique SID is assigned to it. The SID comes in the form of S-1-5-21-A-B-C-RID, where the S-1-5-21 is common to all SIDs. The "A," "B," and "C" parts of the number are randomly generated 32-bit numbers that are specific to a domain, or to a particular machine (if Active Directory is not installed on the server or if a workstation isn't joined to a domain). The RID, or relative identifier, part of the SID is another 32-bit number that is the unique part of the SID and identifies a distinct object in the directory. The domain controller with the RID master role distributes groups of 500 unique RIDs to its brother and sister domain controllers with the domain, so that when they create unique objects, the SIDs they assign to those unique objects should also be unique. Much like DHCP ensures that no two workstations have the same IP address, distributing pools of RIDs in this way ensures that no two domain controllers have the same groups of RIDs to assign. To move the RID master role to another domain controller in a domain, follow these steps:
5.3.4. PDC Emulator
The PDC emulator operations master role serves a very important function for mixed Windows NT Server, 2000 Server, and Windows Server 2003 domains. As I mentioned at the beginning of this section, NT domain controllerswhether primary or backupdon't support multimaster replication, so if your PDC has been upgraded to Windows 2000 or Windows Server 2003, obviously there is no computer from which your BDCs can get updates, or at least none they can understand. Those of you familiar with Microsoft's older networking protocols know that the Master Browser service, the utility that populates Network Neighborhood and My Network Places on workstations and servers, typically runs on the PDC in an NT domain. System policies for Windows 95 are stored on the PDC, not on any BDCs. And trusts between NT domains and Active Directory domains require a PDC, or a PDC emulator, because NT thinks only one computer has the read/write copy of the SAM database. Figure 5-42. Identifying the RID pool master
The PDC emulator runs on one domain controller in a domain to perform these functions. It also helps speed up propagation and replication of changes to two specific attributes of a user object in Active Directory: the password and the account lockout attribute. Think about large organizations, and the time it can take for changes made at one domain controller to filter out. (I'll cover replication in a lot more detail in the next section, but know for now that replication can involve a considerable amount of time if you have many domain controllers handling Active Directory responsibilities in your environment.) If a user called to reset a password and the help desk personnel responding to that call were in another site, the password change would take effect first on the domain controller local to the help desk personnel, not necessarily local to the person whose password was being changed. Do you really want to wait the hours it might take for that change to take effect? Of course not, so the domain controller for the help desk personnel immediately contacts the domain controller holding the PDC emulator role for the domain, and it gets that updated password, thus avoiding replication delays. So, although the local domain controller for the user might not have the new password, the local domain controller will look at the PDC emulator domain controller to check if the password matches there. If it does, the user gets a green light to log in. (Of course, password changes aren't actually immediatethere is still lag time.) This policy stretches to one other attribute as well. If you use account lockoutswhen a password is entered incorrectly for X number of times, the account becomes temporarily disabled for a period of timeit probably wouldn't do a lot of good for only the password to be passed quickly to the PDC emulator role. The user would have the right password, but neither the PDC emulator nor the local domain controller for the user would know the account actually wasn't locked out anymore. So, the account lockout attribute is passed at the same time as a password reset, to make sure users aren't sitting, twiddling their thumbs without access to their domain user accounts while the domain controllers wait for replicated changes to arrive. Finally, the PDC emulator handles time synchronization in a domain. Ideally, the PDC emulator role should be on the same domain controller as the RID master role. To move the PDC emulator role, use ADUC, as follows:
Figure 5-43. Identifying the PDC emulator master 5.3.5. Infrastructure Master
The infrastructure master also helps to speed up propagation and replication of certain pieces of information among domain controllers. The infrastructure master role is designed to not be on a domain controller functioning as a GC serverthat is, unless every domain controller in your domain is a GC server as well, or if you have only one domain. To find out and change which domain controller holds the infrastructure master role, use the ADUC tool. As before, if you have only one domain controller in your domain, that is obviously the infrastructure master. In larger domains, to identify and/or change this machine, follow these steps:
Figure 5-44. Identifying the infrastructure master
5.3.6. Transferring and Seizing Roles Manually
Sometimes you might need to change the operations master roles that domain controllers are playing without necessarily using the graphical interface. It might be that you inadvertently unplugged and reformatted your first domain controller in your domain too early, without transferring its roles elsewhere. Or maybe your specific server is temporarily offline but you really need a role transferred as soon as possible.
Windows Server 2003 comes with the NTDSUtil tool, a command-line utility that allows you to perform Active Directory maintenance that goes above and beyond what the GUI tools allow. In this case, you might need to transfer the schema master, domain-naming master, or RID master rolesor you might need to force that transfer if the original holder of those roles is unavailable. To transfer a role using NTDSUtil, open a command prompt and run NTDSUTIL. Then follow these steps:
If you find error messages when you're simply attempting a transfer, you can force the role transfer by using the SEIZE command. After step 4 in the previous procedure, start the following.
|