Windows 2000 Domain Logon Over Slow Links

This article explains how Microsoft Windows 2000 handles user and computer domain logons when communicating with domain controllers over low-bandwidth connections. It covers the link-speed detection algorithm, domain controller discovery through Active Directory sites, the optimization of Kerberos authentication, and the selective bypass of bandwidth-heavy tasks such as Group Policy processing and roaming profile synchronization.

During the initial logon sequence, the Windows 2000 operating system measures the network transfer speed between the client workstation and the authenticating Domain Controller (DC). The system uses the Internet Control Message Protocol (ICMP) to send a series of echo requests (pings) of varying sizes to the DC and measures the round-trip latency.

By default, Windows 2000 defines any connection with a data transfer rate below 500 kilobits per second (Kbps) as a slow link. If the measured speed falls below this threshold, the operating system flags the session as running across a slow connection and alters the logon sequence to conserve bandwidth.

Domain Controller Discovery and Active Directory Sites

Windows 2000 relies on Active Directory Sites and Services to minimize wide-area network (WAN) traffic. When a client initiates a logon:

  1. DNS Query: The client queries DNS for Service Location (SRV) records to identify available domain controllers.
  2. Subnet Mapping: The client contacts an initial DC via Lightweight Directory Access Protocol (LDAP) ping. The DC inspects the client's IP address, matches it against defined Active Directory subnets, and returns the client’s designated site name along with a list of DCs local to that site.
  3. Local DC Preference: If a domain controller exists in the local subnet/site, the client directs all subsequent logon traffic to that DC, avoiding unnecessary authentication over a slow WAN link entirely.

If no local DC exists, the client continues authentication across the slow link to the closest available remote DC.

Kerberos v5 Authentication

Authentication over the slow link is handled primarily by Kerberos version 5:

  • Ticket Exchange: The client sends an Authentication Service Request (AS-REQ) to the remote Key Distribution Center (KDC) running on the DC. This payload is small and typically transported via User Datagram Protocol (UDP) port 88.
  • Packet Fragmentation Handling: If the user belongs to numerous security groups, the Kerberos Ticket Granting Ticket (TGT) may exceed the maximum transmission unit (MTU) size. Windows 2000 detects packet fragmentation issues on slow, lossy links and automatically switches the Kerberos transport from UDP to Transmission Control Protocol (TCP) to guarantee delivery.
  • NTLM Fallback: If Kerberos negotiation fails due to severe packet loss or latency timeouts, Windows 2000 falls back to NTLM authentication using the Netlogon service over Remote Procedure Calls (RPC).

Adjustments to Group Policy Processing

To prevent extended logon delays, the Group Policy engine automatically disables high-bandwidth policy extensions when a slow link is detected:

  • Disabled Policies: Software Installation, Folder Redirection, and Disk Quota policies are skipped by default.
  • Processed Policies: Administrative Templates, Security Settings, and EFS (Encrypting File System) policies continue to apply, as they consume negligible bandwidth.
  • Scripts: Logon and logoff scripts run by default, but administrators can configure policy settings to disable them across slow links.

Roaming User Profiles

When a user with a roaming profile logs on across a slow link, Windows 2000 does not automatically download the entire profile from the remote server. Instead, the system:

  1. Compares the timestamps of the locally cached profile with the server-based profile.
  2. Prompts the user with a dialog box (if configured) asking whether to load the local copy or download the remote profile.
  3. Defaults to the local cached copy if no response is received within a timeout period, significantly accelerating the desktop initialization process.

Cached Credentials as a Fail-Safe

If the slow link experiences severe packet loss, latency exceeding standard RPC timeouts, or a total connection drop during the authentication handshake, the client falls back to locally cached credentials. Windows 2000 checks the locally stored hash in the Local Security Authority (LSA) database (by default, up to 10 previous unique logons are stored), allowing the user to access the local environment without a completed DC handshake.