🗃️AD Global Catalog
Idea of AD Global Catalog
What is the Global Catalog
The Global Catalog is a distributed data repository in Active Directory that contains a searchable, partial representation of every object in every domain within a multi-domain AD forest. It acts as a centralized index, enabling users and applications to locate objects across the entire forest without needing to know the specific domain in which the object resides. This is particularly crucial in large, distributed environments where objects are spread across multiple domains.
Imagine you work for a huge company, MyCorp, with offices in New York, London, and Tokyo. Each office has its own Active Directory domain (like
us.mycorp.com
,eu.mycorp.com
, andasia.mycorp.com
) to manage its users, computers, and printers. Now, if you’re in New York and need to email someone in Tokyo, you don’t want to call every office to find their email address. That’s where the Global Catalog comes in , it’s a centralized, searchable index that knows a little bit about every object in every domain across the company’s network (called an AD forest).The GC doesn’t store every single detail about every object , that would be too bulky. Instead, it keeps just the essentials, like names, email addresses, and login info, so it can quickly point you to the right place for more details. It’s hosted on specific domain controllers called Global Catalog Servers, and these servers share their info with each other to keep everything consistent.
Why does this matter
It makes searching across domains fast and easy.
It helps people log in, especially when they use their email-like username (
john.smith@mycorp.com
).It ensures access control works smoothly, like checking if you’re in a global group that gives you permission to a shared folder in another office.
The global catalog server
The global catalog server holds the full writable copy of objects in its host domain, and the partial copy of the objects in other domains in the same forest. The partial replica contains a copy of every object in the forest and the most commonly used attributes in queries. Applications and users in one domain can query for the objects in another domain (in the same forest) via the global catalog server. All domain controllers in the domain will not be global catalog servers by default. When installing the first domain controller, it will become the global catalog server, and other domain controllers can be promoted as global catalog servers according to the business requirements. Not every domain controller in the domain needs to be a global catalog server.
How Does the Global Catalog Work
Let’s get into the nuts and bolts. The GC is like a lightweight version of the full Active Directory database, focusing on speed and accessibility.
1. What’s Inside the GC ?
The GC holds a partial replica of every object in the AD forest. An object could be a user, group, computer, or organizational unit (OU). For each object, it stores only a subset of attributes think of these as the key fields you’d need for a quick lookup. For example:
User Object: Includes attributes like:
cn (Common Name, “John Smith”)
givenName (First Name, “John”)
sn (Surname, “Smith”)
userPrincipalName (Login name, john.smith@mycorp.com)
mail (Email, john.smith@mycorp.com)
Group Object: Includes attributes like:
cn ( “GlobalSalesTeam”)
member (List of members,
DNs like CN=John Smith,OU=Employees,DC=us,DC=mycorp,DC=com
)
These attributes are chosen because they’re the ones most often searched or needed for authentication. The full object, with all its attributes (like a user’s phone number or job title), stays in the domain’s regular directory, and the GC just points you there if you need more.
Where’s It Stored
The GC lives on Global Catalog Servers, which are domain controllers you’ve told to take on this extra role. Not every domain controller is a GC server , only the ones you designate. For example, in MyCorp’s New York site, you might make
DC01.us.mycorp.com
a GC server, and inLondon, DC01.eu.mycorp.com
.
The GC data is stored in the same AD database (ntds.dit) as the regular domain data, but it’s organized into three main parts:
Schema Partition: The blueprint for all objects and attributes (same as the AD Schema we discussed earlier).
Configuration Partition: Info about the forest’s structure, like domains, sites, and domain controllers.
Partial Domain Partitions: A slimmed-down copy of every object’s key attributes from all domains in the forest.
Last updated