Active Directory 2008 : Configuring the Global Catalog and Application Directory Partitions (part 1) - Universal Group Membership Caching

1. Reviewing Active Directory Partitions

AD DS includes a data store for identity and management, specifically the directory database, Ntds.dit. Within that single file are directory partitions. Each directory partition, also called a naming context, contains objects of a particular scope and purpose. Three major naming contexts are discussed in this training kit:

• Domain The Domain naming context (NC) contains all the objects stored in a domain, including users, groups, computers, and Group Policy containers (GPCs).

• Configuration The Configuration partition contains objects that represent the logical structure of the forest, including domains, as well as the physical topology, including sites, subnets, and services.

• Schema The Schema defines the object classes and their attributes for the entire directory.

Each domain controller maintains a copy, or replica, of several naming contexts. The Configuration is replicated to every domain controller in the forest, as is the Schema. The Domain NC for a domain is replicated to all domain controllers within a domain but not to domain controllers in other domains, so each domain controller has at least three replicas: the Domain NC for its domain, the Configuration, and the Schema.

Traditionally, replicas have been complete replicas, containing every attribute of an object, and replicas have been writable on all DCs. Beginning with Windows Server 2008, read-only domain controllers (RODCs) change the picture slightly. An RODC maintains a read-only replica of all objects in the Configuration, Schema, and Domain NCs of its domain. However, certain attributes are not replicated to an RODC—specifically, secrets such as user passwords—unless the password policy of the RODC allows such replication. There are also attributes that are domain and forest secrets that are never replicated to an RODC.

2. Understanding the Global Catalog

Imagine a forest with two domains. Each domain has two domain controllers. All four domain controllers maintain a replica of the Schema and Configuration for the forest. The domain controllers in Domain A have replicas of the Domain NC for Domain A, and the domain controllers in Domain B have replicas of the Domain NC for Domain B.

What happens if a user in Domain B is searching for a user, computer, or group in Domain A? The Domain B domain controllers do not maintain any information about objects in Domain A, so a domain controller in Domain B could not answer a query about objects in the Domain NC of Domain A.

That’s where the global catalog comes in. The global catalog (GC) is a partition that stores information about every object in the forest. When a user in Domain B looks for an object in Domain A, the GC provides the results of the query. To optimize efficiency of the GC, it does not contain every attribute of every object in the forest. Instead, it contains a subset of attributes that are useful for searching across domains. That is why the GC is also called the partial attribute set (PAS). In terms of its role supporting search, you can think of the GC as a kind of index for the AD DS data store.

3. Placing Global Catalog Servers

The GC improves efficiency of the directory service tremendously and is required for applications such as Microsoft Exchange Server and Microsoft Office Outlook. Therefore, you want a GC to be available to these and other applications. The GC can be served only by a domain controller and, in an ideal world, every domain controller would be a GC server. In fact, many organizations are now configuring all of their domain controllers as GC servers.

The potential downside to such a configuration relates to replication. The GC is another partition that must be replicated. In a single domain forest, very little overhead is actually added by configuring all domain controllers as GC servers because all domain controllers already maintain a full set of attributes for all domain and forest objects. A large, multidomain forest has overhead related to replication of changes to the partial attribute set of objects in other domains. However, many organizations are finding that Active Directory replication is efficient enough to replicate the GC without significant impact to their networks and that the benefits far outweigh such impact. If you choose to configure all DCs as GC servers, you no longer need to worry about the placement of the infrastructure operations master; its role is no longer necessary in a domain where all DCs are GC servers.

It is particularly recommended to configure a GC server on a domain controller in a site where one or more of the following is true:

• A commonly used application performs directory queries against the GC.

• The connection to a GC server is slow or unreliable.

• The site contains a computer running Exchange Server.

4. Configuring a Global Catalog Server

When you create the first domain in the forest, the first domain controller is configured as a GC. You must decide for each additional DC whether it should be a GC server. The Active Directory Domain Services Installation Wizard and the Dcpromo.exe command both allow you to configure a GC server when promoting a domain controller. You can also add or remove the GC from a domain controller by using Active Directory Sites And Services.

To configure a DC as a GC:

1. In the Active Directory Sites And Services snap-in, expand the site, the Servers container within the site, and the domain controller’s server object.

2. Right-click the NTDS Settings node and click Properties.

3. On the General tab, shown in Figure 1, select the Global Catalog check box.

Figure 1. The NTDS Settings Properties dialog box, showing the Global Catalog check box

To remove the GC from a domain controller, perform the same steps, clearing the Global Catalog check box.

5. Universal Group Membership Caching

Active Directory supports groups of universal scope. Universal groups are designed to include users and groups from multiple domains in a forest. The membership of universal groups is replicated in the GC. When a user logs on, the user’s universal group membership is obtained from a GC server. If a GC is not available, universal group membership is not available. It’s possible that a universal group is used to deny the user access to resources, so Windows prevents a security incident by denying domain authentication to the user. If the user has logged on to his or her computer before, he or she can log on using cached credentials, but as soon as the user attempts to access network resources, access will be denied. To summarize: If a GC server is not available, users will effectively be unable to log on and access network resources.

If every domain controller is a GC server, this problem will not arise. However, if replication is a concern, and if you have, therefore, chosen not to configure a domain controller as a GC server, you can facilitate successful logon by enabling universal group membership caching (UGMC). When you configure universal group membership caching for a branch office site, a domain controller obtains universal group membership information from a GC for a user when the user first logs on in the site, and the domain controller caches that information indefinitely, updating universal group membership information every eight hours. That way, if the user later logs on and a GC server is not accessible, the domain controller can use its cached membership information to permit logon by the user.

It is recommended, therefore, that in sites with unreliable connectivity to a GC server, you configure UGMC on the site’s domain controllers.

To configure UGMC:

1. Open the Active Directory Sites And Services snap-in and select the site in the console tree.

2. In the details pane, right-click NTDS Site Settings and click Properties.

3. The NTDS Site Settings Properties dialog box, shown in Figure 2, exposes the Enable Universal Group Membership Caching option. When you select the option, the default of the the Refresh Cache From option, <Default>, useshe most efficient route to a site with a global catalog server. It is recommended to use <Default>. Alternately, you can select a site from which to refresh the membership cache. Ensure that the site contains a working global catalog server.

Figure 2. The NTDS Site Settings Properties dialog box with the option to enable Universal Group Membership Caching