Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Flexible Single Master Operations

In a multiple-master replication environment, any domain controller can theoretically change any object in Active Directory. As we saw in the last chapter, Active Directory has special features to handle conflicting updates performed during the same replication interval.

Certain Active Directory functions just cannot be shared without causing potential data consistency problems. These special functions are called

Flexible Single Master Operations , or FSMOs (pronounced FizzMohs). The domain controller assigned a particular FSMO is called a

role master. Here are the five FSMOs and the MMC console you would use to view and set the role master:

• PDC Emulator
  AD Users and Computers




• RID Master
  AD Users and Computers




• Infrastructure Master
  AD Users and Computers




• Domain Naming Master
  AD Domains and Trusts




• Schema Master
  Custom console containing the Schema snap-in

PDC Emulator

Active Directory supports the presence of downlevel NTbackup Domain Controllers (BDCs). To make this trick work, Active Directory fools the BDCs into thinking that a Windows Server 2003 domain controller is an NT Primary Domain Controller (PDC). This is necessary because BDCs will only replicate from a PDC. This special domain controller is the

PDC Emulator role master.

The PDC Emulator packages up Active Directory updates that affect objects shared by the classic SAM and replicates those updates to the downlevel BDCs using LanMan Replication. While in Mixed, objects representing security principals (users, computers, and groups) can only be created by the PDC Emulator.

After all domain controllers have been removed from operation, the domain can be shifted to Native. When this is done, the LanMan Replication service is stopped and the downlevel BDCs no longer get updates. They remain active, however, getting older and older and further and further out of date, a little like 1960s rock bands.

You cannot promote a classic NT BDC to PDC after you have begun upgrading your domain to Active Directory. You can, however, transfer the PDC Emulator role to another Windows Server 2003 domain controller (or a Windows 2000 domain controller if you are still running in Functionality Level 0). From the perspective of the downlevel BDCs, this looks as if a BDC has been promoted. They shift their allegiances to the new PDC Emulator and begin replicating from that server.

Windows 9x and NT clients that are members of a domain know that the only domain controller with write permissions on the domain SAM is the PDC. Therefore, when these clients need to change a password, they communicate directly to the PDC. In modern Windows, any domain controller can update a user's password but the downlevel clients don't know this. The PDC Emulator gives the downlevel clients a place to go when they want to change passwords or make any other change involving the classic SAM.

In addition to its duties as housemaid to the downlevel BDCs, Microsoft decided to throw additional single master operations onto the PDC Emulator. For example, as we saw in Chapter 7, "Managing Active Directory Replication," the PDC Emulator is also the primary time standard for other domain controllers in a domain. There are three additional duties assigned to the PDC Emulator.

Final Validation for Password Changes

When a user changes a password, or an administrator resets a password for a user, the update is replicated to the PDC Emulator on a "best effort" basis. This means that schedules on intervening inter-site links are ignored.

The domain controllers in a domain use the PDC Emulator as a "last court of appeals" for invalid passwords. If a user enters an incorrect password, the local DC checks with the PDC emulator to see if the password has been changed and the user's password is actually valid. If so, the user is given access. This feature prevents calls to the Help Desk following a password change.

Preferred Group Policy Location

Group policies consist of two components: a Group Policy Container (GPC) in Active Directory and a Group Policy Template (GPT) in \Windows\Sysvol\Sysvol\<domain_name>. If these two components get out of sync, a user will either try to get a policy when the GPT is not yet in Sysvol or will miss a policy in Sysvol because the GPC hasn't yet replicated to the logon server.

To avoid this problem and other inconsistencies that might arise from multi-master replication, when you open the Group Policy Editor, the focus of the tool is set to the PDC Emulator. This ensures that all administrators in the domain make their group policy modifications on the same machine, reducing the likelihood of synchronization problems.

Key:    HKLM\CurrentControlSet\Services\Netlogon\Parameters
Value:  AvoidPDConWAN
Data:   1

