Global Catalog Server Requirement for User and Computer Logon (216970)

MORE INFORMATION

Instead of communicating with every domain in the forest to enumerate the universal groups from each, the member list of each universal group is replicated to Global Catalog (GC) servers, making it easier for a domain controller to query one location for all universal groups of which the user is a member.

In a Native-mode domain, the Key Distribution Center (KDC) on the domain controller authenticating the user's logon request is responsible for adding the SIDs for global groups from the user's logon domain, locating and communicating with the GC to enumerate the universal groups the user is a member of, and adding the SIDs of those groups to the user's token. If the domain the computer resides in is in Native mode, any domain local groups from that domain of which the user is a member are added to the token. Lastly, any local groups from the local computer of which the user is a member are added to the token.

The first domain controller that is installed for a given forest is automatically selected to be a GC server. The GC server replicates a copy of all objects from every domain in the forest, but only contains a subset of each object's attributes. The attributes that are replicated are those that will be those used in most common queries. Beyond the first domain controller of the forest, it is an administrative action to make other domain controllers in the forest GC servers.

GC servers can be domain controllers from any domain. When authentication occurs, the domain controller that is authenticating the user's logon request needs to locate a GC in order to construct the universal groups to which that user belongs. In the event that there is only one domain in the forest, all domain controllers contain the same data, so there is no need to locate a GC (even though any given server might be designated a GC). If the domain controller handling the user logon request is also a GC, there is no need to remote the request to another GC. There is no requirement that the GC selected to service the request be a member of the domain to which the authenticating domain controller belongs.

If a GC server cannot be located by the domain controller during this process:

• If the account that is used is the built-in Administrator account (RID 0x1F4 or decimal 500), Windows 2000 allows the logon to take place without the domain controller contacting a GC.
• If cached credentials exist for the user on the local computer, the user is logged on with those credentials. Access to network resources must be validated on an individual basis. If the client uses Kerberos to use a server's resources, the KDC must be contacted to get a ticket for the server, or if NTLM is used, pass-through authentication is required.
• If cached credentials do not exist, the user is denied logon.

For these reasons, it is important to note that a user's getting logged on with cached credentials or being denied logon would be the result of the domain controller failing to find any GC. Because all global catalogs contain the same information (with the replication latency exception), any GC can be used. If a local GC happens to be offline, a remote GC can and will be used. For performance reasons and bandwidth efficiency, it may be beneficial to host a local GC in each site. Clients and domain controllers prefer communicating with a GC in the local site before using a remote GC in another site.

This process takes place at every logon and is consistent with down-level behavior; if the user is added or removed from a group, the change is not reflected until the user logs off and back on.

In a Mixed-mode domain, universal groups cannot be created. If a Windows 2000-based computer is located in a down-level or Mixed-mode domain, different behavior occurs. Other domains may be in Native mode and universal groups may have been created that contain the user as a member. The domain controller authenticating the logon request will add the SIDs of the global groups of which the user is a member to the user's token and the local computer adds SIDs for groups of which the user is a member on the local computer as appropriate. When an attempt to use resources in another domain occurs, the computer hosting the resource contacts a domain controller for that domain, which adds the SIDs of the groups local to that domain (which may include universal groups) of which the user is a member to the user's token.

Down-level clients are also subject to this behavior. Note that computers are security principals and can be affected in the same way. An enumeration of the groups to which the computer belongs is also performed at computer startup.