Share via

Global Catalog and LDAP Searches

  • Article

The Global Catalog enables searching for Active Directory objects in any domain in the forest without the need for subordinate referrals, and users can find objects of interest quickly without having to know what domain holds the object.

Global Catalog Servers

A Global Catalog server is a domain controller that stores extra information; its database stores rows for every object in the forest instead of rows for only the objects in one domain. The rows that store objects that occur in domain directory partitions other than the local domain partition hold only a subset of attributes for each object. In this way, the Global Catalog enables forest-wide searches without requiring replication of the entire contents of Active Directory to every domain controller. The Knowledge Consistency Checker (KCC) process creates a replication topology that ensures delivery of the contents of every directory partition to every Global Catalog server in the forest.

note-iconNote

A Global Catalog server stores full (writable) copies of the schema and configuration directory partitions — the same as any domain controller.

By default, the server on which you install Active Directory to create the first domain in a new forest is a Global Catalog server. Thereafter, you must designate additional Global Catalog servers, if they are needed.

Searching the Global Catalog vs. Searching the Domain

The decision whether to search the Global Catalog or the domain is based on the scope of the search:

  • When the scope of a search is the domain or an organizational unit, the query can be resolved within the domain partition by using an LDAP search.

  • When the scope of a search is the forest, the query can be resolved within any partition by using a Global Catalog search.

Searches That Use the Global Catalog by Default

Any time that you specify port 3268, you are searching in the Global Catalog. In addition, the Global Catalog is searched by default under the following conditions:

  • During the logon process when a user principal name is presented. The Global Catalog is searched to find the domain and account name on the basis of the user principal name.

  • During the logon process to expand universal groups Universal group membership can span domains. It is possible, therefore, that a user has a membership in a universal group that is not in the logon domain. For this reason, the Global Catalog is contacted to search the membership of universal groups. If a membership is found, the group is attached to the user's logon credentials.

  • When you choose Entire Directory in a search-scope list.

  • When you write the value for a distinguished name-valued property, where the distinguished name represents a nonlocal object. For example, if the member that you are adding is from a different domain, the Global Catalog is used to verify that the user object represented by the distinguished name actually exists.

Global Catalog Search Base

For an LDAP search, you must supply a valid base distinguished name. For a Global Catalog search, the base distinguished name can be any value, including the value "NULL" (" "). A base distinguished name of NULL effectively scopes the search on the search computer to the Global Catalog. If you use a NULL base distinguished name with a scope of one level or subtree and specify port 389 (the default LDAP port), the search fails. Therefore, if you submit a NULL search to the Global Catalog port and then change the port to the LDAP port, you must change the base distinguished name for the search to succeed.

note-iconNote

Windows Address Book is configured automatically with the value "NULL" for server name, account name, and base distinguished name. The default port is port 3268; so to submit the search to port 389, you must provide a valid base distinguished name as defined in RFC 2247. A blank base distinguished name fails on either port.

The following characteristics differentiate a Global Catalog search from a standard LDAP search:

  • Global Catalog queries are directed to port 3268, which explicitly indicates that Global Catalog semantics are required. By default, ordinary LDAP searches are received through port 389. If you bind to port 389, even if you bind to a Global Catalog server, your search includes a single domain directory partition. If you bind to port 3268, your search includes all directory partitions in the forest. If the server you attempt to bind to over port 3268 is not a Global Catalog server, the server refuses the bind.

  • Global Catalog searches can specify a non-instantiated search base, indicated as "com" or " " (blank search base).

  • Global Catalog searches cross directory partition boundaries. The extent of the LDAP search is the directory partition.

  • Global Catalog searches do not return subordinate referrals. If you use port 3268 to request an attribute that is not in the Global Catalog, you do not receive a referral to it. Subordinate referrals are an LDAP response; when you query over port 3268, you receive Global Catalog responses, which are based solely on the contents of the Global Catalog. If you query the same server by using port 389, you receive referrals for objects that are in the forest but whose attributes are not referenced in the Global Catalog.

note-iconNote

An external referral can be returned by the Global Catalog if a base-level search for an external directory is submitted and if the distinguished name of the external directory uses the domain component (dc=) naming attribute. This referral is returned according to the ability of Active Directory to construct a DNS name from the domain components of the distinguished name and not based on the presence of any cross-reference object. The same referral is returned by using the LDAP port; it is not specific to the Global Catalog. (For more information about constructing a DNS name from the domain components, see "Superior References" earlier in this chapter.)

Some Active Directory attributes cannot be located specifically by finding a row in the directory database. A back link is an attribute that can be computed only by referencing another attribute, called a forward link. An example of a back-link attribute is the memberOf attribute on a user object, which relies on the group attribute members to derive its values. For example, if you request the groups of which a specific user is a member, the forward link members , an attribute of the group object, is searched to find values that match the user name that you specified.

Because of the way that groups are enumerated by the Global Catalog, the results of a back-link search can vary, depending on whether you search the Global Catalog (port 3268) or the domain (port 389), the kind of groups the user belongs to (global groups vs. domain local groups), and whether the user belongs to groups outside the local domain. Connecting to the local domain does not locate the user's group membership in groups outside the domain. Connecting to the Global Catalog locates the user's membership in global groups but not in domain local groups because local groups are not replicated to the Global Catalog. For more information about searching on back-link attributes, see "Active Directory Data Storage" in this book.