Windows 2000 Universal Group Evaluation Across Subnets

In Microsoft Windows 2000 Active Directory, Universal Group membership evaluation across subnets occurs during the user authentication process and strictly depends on communication with a Global Catalog server. Because Universal Group membership lists are replicated exclusively to Global Catalogs rather than standard Domain Controllers, an authenticating domain controller must traverse network subnets using Active Directory site topology to locate a Global Catalog and build an accurate security access token for the user.

The Storage of Universal Group Memberships

In a native-mode Windows 2000 Active Directory environment, Universal Groups can contain user accounts, computer accounts, and other groups from any domain in the forest. Unlike Global and Domain Local groups, the membership of Universal Groups is not replicated to every standard Domain Controller (DC). Instead, Universal Group memberships are stored exclusively in the Global Catalog (GC) partition to prevent excessive inter-domain replication traffic.

The Authentication and Token Generation Process

When a client computer initiates a logon request across a subnet, the following sequence takes place to evaluate Universal Group memberships:

  1. DC Discovery via Subnet Mapping: The client submits a DNS query to find a local DC based on its IP address and subnet definition in Active Directory Sites and Services.
  2. Logon Initiation: The client sends authentication credentials to the chosen authenticating DC using Kerberos v5 or NTLM.
  3. Global Catalog Contact: To construct the user’s security access token, the authenticating DC must identify all group Security Identifiers (SIDs) associated with the account. If the authenticating DC is not itself a Global Catalog, it must contact a GC.
  4. Locating a GC Across Subnets: The DC queries DNS for _gc._msdcs.<ForestRootDomain> SRV records to discover available Global Catalog servers. It prioritizes GCs within the same Active Directory site. If no GC exists in the local site, the DC selects the closest GC in an adjacent subnet or site according to configured site link costs.
  5. LDAP Query: The authenticating DC connects to the remote GC over port 3268 (LDAP) or port 3269 (LDAP over SSL) to query the user's Universal Group memberships.
  6. Token Assembly: The remote GC returns the list of Universal Group SIDs. The authenticating DC merges these SIDs with the user's Global and Domain Local group memberships to complete the access token.

When the Global Catalog resides on a different subnet or across a WAN link, latency can directly affect the logon duration:

  • Site Link Costs: Windows 2000 uses cost metrics defined in Active Directory Sites and Services to determine the most efficient network route across subnets. The DC always directs queries to the lowest-cost reachable site.
  • Bandwidth Overhead: While Global Catalog LDAP queries are relatively compact, high network latency across remote subnets can introduce delays during peak logon hours.

Failure Behavior and Logon Denial

Windows 2000 strictly enforces the presence of a Global Catalog for non-administrative logons in native-mode domains. If network routing issues or firewall rules prevent the authenticating DC from reaching a GC across subnets:

  • The DC cannot evaluate Universal Group memberships.
  • To prevent users from accessing resources without proper security context (or bypassing intended group-based restrictions), the DC refuses to generate an incomplete access token.
  • The logon fails entirely, returning an error indicating that no Global Catalog server is available.

(Note: The ability to bypass this restriction via Universal Group Membership Caching was not introduced until Windows Server 2003; Windows 2000 requires direct network reachability to a Global Catalog across subnets for every fresh logon).