How the Global Catalog Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

In this section

• Global Catalog Architecture

• Global Catalog Protocols

• Global Catalog Interfaces

• Global Catalog Physical Structure

• Global Catalog Processes and Interactions

• Network Ports Used by the Global Catalog

• Related Information

In a multidomain Active Directory® Domain Services (AD DS) forest, the global catalog provides a central repository of domain information for the forest by storing partial replicas of all domain directory partitions. These partial replicas are distributed by multimaster replication to all global catalog servers in a forest.

Note

In Windows Server® 2003 and Microsoft Windows® 2000 Server, the directory service is named Active Directory. In Windows Server 2008 R2 and Windows Server 2008 and, the directory service is named Active Directory Domain Services . The rest of this topic refers to AD DS, but the information is also applicable to Active Directory.

The global catalog makes the directory structure within a forest transparent to users who perform a search. For example, if you search for all printers in a forest, a global catalog server processes the query in the global catalog and then returns the results. Without a global catalog server, this query would require a search of every domain in the forest.

During an interactive domain logon, the domain controller authenticates the user by verifying the user’s identity, and also provides authorization data for the user’s access token by determining all groups of which the user is a member. Because the global catalog is the forestwide location of the membership of all universal groups, access to a global catalog server is a requirement for authentication in a multidomain forest. A global catalog server is also required for applications such as Microsoft Exchange Server.

