Global Catalog Placement

How the GC plays a role in Active Directory.

• By Don Jones
• February 01, 2004

First of all, the GC does play an important role in the logon process. Keep in mind that a domain controller (DC) can only supply membership information about the groups from its own domain; only a GC is capable of showing which other Universal Security Groups a user belongs to. So, the DC that processes a user’s logon must contact a GC in order to see what Universal Groups from other domains the user belongs to. The GC is actually a shortcut, allowing a single server to provide all Universal Group information, rather than having the authenticating DC contact each domain in the forest independently. The GC’s role is an important factor in network design: If you don’t want DCs to traverse a WAN link in order to log on, make sure their local site includes at least one GC (or two, if you want fault tolerance). Of course, GCs do have their own replication requirements, so that will be a bit of extra traffic on the WAN.

Note that GCs in a single-domain forest do not require a lot of extra traffic because every DC already knows everything there is to know about the forest. In fact, the authenticating DC doesn’t need to contact a GC in a single-domain forest, because every DC in the forest already knows about all the Universal Groups that could possibly exist. DCs in a Windows 2000 mixed-mode domain won’t check with a GC either, because they don’t support Universal Groups. In a multiple-domain forest, GCs also allow users to log on through a DC that isn’t in their own domain: The DC uses the GC to locate the user’s home domain, which handles the logon.

What if a GC can’t be contacted at logon? That’s where cached credentials come in. Each time a successful logon occurs, the client saves the credentials to a local cache. This allows the client to “fake it” when a GC can’t be contacted; the client simply rebuilds the security token from the last successful logon. Cached credentials don’t provide updated group policies or access to a user’s home folder. By default, Win2K and Windows XP will cache the last 10 users that logged on. You can change that value through Group Policy, and some folks consider it a good security practice to do so. Why? Because you could disable someone’s user account, and if the user knew about it, he or she could simply disconnect the client before logging on. The user would get cached credentials and might still be able to access resources that should be denied. To turn off cached credentials, use a Group Policy Object (GPO) to set the number of cached credentials to zero. Users can still log on using local user accounts, but in most environments, it’s unusual for users to have local user accounts on their clients. You might consider changing the cached credential setting only for desktop computers, as laptop users may have a legitimate need to log on when they can’t contact a DC.