Global Catalog Placement


Paralleling the question of where to place the domain controllers is the question of which domain controllers should be the main global catalog servers. The typical rule of thumb is that each site that has domain controllers should have at least one Global Catalog.

What Does the Global Catalog Do?

A global catalog is a kind of index for Active Directory. Every directory object in the entire enterprise is represented in the global catalog, but only a subset of the properties of each object is stored in the catalog. The properties stored for each object are those most likely to be used as search attributes, such as the user 's first or last name . You can specify storing additional object attributes in the catalog if desired. Having the global catalog store only a subset of an object's attributes in Active Directory improves the performance of search queries against Active Directory.

GC Replication Traffic Versus Lookup Traffic

Any changes in Active Directory will show up on the Global Catalog servers when Active Directory replication occurs. Because this is only a subset of the entire Active Directory, replication traffic will be relatively light. This load will increase with the number of domains because Global Catalogs contain objects from all domains in the forest. As such, Global Catalog placement in a forest with a low number of domains can benefit from mirroring Domain Controller placement.

Determining the Impact of Global Catalog Failure

When a user authenticates against an Active Directory domain controller, the domain controller must be able to contact a global catalog to determine if the user is a member of any universal groups. If a domain controller fails to contact a global catalog, the user's logon will fail. As such, if a domain controller is going to be placed in a remote site in order to ensure local access to local resources in an office where many users might not have locally caches credentials, it is important to make the domain controller a global catalog as well.

For extremely large sites, this additional global catalog traffic might be excessive if it must be placed on every domain controller in the enterprise to protect logons for remote sites. Optionally, you can disable this requirement for contacting a global catalog in order to authenticate a user successfully. Doing the following disables this function:

  1. From the run command, launch Registry Editor (Regedt32.exe).

  2. Drill down to the following key in the Registry:

    HKEY_LOCAL_MACHINE\System\

    CurrentControlSet\Control\Lsa

  3. On the Edit menu, click Add Key, and then add the Registry key IgnoreGCFailures. After adding the Registry key, the Registry Editor screen will look similar to Figure 10.4.

    Figure 10.4. Adding the Registry key.

    graphics/10fig04.gif

  4. Exit the Registry Editor.

  5. Restart the domain controller.

Only Use This Feature If It Is Unavoidable

You should only use this feature if it is unavoidable to have local domain controllers that are not global catalogs. If this key is enabled and a user is a member of a universal group, if that universal group is denied access to a resource, the user might still be able to access the resource. This is because the key turns off enumeration of universal groups so the universal group SID will not be added to the user's token.


This will enable sites with local Domain Controllers that are not Global Catalogs to still authenticate users if a Global Catalog server is not available.



Microsoft Windows Server 2003 Insider Solutions
Microsoft Windows Server 2003 Insider Solutions
ISBN: 0672326094
EAN: 2147483647
Year: 2003
Pages: 325

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net