Skip to main content
Identity Authority
Category: Directory Services

Global Catalog

Also known as: GC, Global Catalog Server
Simply put

The Global Catalog is a feature of Microsoft Active Directory that lets users and applications search for objects across all domains in a directory forest, rather than being limited to a single domain. It works by keeping a searchable, partial copy of every object in the forest so that lookups can be answered quickly without contacting every domain individually.

Formal definition

The Global Catalog (GC) is a specialized role hosted on designated domain controllers in Active Directory Domain Services (AD DS) that maintains a partial, read-only, searchable representation of every object across all domains in a forest, alongside a full set of attributes for objects in the GC's own domain. Applications and users query the GC to locate objects by one or more attributes across the domain tree without needing to enumerate individual domain partitions. Note that the GC stores only a configurable subset of attributes (the partial attribute set) for out-of-domain objects rather than every attribute; specific ports, replication behavior, and attribute inclusion depend on the AD deployment and configuration and are out of scope here.

Why it matters

In multi-domain Active Directory forests, the Global Catalog is what makes forest-wide object lookups practical. Without it, an application or user searching for an object outside their own domain would need to locate and query the appropriate domain partition directly, which is slower and operationally fragile. Because the GC maintains a partial, searchable representation of every object in the forest, it underpins common operations such as resolving user principal names, evaluating universal group memberships, and answering directory searches that span domain boundaries. Many enterprise applications that integrate with Active Directory rely on GC availability to authenticate and locate users efficiently.

From a security and governance standpoint, the GC concentrates a broad, cross-domain view of directory objects into a single queryable service, which makes it both operationally valuable and worth protecting. It exposes a partial attribute set for out-of-domain objects, so what an attacker or a legitimate application can enumerate depends on which attributes are included in that set and on how access is configured. Availability also matters: because certain directory operations depend on reaching a GC, the loss or misconfiguration of Global Catalog servers can disrupt sign-in and application behavior across the forest.

Understanding the GC's scope is important precisely because it is easy to overstate. It provides identification and lookup of objects across domains, but it is not itself an authorization mechanism, and it stores only a configurable subset of attributes for objects outside its own domain. Treating it as a complete replica of the forest, or as a substitute for domain-specific queries when full attribute data is required, leads to design errors that surface only under specific query patterns.

Who it's relevant to

Active Directory and identity administrators
Administrators managing multi-domain forests plan the placement and availability of Global Catalog servers, since many directory operations and application integrations depend on reaching a GC. They also need to understand that the GC exposes only a partial attribute set for out-of-domain objects when troubleshooting searches that return incomplete data.
Application and integration engineers
Engineers building applications that query Active Directory use the GC to locate users and objects across domains efficiently rather than querying individual domain partitions. They should design queries with an awareness that attributes not in the partial attribute set must be retrieved from the object's home domain controller.
Security architects and IAM teams
Because the Global Catalog concentrates a cross-domain, searchable view of directory objects, security teams treat it as a sensitive service to protect and monitor. They should note that the GC supports identification and lookup of objects but is not itself an authorization control.

Inside GC

Partial attribute set (PAS)
The Global Catalog holds a read-only, partial replica of every object in the forest, containing a subset of each object's attributes rather than the full attribute set. The attributes included are those flagged as members of the partial attribute set in the schema.
Full replica of the host domain
For the domain in which a Global Catalog server resides, it stores a complete, writable replica of all objects and their full attributes, in addition to the partial replica of objects from other domains in the forest.
Forest-wide object index
Because it aggregates a partial replica of objects across all domains, the Global Catalog enables forest-wide searches without requiring referrals to other domain controllers, which is useful when the target domain is unknown.
Universal group membership information
The Global Catalog typically stores universal group membership across the forest, which is consulted during authentication to construct a user's complete group membership context, depending on domain and forest configuration.
Schema-driven attribute selection
Which attributes are replicated into the partial attribute set is governed by the forest schema; administrators can add attributes to the partial attribute set, though doing so affects replication scope and volume.

Common questions

Answers to the questions practitioners most commonly ask about GC.