If the PDC Emulator is not available (either because it is down or the WAN link is cut), you'll be prompted to pick another domain controller or to wait until the PDC Emulator is available again. If you are fairly confident that your modification won't conflict with changes made by other administrators, you can select another domain controller.

Keep this behavior in mind as you update your group policies. If you are several slow hops away from the PDC Emulator, it may take you a while to get your screen refreshed.

Domain Master Browser

Windows is a little like the Beverly Hillbillies in some respects. You can dress it up and put it in a fancy setting, but at some point or another you're going to end up with lye soap cookin' out by the cement pond.

An example of this unsophisticated behavior is

browsing . I don't know of a single Windows feature that has caused more administrative headaches than browsing.

Modern Windows does not need browsing. You can publish your printer resources in Active Directory. You can use the Distributed File System (Dfs) to abstract your share points away from their home servers. But for some reason, users find it comforting to open My Network Places and scratch around looking for resources.

Windows Server 2003 provides backward compatibility for browsing. Windows Server 2003 and XP desktops participate in browse elections on an equal footing with NT4 servers and workstations. If they win the election, they become the Subnet Master Browsers.

In a routed enterprise, browsing depends on a single server, a Domain Master Browser, to aggregate the subnet browser databases and distribute a comprehensive server list. In a classic NT domain, the PDC acts as the Domain Master Browser. In an Active Directory domain, the PDC Emulator takes on this chore.

WINS plays an important role in browsing by publishing the IP address of the Domain Master Browser and any Subnet Master Browsers. It's important that the PDC Emulator be a WINS client so it will register the appropriate browser records.

RID Master

All security objects have a SID. The SID is a combination of the SID of the domain and a sequential number called the

Relative ID , or RID. In a classic NT domain, security principals added after initial installation get RIDs starting with 1000. Here is an example of a few SIDs from a domain:

PhxUser1:   S-1-5-21-515967899-764733703-1708537768-1000
XP-WKS-01$: S-1-5-21-515967899-764733703-1708537768-1001
PhxAdmins:  S-1-5-21-515967899-764733703-1708537768-1002
PhxUser2:   S-1-5-21-515967899-764733703-1708537768-1003

Notice that the last four digits, the RID for each SID, are in sequence. In a native-mode domain where any domain controller can create a security principal, the RIDs may not be in sequence, but they must be unique. For this reason, only one domain controller can hold the RID pool. This is the

RID Master . The available RIDs are stored in an attribute called RIDAllocationPool.

While in Mixed, the RID Master and PDC Emulator stay in constant touch because only the PDC Emulator can create security principals. In Native, the RID Master slices hunks from the RID list and passes them out to the domain controllers when they request it.

There is one RID Master per domain. By default, the RID Master and the PDC Emulator roles are held by the same domain controller. You can transfer the RID Master role to another domain controller, but it is important that it remain available as long as you are in Mixed. Continuous service is not as critical in Native because each domain controller has a big slice of the RID pie, but you would not be able to promote new domain controllers without the RID Master.

Infrastructure Master

When you add a user to a group, the user's distinguished name (DN) is added to the Member attribute for the group. The User object has a corresponding MemberOf attribute that contains the distinguished names of the groups to which the user belongs.

This pair of attributes, Member and MemberOf, are examples of

linked attributes. In a pair of linked attributes, the primary attribute is termed a

forward

link and the other attribute is a

back-link . In the example, the Member attribute is the forward link and the MemberOf attribute is a back-link. Only the forward link can be modified directly. The back-link is calculated.

There are many instances of linked attributes in Active Directory. Another example is the Manager attribute, a forward link that identifies a user's manager, and the Reports attribute, a back-link that lists the users who report to a single manager.

When a forward link is changed, for example, when a new user is added to a group, the user DN is replicated to all domain controllers hosting a replica of the affected naming context. When a domain controller applies the update, it recalculates the back-link attribute for the affected user object.

