Searching the Global Catalog

The global catalog is a special data store that contains a partial replica of every object in the entire forest. That is, a global catalog spans every domain in the entire forest. This special repository allows us to easily search in multiple domains in an efficient manner. Without using the global catalog, we would need to use referral chasing (see Chasing Referrals, later in this chapter) to find objects in other domains, which takes considerably longer.

Tip: Profile Your LDAP Queries

Active Directory and ADAM both support a special control that supports returning query statistics about how a query performed. The information contains details on the number of objects visited and indices used, among other things. This kind of information can be extremely helpful in understanding why different queries perform differently.

We do not have an easy way to use these statistics from within our own code, but several of the tools we discuss in Appendix B, such as ldp.exe and ADFind, support query statistics. We generally recommend using one of these types of tools for modeling queries before committing to code anyway. Remember, though, that using the statistics control requires administrative privileges on the server, as the user must have the ability to debug the server in order to invoke this feature. Hopefully we have a highly privileged account that we can bind with for these special occasions.

A global catalog server is simply a domain controller that has been dual-purposed not only to serve its joined domain, but also to hold a partial replica of the entire forest and to service global catalog search requests.

Important Considerations for Using the Global Catalog

The global catalog contains only a partial replica of each object in the directory. This means that we are limited to searching using only filter criteria from the available attributes. The attributes included for replication to the global catalog are actually defined in the schema and can be set by an administrator (see Table 7.4 in Chapter 7 for details). It also means that in order to read any additional attributes, we must perform another bind to the object directly in the domain to retrieve that information. One last point is that the global catalog is a read-only data repository. We cannot bind to it directly and add, modify, or delete information contained within it.

Binding Syntax for the Global Catalog

While normal LDAP operations are serviced off of port 389 (port 636 using SSL), the global catalog is serviced off of port 3268 (port 3269 using SSL).

Listing 5.1 shows a sample of how to use the global catalog to find objects across the forest.

Listing 5.1. Searching the Global Catalog

class Invoker
{
 static void Main(string[] args)
 {
 Console.WriteLine(
 GetUserInfo("dunn")
 );
 Console.ReadLine();
 }

 public static string GetUserInfo(string lastName)
 {
 DirectoryEntry gc = new
 DirectoryEntry("GC:");

 DirectoryEntry _root = null;

 using (gc)
 {
 //there is only 1 child under "GC:"
 foreach (DirectoryEntry root in gc.Children)
 {

 _root = root;
 break;
 }
 }

 StringBuilder sb = new StringBuilder();

 //note the filter must be searching
 // for a GC replicated attribute!
 string filter = String.Format(
 "(sn={0}*)",
 lastName
 );

 DirectorySearcher ds = new DirectorySearcher(
 _root,
 filter,
 null,
 SearchScope.Subtree
 );
 using (SearchResultCollection src=ds.FindAll())
 {
 foreach (SearchResult sr in src)
 {
 sb.AppendFormat("{0}
", sr.Path);
 }
 }

 return sb.ToString();
 }
}

Note that the GC: moniker has been substituted for the standard LDAP: provider. Beneath the covers, it will automatically be converted to LDAP://:3268/, as the only difference is the port that the global catalog listens on.