Global Catalog Server Requirement for User and Computer Logon

ID: Q216970

The information in this article applies to:

Microsoft Windows 2000 Server
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Datacenter Server
Microsoft Windows 2000 Professional

SUMMARY

As part of the logon process, a security token is constructed by the Local Security Authority (LSA) that contains the Security Identifiers (SIDs) of groups of which the user is a member (for both the domain and the local computer) and is used to identify the user and authorize the use of local and remote resources when the client attempts to gain access to them.

Windows 2000 includes a new type of group, the universal group, which is used in Windows 2000 to grant permissions to resources throughout the enterprise. A universal group can be created only in a Native-mode domain and can contain user accounts, global groups, and universal groups from any domain in the forest.

Because universal groups can be created in one domain and contain user accounts or groups from another domain, when a user's token is being constructed, the universal groups of which a user is a member must be enumerated and added to the token.

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 user is an administrator, 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 do not perform this operation at logon and are unaffected. 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.

Additional query words:

Keywords : kbenv kbnetwork
Version : WINDOWS:2000
Platform : WINDOWS
Issue type : kbinfo