Active Directory Insights (Part 13) – Digging into the Global Catalog

By /

If you would like to read the other parts in this article series please go to:

Introduction

Let’s start off with some background info which should be familiar to most administrators of Active Directory environments.

The Global Catalog (GC) is a feature of Active Directory that facilitates searching the directory database for your entire forest utilizing only domain controllers in your local domain. In other words, the GC lets you search your forest for information about users, groups computers, and other objects without needing to issue referrals to domain controllers residing in other domains or domain trees.

The GC resides on domain controllers, and a domain controller that hosts the GC is called a global catalog server. The GC on any global catalog server contains a complete copy of all of directory objects in the local domain along with all of the attributes of these objects. The GC also contains a read-only copy of all of the objects in other domains of the forest, but this only includes the most commonly searched-for attributes for these objects.

Users, applications and services can find objects in Active Directory by searching a nearby global catalog server (typically the domain controller the user, application or service has authenticated with) by issuing a Lightweight Directory Access Protocol (LDAP) query over port 3268. Global catalog servers are also used by Active Directory to resolve user principal names (UPNs) when the domain controller that is trying to perform the authentication has no knowledge of that particular user account. The GC is also required whenever you want to use universal groups in your Active Directory environment.

For more background information on the GC you can read this section on TechNet.

Now that we’ve done a quick recap of what the GC is all about, let’s dig deeper by looking at some specific issues involving global catalog servers.

Make all your domain controllers host the GC

Microsoft’s recommendations regarding which domain controllers should host the GC may feel somewhat confusing. For example, on this TechNet page they recommend the following:

“To optimize network performance in a multiple-site environment, consider adding global catalog servers in sites according to the needs in the sites for fast search responses and domain logons. It is recommended to make all domain controllers be global catalog severs if possible. In a single-site, multiple-domain environment, a single global catalog server is usually sufficient to cover common Active Directory queries and logons.”

So it sounds like best practice is to make all of your domain controllers global catalog servers, but if that’s the case why does Microsoft hedge this with “if possible”? Replication bandwidth between Active Directory sites in a forest is the likely consideration here, especially when slow WAN links are used to connect remote branch offices with corporate headquarters. But is replication to global catalog servers really that big of a concern? With the initial release of Active Directory in Windows 2000 Server there were some concerns in this area, but beginning with Windows Server 2003 Microsoft has consistently made improvements in how Active Directory replicates such that now there really should be little or no concern about replication traffic to build (or rebuild) the GC on a domain controller. For example, Windows Server 2003 introduced a feature that eliminated the necessity of resetting global catalog servers when a new index is created. Another introduced feature called link value replication also mitigated against inter-site GC replication being an issue. Later when read-only domain controllers (RODCs) were introduced in Windows Server 2008, you now had the option of hosting your GC on an RODC. So basically the end result of all these improvements is that GC replication is now only an issue when you introduce a new global catalog server into your environment by promoting a new domain controller and making it host the GC. Once the GC partitions have replicated to the new domain controller, future GC replication is simply normal attribute replication which means there’s no extra cost to GC replication above normal Active Directory domain controller replication.

You can also make some design decisions that can minimize the replication cost of maintaining the GC in your environment. For example, you can make use of universal groups sparingly instead of going all-out and creating tons of them. And instead of making individual users the members of your universal groups, consider putting those users in global groups and then making the global groups members of your universal groups.

There are also some benefits of making every domain controller in your forest a global catalog server. One important benefit is that all logon traffic for users and computers will be kept to the local site where the users and computers reside. This can speed up the logon process, which is an important consideration since users need to log on before they can do work, and if they can’t do work your company can’t make money.

Another advantage of making every domain controller host the GC is that you will not have to worry about which domain controller to place the infrastructure master FSMO role upon in each domain of your forest. The infrastructure master is the domain controller in your domain that is responsible for updating references from objects in the local domain to objects in other domains. The infrastructure master does this by comparing its data with that found in the GC. If all domain controllers in your domain are global catalog servers, then you don’t have to be concerned about which domain controller hosts the infrastructure master role for the domain. If however only some of the domain controllers in your domain are global catalog servers, then you need to make sure that the infrastructure master role is not assigned to a domain controller hosting the GC or the GC for the forest will quickly become out of date. And see also what this MSDN article says concerning the infrastructure master role and the GC.

Another benefit of making every domain controller host the GC is that when you promote new domain controllers you don’t have to worry about whether to have them host the GC or not. This makes provisioning new domain controllers a more consistent process since you only need to maintain one configuration for all your domain controllers. As a tip though, make sure you implement some kind of automated check for your environment that verifies that any newly provisioning domain controller does in fact now host the GC.

Some limitations of global catalog servers

When designing applications or services that will be using LDAP to query for such things like a user’s group membership within the forest, there are a few things you should keep in mind concerning the GC and global catalog servers:

  • The GC is a forest resource, not a domain resource. This means for example that you can’t search for a global catalog server in a particular domain, you can only search “the” GC.
  • Global catalog servers can only provide information about universal groups in the forest. They don’t contain any information about global group memberships or about domain local groups in the domain where they reside.
  • To search the whole forest using the GC, search the GC using an empty base distinguished name (DN) in a subtree search. For more information on how to do this, see this old article on TechNet.

Querying the GC for group membership is an expensive proposition which can take too much time in some application or service scenarios. It might be better to query the TokenGroups instead, see this old but still useful article for more information, and also see this article which explains the difference between the TokenGroups and MemberOf attributes in Active Directory.

To be continued

We’ll examine some more issues associated with the GC and its operations and maintenance in the next article of this series, so stay tuned!

Still got questions about Active Directory?

If you have any questions about domain controller hardware planning, the best place to ask them is the Active Directory Domain Services forum on TechNet. If you don’t get help that you need there, you can try sending your question to [email protected] so we can publish it in the Ask Our Readers section of our newsletter and see whether any of the almost 100,000 IT pro subscribers of our newsletter have any suggestions concerning your problem.

If you would like to read the other parts in this article series please go to:

About The Author

Mitch Tulloch is Senior Editor of both WServerNews and FitITproNews and is a widely recognized expert on Windows Server and cloud technologies. He has written more than a thousand articles and has authored or been series editor for over 50 books for Microsoft Press and other publishers. Mitch has also been a twelve-time recipient of the Microsoft Most Valuable Professional (MVP) award in the technical category of Cloud and Datacenter Management. He currently runs an IT content development business in Winnipeg, Canada.

Read Next

Static vs Dynamic IP Address

Static vs Dynamic IP Address

Most people are familiar with Internet Protocol (IP) Addresses, but many people don’t know you have 2 types. In this article, you’ll learn about static…

Read More »

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top