The Global Catalog (GC) is a critical component of Active Directory, particularly in multi-domain forests. In a multi-domain forest, objects (users, groups, computers, etc.) are spread across each domain. If an application needs to locate a user, for example, and the application does not know what domain the user is located in, then the application would need to contact a domain controller in each domain until the user is located. This approach is highly inefficient, and the Global Catalog is the solution. Domain Controllers that host a copy of the Global Catalog store a partial read-only copy of every object in the forest in the local database. When LDAP queries are submitted on TCP port 3268 (or TCP port 3269 for SSL), a single search can be conducted across all of the objects in the forest.
To conserve space and ensure efficient replication, objects in the Global Catalog are referred to as partial objects because only a subset of the attributes of the object are replicated to the Global Catalog. This subset of attributes is known as the Partial Attribute Set (PAS). Administrators can configure the set of attributes that comprise the PAS by modifying the definition for a given attribute in the Active Directory schema. Many applications that extend the Active Directory schema add their custom attributes to the PAS. Microsoft Exchange Server is a common example of this approach. Exchange adds dozens of attributes to the PAS and subsequently conducts nearly all of its LDAP searches via the Global Catalog.
Special logic in Active Directory ensures that the Global Catalog has a copy of group membership for all universal groups. Consequently, client computers must contact a Global Catalog at logon time to construct a complete token for the user. If the user is located at a site that does not have a Global Catalog, the request must traverse the wide area network (WAN). If a GC is not available (e.g. due to a network outage), the logon attempt will fail. This behavior can be disabled by following the steps in Microsoft Knowledge Base Article 241789. It is important to note however that if this behavior is disabled and a GC cannot be contacted, the user will receive an incomplete security token. Resources secured via universal groups will not be accessible to the user. If your access model uses deny entries in Access Control Lists (ACLs), and a deny entry is specified for a universal group, the deny entry will not be effective because universal group memberships are not reflected in the user’s token.
Historically, the question of what domain controllers should host the Global Catalog was a topic of significant interest during Active Directory design discussions. As WANs have evolved and forest topologies have shrank to have fewer and fewer domains, the need for this discussion has subsided. First and foremost, the GC is not relevant in a single domain forest. If your forest has only one domain, simply make all of your domain controllers GCs. In a multi-domain forest, try to make as many (or all) of your domain controllers GCs if possible. If you have sites that have poor connectivity and the replication overhead of the GC would place a significant burden on the WAN, then you must decide if placing a GC in the site is necessary or not. If the site hosts applications that are dependent on the GC (e.g. Exchange Server), then placing a GC locally is critical. Likewise, if universal group membership is a key component of the access model for applications and services hosted at the site, then placing a GC is likely necessary.