Tips and Tricks

Global Catalog Placement

How the GC plays a role in Active Directory.

There’s a lot of confusion about the role of global catalog (GC) servers in the logon process and where cached credentials come into play. This month, I’ll try to clear up the confusion and offer tips for improving logon support in an Active Directory environment.

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.

How Many GCs Is Enough?
Reduce across-the-WAN replication traffic by reducing the number of GC servers on your network. Clients can still log on using a Windows 2003 DC, thanks to its ability to cache Universal Group membership lists. In an Exchange 200x environment, GC servers are also used for global address list lookups; for the best client performance, make sure a large body of users has fast connectivity to a GC server. Finally, in a single-domain forest, you don’t really need extra GC servers beyond the first one that AD creates—every DC already knows everything there is to know about the entire forest.

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.

About the Author

Don Jones is a multiple-year recipient of Microsoft’s MVP Award, and is Curriculum Director for IT Pro Content for video training company Pluralsight. Don is also a co-founder and President of PowerShell.org, a community dedicated to Microsoft’s Windows PowerShell technology. Don has more than two decades of experience in the IT industry, and specializes in the Microsoft business technology platform. He’s the author of more than 50 technology books, an accomplished IT journalist, and a sought-after speaker and instructor at conferences worldwide. Reach Don on Twitter at @concentratedDon, or on Facebook at Facebook.com/ConcentratedDon.

comments powered by Disqus
Most   Popular