For more information about other reasons why a global catalog server is required, see the FAQ on the Ask the Directory Services Team blog (https://blogs.technet.com/b/askds/archive/2011/09/30/friday-mail-sack-super-slo-mo-edition.aspx\#gc).

An ideal distribution of the global catalog is to have at least one global catalog server in each AD DS site. When a global catalog server is available in a site, the authenticating domain controller is not required to communicate across a WAN link to retrieve global catalog information. It is recommended make all domain controllers be global catalog servers.

In branch office scenarios, it is often not feasible to deploy a global catalog server in every branch site. At the same time, it is not cost effective to contact a global catalog server over a WAN link for every logon that occurs in the site. On domain controllers that are running Windows Server 2003 or later, universal group membership can be cached so that the domain controller must connect to a global catalog server across a WAN link only for initial logons in the site; thereafter, universal group membership can be checked from a local cache. Search clients, however, must always connect to global catalog servers across the WAN if no global catalog server exists in the client’s site.

This subject describes the functionality of the global catalog and the replication of objects to global catalog servers in an AD DS forest.

Global Catalog Architecture

Global catalog server architecture differs from non-global catalog server architecture in its use of the nonstandard LDAP port 3268, which directs queries to the global catalog. Queries over this port are formed the same way as any LDAP query, but AD DS varies the search behavior according to the port that is used: queries over port 3268 target the global catalog directory partitions (including the read-only domain directory partitions and the one writable domain directory partition for which the server is authoritative), and queries over port 389 target only the writable domain, configuration, application, and schema directory partition replicas stored by the global catalog server in its role as a domain controller. In addition, domain controllers use the proprietary replication interface when they contact global catalog servers to retrieve universal group membership during client logons.

Search clients include Exchange Address Book clients, which use the client MAPI provider Emsabp32.dll to look up e-mail addresses in the global catalog. The client-side MAPI provider communicates with the server through the proprietary Name Service Provider Interface (NSPI) RPC interface.

Windows NT clients use Net APIs to communicate with the Security Accounts Manager (SAM) on the primary domain controller (PDC) emulator. The PDC emulator, a domain controller operations master role in AD DS domains, manages search and replication communication with clients that are running Windows NT.

The relationships between these architectural components are shown in the following diagram. Descriptions for the major components are provided in the subsequent table.

Global Catalog Architecture

For a more detailed description of LDAP and replication client-server architecture, see “How the Active Directory Replication Model Works.”

Global Catalog Architecture Components

Component	Description
Clients	Global catalog clients, including search clients and Address Book clients, as well as domain controllers performing replication and universal group security identifier (SID) retrieval during logon in a multidomain forest.
Network	The physical IP network.
Interfaces	LDAP over port 389 for read and write operations and LDAP over port 3268 for global catalog search operations. NSPI and replication (REPL) use proprietary RPC protocols. Retrieval of universal group membership occurs over RPC as part of the replication RPC interface. Windows NT 4.0 clients and backup domain controllers (BDCs) communicate with AD DS through the Security Accounts Manager (SAM) interface.
Directory System Agent (DSA)	The directory service component that runs as Ntdsa.dll on each domain controller, providing the interfaces through which services and processes gain access to the directory database.
Extensible Storage Engine (ESE)	The directory service component that runs as Esent.dll. ESE manages the tables of records that comprise the directory database.
Ntds.dit database file	The AD DS data store.

Global Catalog Protocols

The following diagram shows the four interfaces into AD DS and the protocols that package the data according to their specific applications. These protocols and interfaces are the same for all domain controllers and are not specific to global catalog servers. The significance for the global catalog server is that domain controllers use the proprietary RPC replication protocol not only for replication, but also to contact the global catalog server when retrieving universal group membership information and when updating the group membership cache when Universal Group Membership Caching is enabled.

Global Catalog Protocols

The protocols are described in the following table.

Global Catalog Protocols

Protocol	Description
Lightweight directory access protocol (LDAP)	The primary directory service protocol that specifies directory communications. It runs directly over TCP/IP, and it can also run over User Datagram Protocol (UDP) connectionless transports (UDP access is primarily used by the domain controller Locator process and can also be used to query the rootDSE). Clients use LDAP to query, create, update, and delete information that is stored in a directory service over a TCP connection through the TCP default port 389. Global catalog clients can use LDAP to query AD DS over a TCP connection through the TCP port 3268. AD DS supports LDAP v2 (RFC 1777) and LDAP v3 (RFC 2251). LDAP v3 is an industry standard that can be used with any directory service that implements the LDAP protocol. LDAP is the preferred and most common way of interacting with AD DS.
Remote procedure call (RPC)	Protocol for replication (REPL) and domain controller management communications (including global catalog server interactions), NSPI address book communications, and SAM-related communications. RPC is a powerful, robust, efficient, and secure interprocess communication (IPC) mechanism that enables data exchange and invocation of functionality residing in a different process. That different process can be on the same computer, on the local area network (LAN), or across the Internet.
Simple mail transfer protocol (SMTP)	Protocol for replication communications when a permanent, “always on” network connection does not exist between two domain controllers. SMTP is used to transport and deliver messages based on specifications in Request for Comments (RFC) 821 and RFC 822. SMTP can replicate only the configuration and schema directory partitions and global catalog read-only replicas (not writable domain data).

For more information about AD DS protocols, see “How the Data Store Works.”

Global Catalog Interfaces

Interfaces for global catalog servers are the AD DS data store interfaces, shown in the previous figure and described in the following table.

Global Catalog Data Store Interfaces

Interface	Description
LDAP	The primary interface for AD DS access. Directory clients use LDAP v3 to connect to the DSA through the LDAP interface. The LDAP interface is part of Wldap32.dll. LDAP v3 is backward compatible with LDAP v2.
REPL	The replication management interface that provides functionality for finding data about domain controllers, converting the names of network objects between different formats, manipulating service principal names (SPNs) and DSAs, and managing replication of servers.
NSPI/MAPI	Name Service Provider Interface (NSPI) by which Messaging API (MAPI) clients access AD DS. Messaging clients gain access to AD DS by using MAPI address book providers. For compatibility with existing messaging clients, AD DS supports the NSPI/RPC address book provider, which provides directory access, for example, to find the telephone number of a user.
SAM	Proprietary interface for connecting to the DSA on behalf of clients that run Windows NT 4.0 or earlier. These clients use Windows NT 4.0 networking APIs to connect to the DSA through SAM. Replication with Windows NT 4.0 backup domain controllers (BDCs) occurs through the SAM interface as well.

Note

The NSPI (MAPI) interface is provided only for support of legacy Microsoft Outlook clients. Development against this interface is no longer supported.

For more information about AD DS data store interfaces, see “How the Data Store Works.”

Global Catalog Physical Structure

AD DS is a distributed directory service in which data is stored as replicas on multiple domain controllers to provide a virtual database that maintains consistency through AD DS replication. Domain controllers provide the domainwide distribution of directory data. Global catalog servers provide the forestwide distribution of directory data in a multidomain forest.

Global Catalog Partial Attribute Set

In its role as a domain controller, a global catalog server stores one domain directory partition that has writable objects with a full complement of writable attributes. In its role as global catalog server, it also stores the objects of all other domain directory partitions in a multidomain forest as read-only objects with a partial set of attributes. The set of attributes that are marked for inclusion in the global catalog are called the partial attribute set (PAS). An attribute is marked for inclusion in the PAS as part of its schema definition.

Objects in the schema that define an attribute are attributeSchema objects, which themselves have an attribute isMemberOfPartialAttributeSet. If the value of that attribute is TRUE, the attribute is replicated to the global catalog. The replication topology for the global catalog is generated automatically by the Knowledge Consistency Checker (KCC), a built-in process that implements a replication topology that is guaranteed to deliver the contents of every directory partition to every global catalog server.

The attributes that are replicated to the global catalog by default include a base set that have been defined by Microsoft as the attributes that are most likely to be used in searches. Administrators can use the Microsoft Management Console (MMC) Active Directory Schema snap-in to specify additional attributes to meet the needs of their installation. In the Active Directory Schema snap-in, you can select the Replicate this attribute to the global catalog check box to designate an attributeSchema object as a member of the PAS, which sets the value of the isMemberOfPartialAttributeSet attribute to TRUE.

Domain Controller and Global Catalog Server Structure

The physical representation of global catalog data is the same as all domain controllers: the Ntds.dit database stores object attributes in a single file. On a domain controller that is not a global catalog server, the Ntds.dit file contains a full, writable replica of every object in one domain directory partition for its own domain, plus the writable configuration and schema directory partitions.

Note

The schema directory partition is writable only on the domain controller that is the schema operations master for the forest.

The following diagram shows the physical representations of the global catalog as a forestwide resource that is distributed as a database on global catalog servers.

Global Catalog Physical Structure

As shown in the preceding diagram, a global catalog server stores a replica of its own domain (full and writable) and a partial, read-only replica of all other domains in the forest. All directory partitions on a global catalog server, whether full or partial, are stored in the directory database file (Ntds.dit) on that server. That is, there is not a separate storage area for global catalog attributes; they are treated as additional information in the directory database of the global catalog server.

The following table describes the physical components of the diagram.

Global Catalog Server Physical Components

Physical Component	Description
Active Directory forest	The set of domains that comprise the AD DS logical structure and that are searchable in the global catalog.
Domain controller	Server that stores one full, writable domain directory partition plus forestwide configuration and schema directory partitions. Global catalog servers are always domain controllers.
Global catalog server	Domain controller that stores one full, writable domain plus forestwide configuration and schema directory partitions, as well as a partial, read-only replica of all other domains in the forest.
Ntds.dit	Database file that stores replicas of the AD DS objects held by any domain controller, including global catalog servers.

Global Catalog Processes and Interactions

In addition to its activities as a domain controller, the global catalog server supports the following special activities in the forest:

• User logon: In a multidomain forest, domain controllers must contact a global catalog server to retrieve any SIDs of universal groups that the user is a member of. Additionally, if the user specifies a logon name in the form of a UPN, the domain controller contacts a global catalog server to retrieve the domain of the user.

• Universal and global group caching and updates: In sites where Universal Group Membership Caching is enabled, domain controllers that are running Windows Server 2003 or later cache group memberships and keep the cache updated by contacting a global catalog server.

• Global catalog searches: Clients can search the global catalog by specifying port 3268 or by using search applications that use this port. Search activities include:

  • Validation of references to non-local directory objects. When a domain controller holds a directory object with an attribute that references an object in another domain, this reference is validated by contacting a global catalog server.

  • Exchange Address Book lookups: Exchange Server uses AD DS as the address book store. Outlook clients query the global catalog to locate Address Book information.

• Global catalog server creation and advertisement: Global catalog servers register global-catalog-specific service (SRV) resource records in DNS so that clients can locate them according to site. If no global catalog server is available in the site of the user, a global catalog server is located in the next closest site, according to the cost matrix that is generated by the KCC from site link cost settings.

• Global catalog replication: Global catalog servers must either have replication partners for all domains or be able to replicate with another global catalog server. When changes to the PAS occur on, and are replicated between, domain controllers that are running Windows Server 2003 or later, only the updated attributes are replicated. Changes to the PAS that occur on domain controllers that are running Windows 2000 Server prompt a full synchronization of the entire global catalog (all attributes in the PAS are replicated anew to all global catalog servers). For more information about PAS replication, see Global Catalog Replication.

User Logon

When a domain user logs on interactively to a domain, the contacted domain controller must retrieve information from a global catalog server under the following conditions:

• The user's domain is Windows 2000 native domain functional level or higher. In this case, the user might belong to a universal group whose object is stored in a different domain.

• The user’s logon name is a user principal name (UPN), which has the format sAMAccountName@DNSDomainName. In this case, the DNS domain suffix is not necessarily the user’s domain and the identity of the user’s domain must be retrieved from a global catalog server.

Universal Group SID Retrieval

A universal group is a security group that is available at the Windows 2000 native domain functional level or higher. During interactive user logon, the authenticating domain controller retrieves the SIDs that the user’s workstation requires to build the access token for the user. To retrieve the SIDs of all universal groups to which the user belongs, the authenticating domain controller must contact a global catalog server. If a global catalog server is not available in the site when a user logs on to a domain in which universal groups are available, the computer will use cached credentials to log the user on if the user has previously logged on to the domain from the same workstation. If the user has not previously logged on to the domain from the same computer, the user can log on to only the local computer.

Of the three group types that are used to allow access to resources in a forest (domain local, global, and universal), only universal groups have their membership replicated to the global catalog. The values of the member attribute of universal group objects that exist in all domains must be available to an authenticating domain controller because:

• Universal groups can contain members, including individual user accounts and global groups, from any domain in the forest. Therefore, the user who is logging on might have a membership in a universal group that exists in a different domain.

• Universal groups can be added to access control lists in any domain in the forest. Therefore, the user might have permissions on objects in this domain by virtue of membership in a universal group that exists in a different domain.

Contrast this requirement with the domain local group membership. Domain local groups can also have members from other domains; however, domain local groups can be added to access control lists in only the domain in which they are created. Therefore, a domain controller can always determine a user’s membership in all domain local groups that are required for authorization in its own domain.

For global groups, although these groups can be added to access control lists in any domain, they can contain accounts from only the domain in which they are created. Therefore, the global group membership of the user who is logging on can always be checked locally. However, global groups can be members of universal groups that exist in different domains. When group nesting is in effect (which has the same availability criteria as availability of universal groups), being a member of a global group that is itself a member of a universal group can give the user access to resources other than those allowed by membership in the global group alone.

During the logon process, the authenticating domain controller retrieves a list of global group SIDs from the user’s domain. If universal groups are available in the user’s domain, the domain controller passes the list of global group SIDs to the nearest global catalog server. The global catalog server responds as follows:

• Enumerates the member attribute of all universal groups in the forest and adds universal group SIDs to the user’s SID list as follows:

  • All universal groups that contain the user’s SID.

  • All universal groups that contain the SID of any of the global groups in the user’s SID list.

• Returns the list, including both universal group SIDs and global group SIDs, to the domain controller.

The authenticating domain controller sends the list of SIDs that is returned from the global catalog server to the user’s computer, along with domain local group SIDs from the user’s domain. The user's local computer, which creates the access token for the user, adds the returned SIDs to the access token.

For more information about how domain controllers cache group membership, see Universal Group Membership Caching. For more information about how SIDs are retrieved and used in access tokens, see “How Access Tokens Work.” For more information about the authentication process, see “How the Kerberos Version 5 Authentication Protocol Works.” For more information about the logon process, see “How Interactive Logon Works.”

UPN Logon

A global catalog server resolves UPNs when the authenticating domain controller does not have knowledge of the account. For example, if a users account is located in noam.corp.contoso.com and the user logs on with a UPN of JSmith@contoso.com, the domain name in the UPN suffix does not match the user’s domain. In the Windows Server 2003 and Windows 2000 Server logon screen, you can either type your user name (sAMAccountName) and select the domain name from the drop-down list, or you can use a UPN. If you use a UPN, as soon as you type the @ sign, the domain list becomes unavailable. In this case, domain controllers running Windows Server 2003 or Windows 2000 Server take the domain name from the UPN suffix. The UPN suffix is often (usually) different from the home domain of the user. In this case, the responding domain controller must contact a global catalog server to determine the domain of the user.

The following diagram shows the general sequence that occurs when a user logs on to a domain by using a UPN.

UPN Logon and Global Catalog Interaction

1. Because the domain of the user is not necessarily the same as the UPN suffix, the domain controller Locator contacts the nearest domain controller according to the site of the client computer.

2. The contacted domain controller determines whether the DNS name in the UPN suffix is the domain for which the domain controller is authoritative.

   • If the domain name in the UPN suffix matches the domain of the domain controller, the domain controller attempts to process the client authentication. If the user name is not found, the domain controller contacts a global catalog server.

   • If the DNS name in the UPN suffix does not match the domain of the domain controller, the domain controller contacts a global catalog server.

3. The global catalog server uses the userPrincipalName attribute of the user object to look up the distinguished name of the user object, and returns this value to the domain controller.

4. The domain controller extracts the domain name from the distinguished name of the user and returns this value to the client.

5. The client requests a domain controller for its domain.

If a forest trust exists between two forests, the default form of a UPN (sAMAccountName@DnsDomainName) is used for authentication in a different forest. If you create a forest trust and the second-level DNS domain name (for example, contoso.com) exists in both forests, the New Trust Wizard detects the conflict and only one forest is authoritative for that name suffix.

If NTLM-based trust relationships are created between the domains in different forests—as is required for a trust relationship between a domain in an Active Directory forest and a Windows NT 4.0 domain, between domains in two Windows 2000 Server forests, or between a domain in a Windows 2000 Server forest and a domain in a Windows Server 2003 forest—a UPN cannot be used to log on to a trusting domain that is outside the forest because the UPN is resolved in the global catalog of only one forest.

Logon Process in a Single-Domain Forest

In a single-domain forest, all domain controllers can service all logon requests, including UPN logons, without requiring a global catalog server. However, only domain controllers that are configured as global catalog servers can respond to LDAP traffic over port 3268.

For more information about the logon process, see “Interactive Logon Technical Reference.” For more information about forest trust relationships, see “Domain and Forest Trusts Technical Reference.”

Universal Group Membership Caching

In multidomain forests where remote sites do not have a global catalog server, the need to contact a global catalog server over a potentially slow WAN connection can be problematic. On domain controllers that are running Windows Server 2003 or later, the Universal Group Membership Caching feature is available by default (does not require a specific functional level or domain mode), although it must be enabled on a per-site basis.

When enabled, this feature allows a domain controller to cache global group SIDs and universal group SIDs that it retrieves from a global catalog server so that future logons do not require contacting a global catalog server. This storage is referred to as “caching,” but the memberships are actually stored in a non-volatile AD DS value. The memberships that are written to this value are not lost as a result of a restart or power outage. For the purposes of this discussion, the term “cache” refers to this value. Group membership is cached for user accounts and computer accounts.

Caching group memberships in branch site locations has the following potential benefits:

• Faster logon times because authenticating domain controllers no longer need to contact a global catalog server to obtain universal group membership.

• Higher availability because logon is still possible if the WAN link to the site of the global catalog server is unavailable.

• No need to upgrade the hardware of existing domain controllers to handle the extra system requirements necessary for hosting the global catalog.

• Minimized network bandwidth usage because a branch site domain controller does not have to replicate all of the objects located in the global catalog.

Enabling Universal Group Membership Caching

Universal Group Membership Caching can be enabled for a site by using the Active Directory Sites and Services MMC snap-in to edit the properties of the NTDS Site Settings object (CN=NTDS Site Settings,CN=TargetSiteName,CN=Sites,CN=Configuration,CN=ForestRootDomain). In Active Directory Sites and Services, if you click a site object, the NTDS Site Settings object for the site is visible in the details pane. Right-click the NTDS Site Settings object and then click Properties. In the NTDS Site Settings Properties dialog box, click Enable Universal Group Membership Caching.

Note

The options attribute of the NTDS Site Settings object, which controls this feature, has a default value of 0. When only the Universal Group Membership Caching option is enabled, the attribute value is 32. However, this attribute is a bit field, so its full functionality is derived from computing a bitwise AND of all of the bits that are set.

When the feature is enabled for a site, domain controllers in the site cache both universal group membership and global group membership for first-time logons and keep the cache updated thereafter. The feature allows specifying the site from which to retrieve group membership. In the NTDS Site Settings Properties dialog box, you can use the Refresh cache from list to specify the site to use. The msDS-Preferred-GC-Site attribute stores the distinguished name of the specified site and controls this setting.

If no site is specified, the closest-site mechanism uses the cost setting on the site link to determine which site has the least-cost connection to contact a global catalog server.

If the user has not logged on to the domain previously and a global catalog server is not available, the user can log on to only the local computer.

Note

If a user is the Administrator in the domain (Builtin Administrator account), the user can always log on to the domain, even when a global catalog server is not available.

For more information about closest-site mechanisms, see “How Active Directory Replication Topology Works” and “How DNS Support for Active Directory Works.”

Global Group and Universal Group SID List

Although the feature is named Universal Group Membership Caching, in fact the domain controller caches both universal group SIDs and global group SIDs. As described in “Universal Group SID Retrieval” earlier in this subject, the authenticating domain controller retrieves the list of universal group SIDs from the global catalog server. The domain controller sends the list of global group SIDs to the global catalog server so that universal group membership can be ascertained for these groups as well as for the user or computer account itself. Therefore, both global group SIDs and universal group SIDs are included in the list of SIDs that is returned from the global catalog server. The domain controller caches the entire list of SIDs. When the account attempts subsequent logons in the site, the universal group and global group SIDs for the account are obtained from the cache. Domain local group SIDs are always obtained from the local directory database.

After a security principal has logged on in a site that has Universal Group Membership Caching enabled, the group cache for the account on the authenticating domain controller is immediately populated. However, it can take up to eight hours for other domain controllers in the same site to populate the group cache. During this time, if the account is authenticated by a domain controller that has not populated the account’s cache, a global catalog server must be contacted for the logon to proceed. After eight hours, all domain controllers that are running Windows Server 2003 or later in the site can process all subsequent logons by using the cached membership.

Group Cache Communication Between Domain Controllers

Although the cache itself is not replicated between domain controllers, knowledge that an account has logged on in the site is replicated to all other domain controllers in the domain by means of a site affinity attribute (msDS-Site-Affinity) of the respective user or computer object. This multivalued attribute identifies the sites in which the account has logged on and includes a timestamp for each site. The domain controllers in the domain use the replicated site affinity attribute to determine which account memberships are cached for their site, and then independently populate their copy of each account’s cache by contacting a global catalog server. For more information about how the cache is populated, see How the Cache is Populated at First Logon and How the Cache is Refreshed. For more information about how this attribute is updated, see Group Cache Storagee.

Cache Refresh and the Availability of Group Changes

The caching of group SIDs in this way, including both universal group and global group SIDs, can lead to unexpected behavior when an administrator modifies the universal group or global group membership for an account and expects the change to be reflected on all domain controllers in the domain after the first replication cycle following the change. Even if the change is made on the domain controller that authenticates the account or has been received through replication, the membership in the cache is used instead of the value of the object member attribute. By default, domain controllers update the membership cache for accounts in the site every eight hours. As a result, changes to the global group or universal group membership of an account can take up to eight hours to be reflected on domain controllers in a site where Universal Group Membership Caching is enabled.

To refresh the cache, domain controllers running Windows Server 2003 or later send a universal group membership confirmation request to a global catalog server. There is no limit to the number of accounts that can be cached, but a maximum of 500 account caches can be updated during any cache refresh.

Note

Universal Group Membership Caching can be enabled in a site that has domain controllers that are running Windows 2000 Server. If Universal Group Membership Caching is enabled in such a site, users might experience inconsistent group membership, depending on which domain controller authenticates them. For this reason, it is recommended that you either upgrade all domain controllers that are running Windows 2000 Server to Windows Server 2003 or later when group caching is enabled in a site, or remove them.

Because the group memberships are cached, there is a period of latency before group membership changes are reflected in an account’s access token. When group membership changes, the changes are not reflected in the access token until the following events have occurred (in order):

1. The changes are replicated to the global catalog server that is used for the refresh of the cache.

2. The cache on the domain controllers in the account’s site is refreshed. Although the cache refresh is not a replication event, the process uses the site link schedule. Therefore, a closed site link schedule postpones the cache refresh until the schedule opens.

3. The user has logged off and back on again (user account is authenticated) or the computer has restarted (computer account is authenticated).

When an access token is created during logon, the token contents are static until that user logs off and logs on again. Furthermore, as long as Universal Group Membership Caching is enabled, an account’s memberships are cached, and the cache entry has not expired, the cache entry is used during logon. If changes have been made to group membership and the refresh task has not run, the changes are not reflected until either the cache entry expires or the refresh task runs and processes the cache entry.

The length of the latency period depends on when the next refresh task is scheduled to run. The refresh task reschedules itself for its next refresh during each current refresh run, as follows:

• Beginning with the current time plus the registry-configured refresh interval, the domain controller consults the replication schedule on the site link that connects its site to the site of the closest (or designated) global catalog server.

• If the site link schedule allows replication at the projected time, the refresh task is scheduled to run at this time.

• If the site link schedule does not allow replication at the projected time, the scheduling algorithm steps forward one minimum replication interval (15 minutes) and checks the schedule again.

• This process is repeated until an open replication interval is found. If no open interval is found in the seven-day schedule, the refresh task is scheduled to run by using a time calculated as the current time plus the registry-configured refresh interval. In this case, event ID 1671 is logged as a warning message that indicates the group membership cache refresh task was unable to find the next available time slot of connectivity to the site of the global catalog server.

If faster updates are required, an administrator can initiate a cache refresh manually on the domain controllers in the user’s site. For more information about refreshing the user cache, see Registry Settings that Affect Cache Refresh and Site Affinity Limits.

Determining the Site to Use for Populating and Refreshing the Cache

You can designate a site from which to initially populate and subsequently refresh the group membership cache. The Universal Group Membership Caching feature user interface (UI) contains an option to select a site from the list of existing sites. When a site has been selected and the cache on a domain controller must be populated for the first time or updated, the domain controller contacts a global catalog server in the designated site. If no site is designated, site link costs are evaluated to determine the lowest-cost site that contains a global catalog server. The site link cost matrix is supplied by the Intersite Messenger (ISM) service.

The UI that you use to designate a preferred site for cache refresh does not check for the presence of a global catalog server in the selected site. Therefore, it is possible to designate a refresh site that does not contain a global catalog server. In this case, or in any case where a refresh site is designated but a global catalog server does not respond, the domain controller uses the site link cost matrix and logs event ID 1668 in the Directory Service log in Event Viewer, which indicates that the group membership cache refresh task did not locate a global catalog in the preferred site, but was able to find a global catalog in the following available site. The event lists the named preferred site and the actual site that was used.

Group Cache Storage

Cached group membership is stored as additional attributes of user and computer objects. Three attributeSchema objects in the AD DS schema for the user object class (and inherited by the computer object class) support this feature:

• msDS-Cached-Membership: (cached membership) A binary large object (BLOB) that contains both universal and global group memberships (the group SIDs) for the user. This attribute has the following characteristics:

  • Is single valued.

  • Is not indexed.

  • Can be deleted.

  • Cannot be written.

  • Is not replicated.

• msDS-Cached-Membership-Time-Stamp: (last refresh time) Contains the time that the cached membership was last updated, either by the first logon or by a refresh. This attribute is used for the “staleness” check. The maximum period that is tolerated when using a cached group membership is called the staleness interval. The staleness interval, set in the registry as 7 days, is measured against the current time and the last refresh time. If the timestamp indicates that the cache is older than the staleness interval allows, the cached membership is invalidated and a global catalog server is required for logon. This attribute has the following characteristics:

  • Is large integer, time valued.

  • Is indexed.

  • Can be deleted.

  • Cannot be written.

  • Is not replicated.

• msDS-Site-Affinity: Identifies the site(s) where the account has logged on plus a timestamp that indicates the start time for the cached logon in the respective site. Presence of a value in this attribute causes automatic population of group memberships and refresh at every refresh interval. When a domain controller refreshes its cached memberships (every 8 hours by default), the timestamp is used for removing accounts from the cache that have not logged on within the site affinity time limit (the cache expires). To avoid replication of this attribute every time the account logs on, the timestamp is updated only when the age exceeds 50 percent of the age limit that is set in the registry (180 days, by default) and one of the following actions occurs:

  • The account logs on and is authenticated by a domain controller.

  • A user changes his or her account password. This update ensures that users who go for extended periods without logging on have their site affinity values updated.

  This attribute has the following characteristics:

  • Is multivalued.

  • Is indexed.

  • Can be deleted.

  • Can be written.

  • Is replicated.

Note

You can use ADSI Edit in Windows Support Tools to clear the cached entries for an account by deleting the values in msDS-Cached-Membership and msDS-Cached-Membership-Time-Stamp from the user or computer object. The attribute values are repopulated at the next logon or cache refresh, whichever comes first.

Registry Settings that Affect Cache Refresh and Site Affinity Limits

Registry settings on each domain controller determine the limits that are imposed on group membership caches. The entries in the following table are under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\, unless otherwise noted, and they can be used to manage the cache.

Changes to these registry settings take effect the next time the refresh task runs.

Note

In the following table, some of the entry names contain the string “(minutes)”. Note that this string is part of the entry name and must be included when creating the entry. For example:

• The value name Cached Membership Refresh Interval (minutes) is correct.
  
  
• The value name Cached Membership Refresh Interval is incorrect.
  
  

Registry Entries Used to Configure Caching Behavior

Registry Entry	Type	Default Value	Notes
Cached Membership Site Stickiness (minutes)	DWORD	172800 (Value is in minutes. This setting equals 180 days)	Defines how long the site affinity will remain in effect. The site affinity value is updated when half of the period defined by this value has expired. If an account has not logged on with a domain controller for a period of one half of this value or longer, the account is removed from the list of accounts whose memberships are being refreshed. The default value is recommended.
Cached Membership Staleness (minutes)	DWORD	10080 (Value is in minutes. This setting equals 7 days)	Determines the maximum staleness value when using cached group membership. The account cannot log on if the cached membership list is older than the staleness value and if no global catalog server is available. The default value is recommended.
Cached Membership Refresh Interval (minutes)	DWORD	480 (Value is in minutes. This setting equals 8 hours)	Defines the length of time between group membership cache refreshes. This value should be changed to synchronize once a day (1440 minutes). For dial-up connections, you might want a higher value than 24 hours. Lowering the value to increase the frequency of cache refresh is not recommended because it causes increased WAN traffic, potentially defeating the purpose of Universal Group Membership Caching.
Cached Membership Refresh Limit	DWORD	500	Defines the maximum number of user and computer accounts that are refreshed. Increase this setting only if event ID 1669 occurs in the event log or you have more than 500 users and computers in a branch. If the number of users and computers in a branch exceeds 500, a general recommendation is to either place a global catalog server in the branch or increase the Cached Membership Refresh Limit above 500. Be aware that increasing the limit might incur more WAN traffic than that caused by global catalog update traffic.
SamNoGcLogonEnforceKerberosIpCheck This setting appears under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.	DWORD	0	By default, allows site affinity to be tracked for Kerberos logons that originate outside the site. A value of 1 configures SAM so it does not give site affinity to Kerberos logon requests that originate outside the current site. This option should be configured to 1 on domain controllers in the branch-sites to prevent logon requests from outside the site being given affinity for the local site. This setting prevents an account’s affinity from being changed during the logon process when connecting to a Kerberos key distribution center (KDC) outside of the account’s site. This setting applies only to Kerberos logons; it does not affect site affinity caching for NTLM logons from different sites.
SamNoGcLogonEnforceNTLMCheck This setting appears under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.	DWORD	0	A value of 1 configures SAM to not give site affinity to NTLM logon requests that are network logon requests; it may not prevent caching for other logon types. This setting reduces the number of accounts with site affinity by excluding those that simply accessed network resources (by using NTLM). This option should not be enabled if you use older clients that must authenticate from outside the branch to local resources in the branch.

Note

To minimize the probability that remote users will use the UGC-enabled branch domain controller for logon, remove the domain controller for site-less SRV records from DNS by using the DnsAvoidRegisterRecords parameter for Netlogon. For more information about using DnsAvoidRegisterRecords, see Microsoft Knowledge Base article 306602 (https://go.microsoft.com/fwlink/?LinkId=126645).

Methods of Refreshing the Cached Memberships

You can refresh cached memberships on a single domain controller.

For a one-time, immediate cache refresh:

• Use Ldp.exe to modify the operational attribute updateCachedMemberships on the rootDSE with a value of 1. Adding a value of 1 to this attribute instructs the local domain controller to perform the update. If the site link schedule allows replication at the time you modify the attribute, this update occurs right away. This method is the preferred method for updating a single domain controller because it does not require restarting the domain controller. For information about using Ldp to modify this attribute, see the Note below. Ldp.exe can be installed from Windows Support Tools in Windows Server 2003 and Windows 2000 Server, and it is installed by default on domain controllers that run Windows Server 2008 and Windows Server 2008 R2.

  -or-

• Restart the domain controllers in the site to restart the cache refresh interval, which triggers a cache refresh.

• Use the following procedure to modify the updateCachedMemberships operational attribute. To perform this operation, the user needs the control access right "Refresh Group Cache for Logons" on the NTDS Settings object for the domain controller. Default access is granted to System, Domain Admins, and Enterprise Admins.

1. Start Ldp.exe and bind to the target domain controller where the cache reset is to be performed. (Do not select Tree view in the View menu.) When first binding to a domain controller with Ldp, the default location is rootDSE. You can view the attributes for rootDSE in the details pane. However, operational attributes are not listed.

2. On the Browse menu, click Modify.

3. In the Modify dialog box, in the Edit Entry Attribute box, type updateCachedMemberships. In the Values box, type 1. Be sure to leave the Dn box blank.

4. Click Enter. The command should appear in the entry list.

5. Click Run. If the operation was successful, Ldp will report “Modified” in the output.

Method of Clearing the Cached Memberships

You can clear all cached memberships on all domain controllers in a site. However, doing so can affect performance. The need to clear the cached memberships might arise due to too many cached accounts, causing inability to refresh all account caches during a single cache refresh. For example, sites that have many transient accounts might exceed the 500-account refresh limit.

If you have more than 500 accounts cached and you want to clear them for all domain controllers in the site, you can do so by editing the registry.

Note

If you must edit the registry, use extreme caution and be sure that you back it up first. Registry information is provided here as a reference for use by only highly skilled directory service administrators. Do not directly edit the registry unless, as in this case, no Group Policy setting or other Windows tools can accomplish the task. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. Storage of incorrect values can result in unrecoverable errors in the system.

On one domain controller, you can set the Cached Membership Site Stickiness (minutes) registry entry to 0 and then initiate a cache refresh by using the operational attribute method on that domain controller, as described in “Methods of Refreshing the Cached Memberships” earlier in this subject. The 0 value in the setting causes the cache to be purged—values in all three attributes (msDS-Cached-Membership, msDS-Cached-Membership-Time-Stamp, and msDS-Site-Affinity) are cleared. After the site stickiness attribute deletion has replicated within the site, you can then initiate cache refresh on the other domain controllers in the site. Remember to return the value in Membership Site Stickiness (minutes) to its default value of 180.

Diagnostic Logging Levels and Events

Diagnostic logging for Universal Group Membership Caching can be set in the registry entry 20 Group Caching under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Data type: REG_DWORD

Value range: 0-5

Default value: 0

Significant events are reported at logging level 2 with many additional events reported at logging level 5. For troubleshooting, set the logging level to 5.

Sample Events at Logging Level 0

Event ID 1667: The group membership cache refresh task detected that the following site in which a global catalog was found is not one of the cheapest sites, as indicated by the published site link information.

Event ID 1668: The group membership cache refresh task did not locate a global catalog server in the preferred site, but was able to find a global catalog server in the following available site. Preferred site: <site name> Available site: <site name>

Event ID 1669: The group membership cache refresh task has reached the maximum number of users for the local domain controller.

Event ID 1670: The group membership cache refresh task is behind schedule. Consider forcing a group membership cache update.

Sample Events at Logging Level 2

Event ID 1776 internal event: The group membership cache task is starting.

Event ID 1777 internal event: The group membership cache task has finished. The completion status was 0, and the exit Internal ID was ######.

Event ID 1779 internal event: The Global Catalog Domain Controller <dcname> in site <site name>, domain <domain name> will be used to update the group memberships.

Event ID 1781 internal event: By examining the published connectivity information, the group membership cache task has determined site <site name> is a site with a low network cost to contact. The task will schedule itself based on the schedule of network connectivity to this site.

Event ID 1782 internal event: By examining the published connectivity information, the group membership cache task cannot find an efficient site to obtain group membership information. The task will run using the global catalog server that is closest, as determined by the Net Logon locator, and will schedule itself based on a fixed period.

Event ID 1842 internal event: The following site link will be used to schedule the group membership cache refresh task. Site link: <distinguished name of site link>

Sample Events at Logging Level 5

Event ID 1778 internal event: The group membership cache task will run again in xx minutes.

Event ID 1784 internal event: The group membership cache task determined that site <distinguished name of site> does not have a global catalog server.

How the Cache is Populated at First Logon

By default, the caching attributes on the user and computer objects are not populated. The following diagram shows how the domain controller builds the list of SIDs to be cached and where in the process the caching attributes are populated during the user’s first logon in the site. This example assumes that the user is in a site that has Universal Group Membership Caching enabled, the domain of the client workstation is the same as the domain of the user, and the domain has a functional level that allows universal groups.

Universal Group Membership Caching Process at First Logon

The following events occur at each step in the preceding diagram:

1. A user logs on in a site where Universal Group Membership Caching is enabled. The user is authenticated by the domain controller as being the requesting user.

2. The domain controller checks the values of the three caching attributes of the user object.

3. Finding that the attributes are not populated, the domain controller checks its local directory and retrieves the SID of the user (including SID history, if available) and the SIDs of all global groups to which the user belongs.

4. The domain controller sends this list of SIDs to the global catalog server. The global catalog server checks the universal group memberships of the user and all global groups in the list. The global catalog server returns the list of combined universal group and global group SIDs to the domain controller.

5. The user’s cache attributes are populated as follows:

   1. The combined list of global group and universal group SIDs is recorded in the msDS-Cached-Membership attribute.

   2. The time is recorded in the msDS-Cached-Membership-Time-Stamp attribute (this time indicates the last time the cache was updated; on the first logon, it also happens to be the time the user logged on).

   3. If SamNoGcLogonEnforceNTLMCheck or SamNoGcLogonEnforceKerberosIpCheck, or both, are enabled on the domain controller, the msDS-Site-Affinity attribute is ignored.

   4. If the GUID for the local site exists in the msDS-Site-Affinity attribute and the settings in step c. are not enabled, the timestamp value in msDS-Site-Affinity is evaluated as follows: If the value indicates an age that is less than half the value in Cached Membership Site Stickiness (minutes), the logon proceeds. If the timestamp indicates an age that is greater than half the value in Cached Membership Site Stickiness (minutes), or if the attribute is not populated, the site GUID and time are written to the msDS-Site-Affinity attribute, and the logon proceeds.

6. The domain controller checks its local directory for any domain local groups to which the user belongs and adds domain local group SIDs to its list of global group and universal group SIDs.

   Note

   The process for accomplishing Step 6 differs depending on whether the domain of the client computer is the same as the domain of the user and, if not, whether the client computer is joined to a domain that has a mixed domain mode or functional level, or a native domain mode or functional level. For more information about how SIDs are retrieved and added to access tokens, see “Access Tokens Technical Reference.”

7. The domain controller sends the entire list of SIDs to the client computer, where the LSA retrieves SIDs of the user’s built-in group memberships and constructs the user’s access token.

Note

Global catalog servers in a site where caching is enabled do not populate the msDS-Cached-Membership and msDS-Cached-Membership-Time-Stamp attributes of users they authenticate. Because global catalog servers are already aware of universal group memberships throughout the forest and global group memberships for the domain, there is no need for them to use these attributes.

How the Cache is Used for Subsequent Logons

When Universal Group Membership Caching is enabled in the site, the following sequence occurs during account logon:

1. The account is authenticated by the contacted domain controller.

2. The domain controller checks for the presence of values in the caching attributes of the respective user or computer object. If the attribute values are present, the domain controller updates the values as follows:

   1. If the value in the msDS-Cached-Membership-Time-Stamp attribute indicates an age that is less than the staleness interval (Cached Membership Staleness (minutes), default seven days), the domain controller reads the group SIDs from the msDS-Cached-Membership attribute and the logon proceeds.

   2. If the value in msDS-Cached-Membership-Time-Stamp indicates an age of greater than the staleness interval, the domain controller contacts a global catalog server to request the universal group membership. If a global catalog server cannot be contacted, the logon is denied.

   3. If the value in the timestamp in msDS-Site-Affinity is equal to or older than 50 percent of the site stickiness setting, the timestamp is updated with the current time.

3. The domain controller returns the group SIDs from the cache plus any domain local group SIDs to the client computer and the logon proceeds.

Note

At no time during a successful logon does the local domain controller check with a global catalog server to see if the account’s group membership has changed. Changes to an account’s group membership are not reflected in the account’s access token until the local domain controller performs a cache refresh. The default amount of time between cache refreshes is eight hours. This interval could result in an inconsistent view of group membership if the account was authenticated by a domain controller in a different site. This discrepancy might also confuse administrators who are unfamiliar with how universal group membership caching works.

How the Cache is Refreshed

The cache refresh process occurs automatically on every domain controller that is running Windows Server 2003 or later and has received replication of the msDS-Site-Affinity attribute update for a user or computer object or has already cached group memberships. The refresh operation occurs differently depending on whether a site is selected for the preferred refresh site.

Cache Refresh Process When a Preferred Refresh Site is Not Selected

When the refresh interval expires, the domain controller proceeds as follows:

1. Lists all the site links that connect the domain controller’s site to a site that hosts a global catalog server in increasing order of cost values on the site link objects.

2. Selects the lowest-cost site link and schedules the refresh by using the site link schedule. If no site link schedule is set, then replication is always available. Depending on the schedule, the refresh proceeds as follows:

   • If the schedule currently allows replication, the domain controller begins the refresh.

   • If the schedule does not currently allow replication, the domain controller schedules the refresh to begin when the schedule allows replication.

     Note

     When the refresh is postponed according to the site link schedule, a random stagger in the range of 0-15 minutes is added to the computed start time. Schedule staggering has the effect of ensuring that domain controllers begin their refresh at slightly different times, thereby improving load balancing on the global catalog server.

   • When the schedule allows replication, begins the refresh by locating and binding to a global catalog server in the next closest site.

   • Removes accounts that have a populated cache but no site affinity. Cached entries that do not include a populated msDS-Site-Affinity value are purged at this time. A maximum of 64 entries are removed at a time. If more entries need to be removed, they are removed during subsequent refreshes.

   • Removes any account whose site affinity matches the local site, but whose site affinity time period has expired. In this case, the values in the three cache attributes are deleted and this account no longer has a group membership cache on the domain controller.

   • Builds a list of accounts by querying the global catalog for all accounts that have GUIDs in their msDS-Site-Affinity attribute that match the GUID of the domain controller’s site.

   • Updates cache attributes of the accounts in the list by querying the global catalog for each account’s group membership, as follows:

     • Update the msDS-Cached-Membership attribute with the account’s group membership SIDs.

     • Update the msDS-Cached-Membership-Time-Stamp attribute with the time of refresh.

   • Repeats the process for each account until all accounts are updated or until the refresh limit of 500 accounts is reached. If the refresh limit is reached, the domain controller logs event ID 1669 in the Directory Service event log, and the refresh stops.

   • Checks to ensure that the refresh task has not fallen behind in terms of the maximum period allowed for an account’s cached membership list to be valid for logons. This step is accomplished by locating the record with the oldest msDS-Cached-Membership-Time-Stamp value and comparing the timestamp value to the staleness interval (seven days by default). If the entry is more than seven days old, the domain controller logs event ID 1670, indicating that the refresh task has fallen behind.

     Note

     When the domain controller encounters the refresh limit, it stops updating cache entries. Because the order in which the updates occur cannot be predicted, there is no way to ensure that the caches of the most recent accounts are updated. The staleness check in step 9 checks all cached entries, even those excluded due to exceeding the refresh limit. After about one week, the non-updated cache entries will become stale and cause the falling behind error to be reported in the event log.

     Note

     • When the domain controller encounters the refresh limit, it stops updating cache entries. Because the order in which the updates occur cannot be predicted, there is no way to ensure that the caches of the most recent accounts are updated. The staleness check in step 9 checks all cached entries, even those excluded due to exceeding the refresh limit. After about one week, the non-updated cache entries will become stale and cause the falling behind error to be reported in the event log.

Cache Refresh Process When A Preferred Refresh Site is Selected

When a site is selected to always be used for refreshing the group membership cache, the domain controller does not need to order the site links according to cost, but simply contacts a global catalog server in the specified site. However, if no global catalog server is available at the time the refresh is attempted, the domain controller logs event ID 1782, indicating that a domain controller could not be found in the preferred site, and uses the site link cost to locate a global catalog server in the next closest site.

Inconsistent Access to Domain-Based Objects on Global Catalog Servers

When specifying Read or List permissions for domain data that is also replicated to the global catalog, use global groups rather than domain local groups because the access token that is created for the user by the global catalog server does not necessarily contain information about domain local groups to which the user belongs.

When a user connects to a global catalog server, an access token is created for the user that is used in subsequent access decisions on the server. If the user is a member of a domain other than the domain of the global catalog server, the global catalog server contacts a domain controller in the user’s domain to authenticate the user and retrieve authorization data. The domain controller returns information about the user, including the SIDs of global groups in the user’s domain to which the user belongs. The domain controller from the user's domain does not return domain local group SIDs to the global catalog server.

Universal group membership is retrieved from the global catalog, and the global catalog server looks to its own domain (which is not necessarily the domain of the user) for any domain local groups to which the user belongs. Thus the access token for the user on the global catalog server contains the global groups and universal groups to which the user belongs, as well as any domain local groups to which the user belongs in the domain of the global catalog server.

The effect of a missing domain local group SID in the user’s access token is that the user’s access to global catalog data is unpredictable. For example, if access to the homePhone attribute of a user object is restricted by a domain local group in the user's domain, and the user is a member of that group, the user is able to view that attribute in the global catalog when both of the following conditions are true:

• The homePhone attribute is replicated to the global catalog.

• The global catalog server to which the user connects does not host a writable copy of the user’s domain.

Similarly, if the user is a member of a domain local group in a domain other than the domain hosted by the global catalog server, and that group is granted read access to the homePhone attribute, the user cannot view that attribute in the global catalog.

Global Catalog Searches

The location of an object in AD DS is provided by the distinguished name of the object, which includes the full path to a replica of the object, culminating in the directory partition that holds the object. However, the user or application does not always have the distinguished name of the target object, or even the domain of the object. To locate objects without knowing the domain, the most commonly used attributes of the object are replicated to the global catalog. By using these object attributes and directing the search to the global catalog, requesters can find objects of interest without having to know their directory location. For example, to locate a printer, you can search according to the building of the printer. To locate a person, you can provide the name of the person. To locate all people who are managed by someone, you can provide the manager’s name.

LDAP Search Ports

AD DS uses the Lightweight Directory Access Protocol (LDAP) as its access protocol. LDAP search requests can be sent and received by AD DS on port 389 (the default LDAP access port) and port 3268 (the default global catalog port). LDAP traffic that uses the Secure Sockets Layer (SSL) authentication protocol accesses ports 636 and 3269, respectively. In this discussion, search behavior that applies to ports 389 and 3268 also apply to the respective behavior of LDAP queries over ports 636 and 3269.

When a search request is sent to port 389, the search is conducted on a single domain directory partition. If the object is not found in that domain or the schema or configuration directory partitions, the domain controller refers the request to a domain controller in the domain that is indicated in the distinguished name of the object.

When a search request is sent to port 3268, the search includes all directory partitions in the forest — that is, the search is processed by a global catalog server. If the request specifies attributes that are part of the PAS, the global catalog can return results for objects in any domain without generating a referral to a domain controller in a different domain. Only global catalog servers receive LDAP requests through port 3268. Certain LDAP client applications are programmed to use port 3268. Even if the data that satisfies a search request is available on a regular domain controller, if the application launching the search uses port 3268, the search necessarily goes to a global catalog server.

Search Criteria That Target the Global Catalog

Searches are directed to a global catalog server under the following conditions:

• You specify port 3268 or 3269 in an LDAP search tool.

• You select Entire Directory in a search-scope list in an AD DS snap-in or search tool, such as Active Directory Users and Computers or the Search command on the Start menu.

• You write the distinguished name as an attribute value, where the distinguished name represents a nonlocal object. For example, if you are adding a member to a group and the member that you are adding is from a different domain, a global catalog server verifies that the user object represented by the distinguished name exists and obtains its GUID.

Characteristics of a Global Catalog Search

The following characteristics differentiate a global catalog search from a standard LDAP search:

• Global catalog queries are directed to port 3268, which explicitly indicates that global catalog semantics are required. By default, ordinary LDAP searches are received through port 389. If you bind to port 389, even if you bind to a global catalog server, your search includes a single domain directory partition. If you bind to port 3268, your search includes all directory partitions in the forest. If the server you attempt to bind to over port 3268 is not a global catalog server, the server refuses the bind.

• Global catalog searches can specify a non-instantiated search base, indicated as "com" or " " (blank search base).

• Global catalog searches cross directory partition boundaries. The extent of the standard LDAP search is the directory partition.

• Global catalog searches do not return subordinate referrals. If you use port 3268 to request an attribute that is not in the global catalog, you do not receive a referral to it. Subordinate referrals are an LDAP response; when you query over port 3268, you receive global catalog responses, which are based solely on the contents of the global catalog. If you query the same server by using port 389, you receive referrals for objects that are in the forest but whose attributes are not referenced in the global catalog.

  Note

  A referral to a directory that is external to AD DS can be returned by the global catalog if a base-level search for an external directory is submitted and if the distinguished name of the external directory uses the domain component (dc=) naming attribute. This referral is returned according to the ability of AD DS to construct a Domain Name System (DNS) name from the domain components of the distinguished name and is not based on the presence of any cross-reference object. The same referral is returned by using the LDAP port; it is not specific to the global catalog.

Because the member attribute is not replicated to the global catalog for all group types, and because the memberOf attribute derives its value by referencing the member attribute (called back links and forward links, respectively), the results of searches for members of groups and groups of which a member belongs can vary, depending on whether you search the global catalog (port 3268) or the domain (port 389), the kind of groups that the user belongs to (global groups or domain local groups), and whether the user belongs to universal groups outside the local domain.

For more information about global catalog searches and the implications of searching on back links and forward links, see “How Active Directory Searches Work.”

The Infrastructure Master and Phantom Records

An attribute that has a distinguished name as a value references (points to) the named object. When the referenced object does not actually exist in the local directory database because it is in a different domain, a placeholder record called a phantom is created in that database as the object reference. Because there is a reference to it, the referenced object must exist in some form, either as the full object (if the domain controller stores the respective domain directory partition) or as an object reference (when the domain controller does not store that domain).

The infrastructure master is a single domain controller in each domain that tracks name changes of referenced objects and updates the references on the referencing object. When a referenced object is moved to a different domain (which effectively renames the object), the infrastructure master updates the distinguished name of the phantom. The infrastructure master finds phantom records by using a database index that is created only on domain controllers that hold the infrastructure operations master role. When the reference count of the phantom falls to zero (no objects are referencing the object that the phantom represents), garbage collection on each domain controller removes the phantom.

Because objects can reference objects in different domains, the infrastructure operations master role is not compatible with global catalog server status if more than one domain is in the forest. If a global catalog server holds the infrastructure operations master role, phantom records are never created because the referenced object is always located in the directory database on the global catalog server.

For more information about the infrastructure operations master role, see “How Operations Masters Work.”

Exchange Address Book Lookups

The Exchange Server directory service is integrated with AD DS. When mail users want to find a person within their organization, they usually search the global address book (GAL), which is an aggregation of all messaging recipients in the enterprise, including mailbox-enabled users, mail-enabled users, groups, and contacts. The GAL is a virtual linked list of pointers to the mail recipient objects that comprise it. Mail recipients can be user accounts (both enabled and disabled accounts), contacts, distribution lists, security groups, and folders. The GAL is automatically populated by a service on the Exchange Server, and user’s can create customized address lists. Exchange Server uses the global catalog to generate the GAL.

Every Outlook client is configured with the name of an Exchange server. Exchange servers use AD DS and DNS to locate a global catalog server. When an Outlook client user opens the Address Book, or when a user composes a message and types a name or an address in the To: field, the Outlook client uses the global catalog server that is specified by its Exchange server to search the contents of the GAL or other address lists.

For more information about how Outlook clients locate address information in the global catalog, see “How Active Directory Searches Work.”

Global Catalog Server Creation and Advertisement

You can designate a domain controller as a global catalog server by simply selecting the Global catalog check box in the properties of the NTDS Settings object, located beneath each server object in Active Directory Sites and Services. On servers that run Windows Server 2008 R2 or Windows Server 2008, you can also designate a domain controller as a global catalog server during AD DS installation. However, for search clients and other domain controllers in the forest to locate it, the global catalog server must register itself in DNS.

The Net Logon service on a domain controller registers service (SRV) resource records in DNS that identify the domain controller so that it can be located. In the case of a global catalog server, additional SRV resource records are registered to identify the server as a global catalog server. These SRV resource records contain the server name, the forest name, and the site name for the global catalog server. DNS queries for these records return all global catalog servers in the requested site. When a client requests a global catalog server by launching an LDAP search over port 3268, the domain controller Locator on the client queries DNS for a domain controller that hosts the global catalog. For more information about how domain controllers and global catalog servers are located, see “How DNS Support for Active Directory Works.”

By default, before a domain controller advertises itself as a global catalog server in DNS, the global catalog contents must be replicated to the server. This process involves replication of a partial, read-only replica of every domain in the forest except for the domain for which the new global catalog server is authoritative. The duration of this process depends on how many domains the forest contains, the size of the domains, and the relative locations of source and destination domain controllers. If multiple domains are in the forest and if source domain controllers are located only in distant sites, the process takes longer than if all domains are in the same site or in only a few sites. When replication must occur between sites to create the global catalog, replication occurs according to the site link schedule.

When creating a new global catalog server, the process can be delayed by several conditions, including the following:

• The KCC could not reach a source domain controller from which to replicate a directory partition.

• Replication cannot begin until the scheduled time.

• Replication of the directory partition is in progress but has not yet completed. This delay might occur if the directory partition is very large. In addition, the replication priority queue prioritizes addition of new directory partitions at a lower priority than incremental replication of existing partitions.

• The source domain controller for a directory partition has gone offline or is unavailable due to network problems.

These conditions are logged in the Directory Service log when the logging level is set to 0 (the default setting) in the Global Catalog entry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\. If you want to receive more information, you can increase the logging level by editing this entry.

Warning

If you must edit the registry, use extreme caution and be sure that you back it up first. Registry information is provided here as a reference for use by only highly skilled directory service administrators. Do not directly edit the registry unless, as in this case, no Group Policy setting or other Windows tools can accomplish the task. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. Storage of incorrect values can result in unrecoverable errors in the system.

Requirements for Global Catalog Readiness

By default, a global catalog server is not considered “ready” (the server advertises itself in DNS as a global catalog server) until all read-only directory partitions have been fully replicated to the new global catalog server. The Global Catalog Partition Occupancy registry entry under HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters determines the requirements for how many read-only directory partitions must be present on a domain controller for it to be considered a global catalog server, from no partitions (0) to all partitions (6).

For domain controllers that run Windows Server 2003 or later, the default occupancy value requires that all read-only directory partitions be replicated to the global catalog server before the Net Logon service registers SRV resource records in DNS. For most conditions, this default provides the best option for ensuring that a global catalog server provides a consistent view of the directory. In less common circumstances, however, it might be useful to make the global catalog server available with an incomplete set of partial domain directory partitions—for example, when delay of replication of a domain that is not required by users is jeopardizing their ability to log on.

The Global Catalog Partition Occupancy entry can have the values shown in the following table.

Global Catalog Partition Occupancy Level Values

Value	Description
0	No occupancy requirement. Removing the occupancy level requirement might be useful in a scenario where domain controllers are being staged for deployment but are not yet in production.
1	At least one read-only directory partition in the site has been added by the KCC. This level, as well as level 3 and level 5, provide the ability to distinguish between a source for the directory partition being reachable (at least one object has been returned) and the entire directory partition having been replicated (as in levels 2, 4, and 6). When the KCC can reach the first object, it can create a replica link, which is the agreement between the source and destination domain controllers to replicate to the destination. If the KCC cannot reach a source, the KCC logs event ID 1558 in the Directory Service log, which indicates the distinguished name of the directory partition that has not been fully synchronized. In this case, the KCC continues to try to replicate the partition each time it runs (every 15 minutes by default). When the KCC succeeds in creating the replica link, it passes responsibility for retrying and completing the synchronization to the replication engine. The KCC then stops logging events, after which the replication status can be checked by using the repadmin/showrepl command.
2	At least one read-only directory partition in the site has been fully synchronized.
3	All read-only directory partitions in the site have been added by the KCC (at least one has been fully synchronized). In this case, the KCC has been able to contact one source for every directory partition in the site. This level is useful when you want to advertise a global catalog server as soon as possible with a high likelihood of success.
4	All read-only directory partitions in the site have been fully synchronized. With this setting, if a source for any directory partition is not available, DNS registrations cannot occur. On domain controllers that are running Windows 2000 Server with Service Pack 1 (SP1) or Windows 2000 Server with Service Pack 2 (SP2), this occupancy level is the default requirement before the global catalog server is advertised in DNS.
5	All read-only directory partitions in the forest have been added by the KCC (at least one has been fully synchronized).
6	All read-only directory partitions in the forest have been fully synchronized. On domain controllers that are running Windows Server 2003 or Windows 2000 Server with SP3 or later, this occupancy level is the default requirement before the global catalog server is advertised in DNS. This setting ensures the highest level of consistency.

Event ID 1578 reports the level that is required and the level that the domain controller has achieved.

Advertising a Global Catalog Server Prior to Full Synchronization

By default, a domain controller checks every 30 minutes to see whether it has received all of the read-only directory partitions that are required to be present before the server advertises itself in DNS as a global catalog server. Event ID 1110 indicates that the promotion is being delayed because the required directory partitions have not all been synchronized.

This delay is controlled by the Global Catalog Delay Advertisement (sec) registry entry under HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters\. If you set a value for Global Catalog Delay Advertisement (sec), it overrides the requirements set in Global Catalog Partition Occupancy and allows global catalog advertisement without requiring full synchronization of all read-only directory partitions.

When conditions preclude the successful synchronization of the new global catalog server, you can force advertisement of the global catalog server and then remove the global catalog from the server. Until the global catalog server is successfully advertised, you are unable to remove it.

Replication Process for Global Catalog Creation

When you designate a domain controller to be a global catalog server, the Knowledge Consistency Checker (KCC) on the domain controller runs immediately and updates the replication topology. When the KCC runs, it checks to see whether the Global Catalog option is selected for any domain controllers, and creates the replication topology accordingly. The KCC configures the newly selected global catalog server to be the destination server for a read-only replica of every domain directory partition in the forest except for the writable domain directory partition that the server already holds. The KCC on the global catalog server must be able to reach a server that will be the source of each read-only directory partition.

When the KCC locates an available source domain controller, it creates an inbound connection on the new global catalog server and replication of that read-only partition takes place. If the source is within the site, replication begins immediately. If the source is in a different site, replication begins when it is next scheduled. Replication of all objects in the partial directory partition must complete successfully before the directory partition is considered to be present on the global catalog server.

Successful Completion of Global Catalog Creation

When all directory partitions are present, the domain controller sets its rootDSE isGlobalCatalogReady attribute to TRUE and the Net Logon service on the domain controller registers SRV resource records that specifically advertise the global catalog server in DNS. At this point, the global catalog is considered to be available, and event ID 1119 is logged in the Directory Service log.

Global Catalog Replication

Although read-only directory partitions on global catalog servers cannot be updated directly by administrative LDAP writes, they are updated through AD DS replication when changes occur to their respective writable replicas.

The following diagram represents the AD DS database on a global catalog server in the corp.contoso.com forest root domain. A global catalog server has a single directory database. However, to represent the different logical directory partitions in the forest, the diagram shows database divided into segments. The top three segments represent directory partitions that are writable replicas for the domain controller (the domain, configuration, and schema directory partitions). The bottom three segments represent directory partitions that are read-only replicas of the other domains in the forest.

Writable and read-only replicas in the AD DS database on a global catalog server

The source domain controller for replication of a given directory partition to a global catalog server can be either a non-global catalog domain controller or another global catalog server. In the following diagram, each directory partition on the global catalog server is being updated by a non-global catalog domain controller. The writable replicas on the global catalog server are updated by a domain controller that is authoritative for the same domain, Corp.contoso.com. The replication for the Corp.contoso.com domain and the configuration and schema directory partitions is two-way because the replicas are all writable.

Each of the read-only replicas is updated by a source domain controller that is authoritative for the respective directory partition. The replication is one-way because read-only replicas never update writable replicas.

Direction of directory partition replica updates between a global catalog server and other domain controllers

Replication Between Global Catalog Servers

As is true for all domain controllers, a global catalog server uses a single topology to replicate the schema and configuration directory partitions, and it uses a separate topology, if needed, for each domain directory partition. However, when a two-way connection exists between the servers, either for replication of the schema and configuration directory partitions or for replication in opposite directions of the two writable domain directory partitions, all replicas on each global catalog server use the same connection to update their common replicas when changes are available.

The diagram below shows the directions of replication between directory partitions on two global catalog servers that are in different sites and are authoritative for different domains. The writable replicas of soam.corp.contoso.com and corp.contoso.com update the respective read-only replicas in one direction only (a writable replica is never updated by a read-only replica). Because neither domain controller is authoritative for the noam.corp.contoso.com and eur.corp.contoso.com domain replicas, the global catalog servers can be sources for replication of these partial read-only replicas. This replication is shown as two-way because a two-way connection already exists and these replicas are each capable of updating the other.

Direction of directory partition replica updates between two global catalog servers in different domains

In the preceding diagram, the read-only replicas can also be updated from other domain controllers. Unless the forest functional level is Windows 2000 Server, the intersite KCC algorithm avoids creating redundant connection objects by implementing one-way replication where possible. For example, if the schema and configuration writable replicas and the Corp and Eur read-only domain replicas on GC1 are all updated by a domain controller other than GC2, replication of the Corp and Eur read-only replicas from GC1 to GC2 occurs in one direction if it occurs. In this case, GC1 might not generate a connection object for replication from GC2.

Global Catalog Replication of Additions to the Partial Attribute Set

Each global catalog server in an AD DS forest hosts a copy of every existing object in that forest. For the objects of its own domain, a global catalog server has information related to all attributes that are associated with those objects. For the objects in domains other than its own, a global catalog server has only information that is related to the set of attributes that are marked in the AD DS schema to be included in the partial attribute set (PAS). As described earlier, the PAS is defined by Microsoft as those attributes that are most likely to be used for searches. These attributes are replicated to every global catalog server in an AD DS forest.

If you want to add an attribute to the PAS, you can mark the attribute by using the Active Directory Schema snap-in to edit the isMemberOfPartialAttributeSet value on the respective attributeSchema object. You mark the attribute by placing a checkmark next to isMemberOfPartialAttributeSet. If the isMemberOfPartialAttributeSet value is checked (set to TRUE), the attribute is replicated to the global catalog. If the value is not checked (set to FALSE), the attribute is not replicated to the global catalog.

When the PAS is updated on the domain controller that has the schema operations master role, the writable schema directory partition replicates normally to all domain controllers. When a global catalog server attempts to update its read-only directory partition from a source replication partner whose schema has been udpated with the PAS change, the destination global catalog server receives the information that the PAS has been updated.

Depending on the version of Windows that is running on the replication partners, a global catalog server responds to an update to the PAS either by initiating replication of all attributes in the read-only directory partitions in the global catalog (full synchronization), or only the attributes that were added to the PAS (updates only), as follows:

• Updates only—both replication partners are running Windows Server 2003 or later: Only the added attributes are replicated and there is no replication impact. In this case, when the isMemberOfPartialAttributeSet value of a new attributeSchema object in the schema directory partition is set to TRUE and this change is either made on a global catalog server or replicated in by a global catalog server, the global catalog server records unique NTDS Replication informational events in the Directory Service log for each read-only directory partition that it hosts, as follows:

  • Event ID 1704, stating that in response to addition of one or more attributes to the PAS, the global catalog server has initiated replication of the PAS for the specified directory partition from the specified domain controller.

  • Event ID 1702, stating that synchronization of the PAS has completed successfully.

• Full synchronization—both replication partners are running Windows 2000 Server: The global catalog server initiates replication of all PAS attributes of all objects in all read-only domain directory partitions. In this case, all replication partner metadata and up-to-dateness metadata for the directory partition is discarded and the global catalog server builds a new list of replication partners and up-to-dateness information relative to those partners. Building its partner information anew, it requests replication of all attributes, filtering out any attribute that is not marked for inclusion in the PAS. If the attributes can be replicated over an RPC connection, the domain controller attempts a full replication over the RPC connection before it uses a configured SMTP connection. If full replication is completed, the up-to-dateness vector that is created ensures that later replication requests on other connections do not include data that has been received during the initial full replication.

  Full replication of all attributes in the PAS to bring all global catalog servers up-to-date causes increased network traffic while it is in progress and can take from several minutes to hours, depending on the size of the directory. Although interruption of service does not occur, this replication causes higher bandwidth consumption than is required for usual day-to-day replication. The resulting bandwidth consumption for each global catalog server is equivalent to that caused by assigning the global catalog role to a domain controller.

  In this case, when the isMemberOfPartialAttributeSet value of an additional attributeSchema object in the schema directory partition is set to TRUE and this change is either made on a global catalog server or replicated in by a global catalog server, a unique NTDS Replication informational event ID 1575 is recorded in the Directory Service log for each read-only directory partition that is hosted by the global catalog server. Event ID 1575 states that one or more new attributes has been added to the PAS for the specified directory partition and that full synchronization of all objects and all attributes in the specified directory partition will be performed from the source domain controller on the next replication cycle.

• Full synchronization—a global catalog server that is running Windows Server 2003 or later sources replication of a partial, read-only directory partition from a global catalog server or domain controller that is running Windows 2000 Server: The global catalog server that is running Windows Server 2003 or later reverts to Windows 2000 Server behavior and, as described above, initiates full replication of all objects and their attributes in all read-only directory partitions. For each read-only directory partition that it hosts, the global catalog server that is running Windows Server 2003 or alter records unique NTDS Replication informational events in the Directory Service log, as follows:

  • Event ID 1575, stating that full synchronization of the PAS will be initiated on the next replication cycle.

  • Event ID 1703, stating that synchronization of the PAS has been initiated.

  • Event ID 1702, stating that synchronization of the PAS has completed successfully.

Note

The AD DS schema in Windows Server 2003 and later contains attributes that are marked for inclusion in the PAS as soon as the forest functional level is raised to Windows Server 2003 or higher. Replication of the additions to the PAS to global catalog servers is triggered by raising the forest functional level to Windows Server 2003 or higher. Therefore, upgrading the schema has no impact on Windows 2000–based global catalog servers because the global catalog is updated only when all domain controllers are running Windows Server 2003 or later (the requirement for raising the forest functional level to at least Windows Server 2003). For more information about functional levels, see “How Active Directory Functional Levels Work.”

For more information about replication metadata, including up-to-dateness vector, see “How the Active Directory Replication Model Works.”

Global Catalog Response to Deletions from the Partial Attribute Set

Removing an attribute from the PAS does not involve replication of a deletion, but is handled locally. If you set the isMemberOfPartialAttributeSet value to FALSE in the schema, the attribute is removed from the directory of each global catalog server immediately after receiving the schema update. This behavior is the same on global catalog servers running any version of Windows Server.

Removing the Global Catalog from a Domain Controller

When you add the global catalog to a domain controller, a partial replica of each domain directory partition, other than the domain for which the domain controller is authoritative, is copied to the domain controller as described in Replication Process for Global Catalog Creation. This replication occurs immediately within a site or at the next scheduled replication between sites. However, when you remove the global catalog from a domain controller, the KCC begins removing the read-only replicas one at a time by means of an asynchronous process that removes objects gradually over time until no read-only objects remain.

The Windows 2000 KCC removes approximately 500 objects per attempt. Each time the KCC runs (every 15 minutes by default), it attempts the removal of the read-only replica until there are no remaining objects. At an estimated 2000 objects per hour, complete removal of the global catalog from the domain controller can take from several hours to days, depending on the size of the directory.

The KCC in Windows Server 2003 or later initially instructs the directory to remove each replica, but once the instruction is received, the directory itself keeps track of the progress of replica removal and reschedules the work accordingly. Rather than removing a fixed number of objects per removal attempt, AD DS continues removing objects until either the replica is gone or a higher priority replication operation is in the queue. Read-only replica removal receives the lowest possible priority, meaning that any other replication work will interrupt it. Thus, removal work is pre-empted for the other work and then resumed later. On domain controllers running Windows Server 2003 or later, event log messages record when removal of a partial replica is starting, being resumed, and finishing.

KCC events that are logged in the Directory Service log during global catalog removal include:

• Event ID 1744: Local domain controller is no longer a global catalog server.

• Event ID 1659: Removal of a directory partition from the local database has been resumed, including the approximate number of objects remaining to be removed and number of link values of attributes remaining to be removed.

• Event ID 1660: A specified directory partition has been removed from the local domain controller.

For a normally-to-lightly loaded system, read-only replica removal occurs as fast as possible in the background. On a server that is very busy with replication (for example, a hub domain controller), estimating the time required for global catalog removal is difficult.

As soon as you set the domain controller to not be a global catalog server by clearing the Global Catalog check box on the NTDS Settings object properties page, Net Logon deregisters the SRV resource records that specifically advertise the global catalog server in DNS. Therefore, although the read-only domain replicas might take hours or days to remove, the domain controller immediately stops advertising itself as a global catalog server in DNS and immediately stops accepting LDAP requests over port 3268.

Note

On a domain controller running Windows 2000 Server, if you check the Global Catalog box again before a partial replica has been completely removed, the KCC begins the process of replicating in the read-only replicas as follows: If a given replica is completely gone, the KCC adds the replica back. If the replica is still in the process of being removed, the KCC does not add it again until the initial removal is complete. Thus, during the removal period, there can conceivably be a mix of new replicas from the most recent global catalog instance, and some old replicas in the process of being removed from the previous instance. This condition is temporary and of no consequence to users because the domain controller is not being advertised as a global catalog server.

Network Ports Used by the Global Catalog

The following ports are used by global catalog servers:

Port Assignments for Global Catalog Servers

Service Name	UDP	TCP
LDAP		3268 (global catalog)
LDAP		3269 (global catalog Secure Sockets Layer [SSL])
LDAP	389	389
LDAP		636 (SSL)
RPC/REPL		135 (endpoint mapper)
Kerberos	88	88
DNS	53	53
SMB over IP	445	445

Related Information

The following resources contain additional information that is relevant to this section.

• RFC 2247 (https://go.microsoft.com/fwlink/?LinkId=192755) in the Internet Engineering Task Force (IETF) RFC Database

• Domain Controller Roles

• How Active Directory Searches Work

• Active Directory Collection

• Windows Security Collection

• Active Directory Replication Model Technical Reference

• Active Directory Replication Topology Technical Reference

• Domains and Forests Technical Reference

• Interactive Logon Technical Reference

• Access Tokens Technical Reference