If you think this process has the potential to get a little messy and complicated, you're right. Maintaining referential integrity between linked attributes is one of the more complex processes in a directory service.

The linked Member and MemberOf attributes play an important role in Active Directory security because groups, as security principals, are used to protect objects. Users who are members of a group get the access permissions assigned to the object. When a user logs on, the system does a search for any groups that have the user's DN in their Member attribute. It resolves these group names into SIDs and adds them to the

Privilege Access Certificate (PAC) for the user. The security subsystem on a member server uses the PAC to construct a local access token for the user.

If the user's distinguished name changes, the system must update all the group objects that have the user as a member. This must be done as quickly as possible so the user doesn't "fly under the radar" and get inappropriate access permissions.

Updates to the Member attribute for group objects in the same domain as the user with the changed name happen immediately because the domain controller holds both the user object and the group object. But when a user is a member of a group in another domain, the update can take a while. A domain controller in the remote domain must be informed about the name change so it can change the Member attribute for any affected groups in that domain.

The job of quickly disseminating these name changes falls to the

Infrastructure Master .

Domain Naming Master

When you create a new domain in an existing forest, the other domain controllers need to know that the new domain exists because the domain represents a separate naming context. The Directory Service Agent's (DSA's) shared knowledge about each other's naming contexts is one of the principal foundations of LDAP.

Active Directory stores pointers to other domains in a special CrossRef object located in a Partitions container in the Configuration naming context. This object contains attributes that describe the distinguished name, DNS name, the flat name, and the name of the Domain naming context along with the kind of trust relationship that binds the domain to the forest.

If two administrators were to create new domains with identical names during the same replication interval, the standard collision management algorithms would fail to prevent a snarl of incorrect links, references, and replication connections. For this reason, only one computer in a forest can make changes to the Partitions container, and that is the

Domain Naming

Master .

By default, the Domain Naming Master is the first domain controller promoted in a forest. You can transfer this role to any domain controller in any domain, although it's best to put it on a domain controller in the root domain so there is no question about which group of administrators can have access to the server.

Schema Master

TheChapter 6, "Understanding Active Directory Services," discussed the requirements to modify the schema manually. This permits you to add attributes and object classes to support in-house applications for departments such as Human Resources or Facilities. Client/server applications such as Exchange 2000 also make changes to the schema. Newer network management applications can take advantage of features in Active Directory and they often make schema changes.

When you install an application that modifies the schema, you do not need to be at the console of the Schema Master, but the Schema Master must be online and available before the schema updates can be applied. Also, you must be a member of the Schema Admins group.

The role master for a FSMO can be transferred to another domain controller or seized if the original domain controller has crashed and cannot be revived. The procedures for these actions are in Chapter 10, "Active Directory Maintenance."

Role Master Location

If you take no actions to transfer FSMO roles, the first domain controller you promote will have all the roles, making it a significant risk as a single point of failure. Here is a set of recommendations for placing FSMO role masters:

• PDC Emulator and RID Master.
  Keep these two FSMOs on the same domain controller. Use a fast, reliable machine that is well connected to your WAN. Remember that all other domain controllers in the domain check invalid passwords by querying the PDC Emulator for a second opinion.




• Infrastructure Master.
  Move this FSMO to a domain controller that is

  not a Global Catalog server. Make sure the server is well connected because it is responsible for updating the other domain controllers with name cross-reference changes.




• Domain Naming Master.
  Move this FSMO to a domain controller that is also a Global Catalog server. This server does not need to be fast but it must be available when you create a new domain.




• Schema Master.
  Microsoft recommends putting the FSMO on the same domain controller assigned as Domain Naming Master, but this is not an absolute requirement. The schema rarely needs updating, but you want to maintain tight security on the Schema Master. All servers share a copy of the schema, so the Schema Master does not need to be a GC.