Windows 95 Domain Logon to Windows NT Server

During the mid-to-late 1990s, integrating consumer-oriented desktop operating systems into enterprise environments required bridging distinct network architectures. This article explains how Windows 95 authenticated against a Windows NT Server domain environment. It covers the core network components, the discovery of Domain Controllers, the challenge-response authentication protocol, and the post-logon execution of enterprise policies and scripts.

The Client Architecture

Windows 95 relied on the Client for Microsoft Networks (implemented primarily through VREDIR.VXD, the 32-bit virtual network redirector) to interface with Windows NT domains. While Windows NT was built from the ground up with native security identifiers (SIDs) and user-level access controls, Windows 95 was inherently an MS-DOS-based operating system with no native local user security.

To bridge this gap, Windows 95 delegated user authentication entirely to the Windows NT Server using the Server Message Block (SMB) protocol running over NetBIOS. The communication occurred through one of three primary transport protocols:

  • NetBEUI: Fast, non-routable protocol used in small local networks.
  • NWLink: An IPX/SPX-compatible protocol frequently used in mixed Novell NetWare environments.
  • TCP/IP (NetBT): NetBIOS over TCP/IP, which became standard for routed corporate networks.

Domain Controller Discovery

When a user typed their username, password, and target domain into the Windows 95 logon dialog, the operating system had to locate an active domain controller:

  1. Name Resolution: The client queried NetBIOS name records to find the domain's Primary Domain Controller (PDC) or Backup Domain Controller (BDC). It specifically looked for the NetBIOS group name representing the domain registered with the <1C> resource type.
  2. Resolution Methods: Depending on network configuration, this query was resolved via a local NetBIOS subnet broadcast, an LMHOSTS file entry, or a query to a Windows Internet Name Service (WINS) server.
  3. Discovery Handshake: Once the IP or hardware address of the domain controller was retrieved, Windows 95 opened an SMB session with the server's Netlogon service.

The Challenge/Response Authentication Handshake

Windows 95 did not send passwords across the network in plaintext. Instead, it used a cryptographic challenge/response mechanism using either LAN Manager (LM) or, with updates, NTLM (NT LAN Manager) version 1:

  1. Negotiation: The client initiated an SMB Negotiate Protocol and Session Setup request to the Windows NT Server, identifying the target username and domain.
  2. Challenge Generation: The NT Server generated a pseudo-random 8-byte challenge nonce and sent it back to the Windows 95 client.
  3. Hash Generation and Response:
    • LM Hash: By default, Windows 95 converted the user password to uppercase, truncated or padded it to 14 characters, split it into two 7-byte halves, and used each half as a DES key to encrypt a known constant string. This produced the 16-byte LM password hash.
    • NTLM Hash: If configured, or after applying later service packs, Windows 95 generated an NTLM hash using the MD4 algorithm over the little-endian Unicode representation of the case-sensitive password.
    • The client then used the resulting hash to encrypt the 8-byte server challenge three times using DES, producing a 24-byte response.
  4. Server Verification: The client returned the 24-byte response to the NT Server. The NT Server looked up the user's password hash stored in its local Security Accounts Manager (SAM) database, performed the identical computation against the challenge it issued, and compared the results.

If the hashes matched, the Windows NT Server granted authentication and returned a success code along with the user's domain access rights and group memberships.

Post-Authentication Setup

Upon successful validation by the NT domain controller, Windows 95 completed the logon sequence:

  • Logon Scripts: The client accessed the domain controller's shared NETLOGON directory (\\<Server>\NETLOGON) to check for and execute assigned batch files (.bat or .cmd).
  • System Policies: If configured, the client downloaded a central policy file named CONFIG.POL from the NETLOGON share. This file overrode local Windows 95 registry settings (USER.DAT and SYSTEM.DAT) to enforce enterprise desktop lockdowns and access restrictions.
  • Roaming Profiles: If user profiles were enabled, Windows 95 pulled the user's remote profile directory from the domain server to populate local desktop icons, shortcuts, and application data.

Once these steps concluded, the Windows 95 shell (Explorer) loaded, allowing the user to browse networked shares and printers via SMB using their authenticated domain credentials.