Does the Global Catalog contain a full copy of every object in the forest?
No. The Global Catalog holds a partial, read-only replica of every object in the forest, but only a subset of each object's attributes rather than all of them. It stores a full writable copy of the objects in its own domain, plus a partial attribute set for objects in all other domains. The specific attributes included in the partial set are governed by the partial attribute set (PAS), which is configurable. So while the Global Catalog spans the entire forest in terms of object coverage, it deliberately does not carry the complete attribute detail for out-of-domain objects.
Is the Global Catalog an authentication or authorization service?
The Global Catalog is neither an authentication protocol nor an authorization decision point; it is a distributed data store and lookup service within a directory. That said, it participates in access-related flows in supporting ways. During sign-in it is typically consulted to resolve universal group memberships, which in turn affects the security context built for a principal. Resolving group memberships is an input to how authorization decisions are later made, but the Global Catalog itself does not verify credentials or evaluate access policy. Its role should be understood as directory lookup and forest-wide search, not as performing authentication or rendering authorization decisions.
Which servers should be designated as Global Catalog servers in a multi-site deployment?
This depends on your topology and site design. In most deployments, planning aims to ensure that Global Catalog lookups can be serviced locally at each site to avoid cross-site latency during sign-in and directory search, particularly where universal group membership resolution is needed. A common practice is to place at least one Global Catalog per site, though the exact placement is a trade-off between replication traffic, storage, and query performance. Some environments use features intended to reduce dependence on a local Global Catalog during logon; whether that is appropriate depends on your version, configuration, and site connectivity. Treat placement as a per-environment design decision rather than a fixed rule.
How do I control which attributes are replicated to the Global Catalog?
Attribute inclusion in the Global Catalog is governed by the partial attribute set, which is defined in the schema by flagging attributes for replication to the Global Catalog. Adding an attribute to the partial attribute set makes it available for forest-wide search but also increases replication and storage overhead. Because schema changes are forest-wide and can be difficult to reverse, such modifications are typically planned carefully and tested before being applied in production. The exact procedure and any behaviors around re-replication depend on your directory version and configuration, so validate against your platform's documentation.
What is the practical impact of a Global Catalog being unavailable at a site?
The effect depends on what your deployment relies on the Global Catalog for. Because it is typically consulted to resolve universal group memberships during sign-in and to service forest-wide searches, its unavailability can affect logon behavior and directory queries that span domains, depending on configuration. Applications and services that perform forest-wide lookups may also be affected. Some environments mitigate this with local caching mechanisms or additional Global Catalog servers, but whether those mitigations apply and how they behave varies by version and configuration. Assess the specific dependencies in your environment rather than assuming a uniform outcome.
How should I plan for capacity and replication overhead when adding Global Catalog servers?
Each Global Catalog server maintains a partial replica of forest-wide objects in addition to its own domain data, so adding Global Catalog servers increases inbound replication traffic and storage requirements. Capacity planning typically weighs the query-performance and availability benefits of a local Global Catalog against the added replication load and disk footprint, and these considerations grow with the number of domains and objects in the forest. Widening the partial attribute set further increases this overhead. Because the magnitude of impact depends on forest size, network topology, and configuration, size and test against your own environment rather than relying on generic figures.

Common misconceptions

The Global Catalog authenticates users.
The Global Catalog is a directory index and lookup service, not an authentication mechanism. It supports the authentication process, for example by supplying universal group membership so that authorization decisions can be made after a principal is authenticated, but verifying a principal's identity is handled by the authentication protocols and domain controllers, and determining access rights is a separate authorization step.
The Global Catalog contains every attribute of every object in the forest.
For objects outside its host domain the Global Catalog holds only a partial attribute set defined by the schema, not the full object. Complete attribute data for a non-local object must be retrieved from a domain controller in that object's own domain.
The Global Catalog is the same thing as a general LDAP directory service.
The Global Catalog is exposed for querying but serves as a forest-wide search index with a partial, read-only replica of remote-domain objects and a full replica only of its host domain. It complements, rather than replaces, the standard directory replicas, and its scope is intentionally limited to enable efficient cross-domain lookups.

Best practices

Plan Global Catalog server placement so that sites with authentication or forest-wide search demands have local access, since universal group membership lookups may be needed during logon depending on configuration.
Evaluate the impact on replication before adding attributes to the partial attribute set, because expanding indexed attributes increases the volume of data replicated across the forest.
Do not rely on the Global Catalog for full object attribute retrieval outside its host domain; direct such queries to a domain controller in the object's own domain where the complete attribute set resides.
Keep the roles distinct in your design: use the Global Catalog for identification and directory lookup, and rely on the appropriate authentication and authorization components for verifying principals and determining their access.
Assess whether universal group caching or additional Global Catalog servers better fit a given site, weighing replication cost against logon-time lookup latency in your specific deployment.
Document which attributes are members of the partial attribute set in your environment so that application and query designs account for what is and is not available from a Global Catalog query.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.