In Windows Server 2003, Microsoft introduces a new feature called Global Catalog (GC)-less logon (also known as universal group caching). What's this feature and how does it benefit the security and architecture of an Active Directory (AD) infrastructure?
Universal group caching lets Windows 2003 domain controllers (DCs) cache a user's universal group memberships in the msDS-Cached-Membership attribute of an AD user account object. You can use the Microsoft Management Console (MMC) Sites and Services snap-in to define and configure site objects and their properties. To enable universal group caching, open the snap-in, select a site object, then open the site object's NTDS Site Settings Properties dialog box, as Figure 1 shows, and select the Enable Universal Group Membership Caching check box.
This new feature benefits both the security and architecture of an AD infrastructure in branch office AD deployments. It lets administrators take advantage of universal groups for easier forestwide resource access control management. At the same time, it eliminates the need to deploy GC servers to every branch office site, which reduces the volume of data that you must replicate between AD instances.
When a user logs on to a Windows 2000 domain, the DC retrieves the user's universal group membership information from a GC server. Microsoft provides a workaround for this requirement by letting the DC ignore GC failures when the DC can't contact the GC server to obtain the user's membership information. However, this workaround takes away the possibility of using universal groups in a Win2K forest. The workaround is based on a registry entry called IgnoreGCFailures, which you have to manually add to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry subkey of every DC. The Microsoft article "How to Disable the Requirement that a Global Catalog Server Be Available to Validate User Logons" documents the workaround.
The new Windows 2003 universal group caching feature doesn't fully eliminate the need to put a GC server in every site-or at least to have one reachable for every site (e.g., one in every domain tree). After you enable the universal group caching feature, you no longer need to use GC servers to find out about a user's universal group memberships; however, you still need a GC server to resolve user principal names (UPNs) when a user logs on using a UPN with an alternate UPN suffix. (A UPN is a name in a mail address-style format such as user@domainname.) Whereas AD can resolve a standard UPN suffix that occurs in the forest domains' DNS names, you need to have a GC server available to resolve any alternate UPN suffixes. Alternate UPN suffixes are additional suffixes that AD administrators have manually added that don't correspond to any of the forest domains' default DNS names. The one exception to this rule is an account that's a member of the Administrators or Domain Administrators groups-these accounts can log on even when a GC server isn't available.
