How Windows 98 Processed Domain Policies

During the late 1990s, Microsoft Windows 98 enforced administrator-defined network restrictions using System Policies rather than the modern Group Policy Object (GPO) framework. When a user logged into a Windows NT or Novell NetWare network, the operating system downloaded a centrally managed file named CONFIG.POL from the authenticating server's network share. Windows 98 then parsed this file to inject administrator-defined restrictions directly into the local registry, overriding local user preferences and limiting access to system utilities, network resources, and desktop components.

Policy Creation and Server Placement

System administrators generated network policies using the System Policy Editor (POLEDIT.EXE). This utility compiled administrator configurations into a single binary file named CONFIG.POL.

To ensure the client could find the policy automatically, administrators placed CONFIG.POL in a predefined location:

  • Windows NT / 2000 Domains: The NETLOGON share of domain controllers (typically mapped to \\<DomainController>\NETLOGON\CONFIG.POL).
  • Novell NetWare Networks: The SYS:PUBLIC directory.

The Network Authentication and Download Process

When a client computer booted and a user logged on, Windows 98 initiated a sequence to locate and retrieve network policies:

  1. User Authentication: The client sent user credentials to the domain controller (or preferred NetWare server) for validation.
  2. Profile Verification: Windows 98 checked whether User Profiles were enabled locally. If disabled, only the default computer policies were processed, ignoring per-user restrictions.
  3. Share Query: Following successful logon, the Windows 98 networking client queried the authenticating domain controller's NETLOGON share for the presence of CONFIG.POL. Alternatively, administrators could specify a manual path via registry settings to download policies from an alternate server using update mode.

Registry Merging and Evaluation Order

Once downloaded to the local machine, Windows 98 read the contents of CONFIG.POL and applied settings according to a strict priority hierarchy:

  1. Default User / Specific User: The system checked CONFIG.POL for a section explicitly matching the logging-in username. If an individual user entry existed, its settings were staged for application. If no user-specific entry was defined, the system applied the Default User settings.
  2. Group Priorities: If the user belonged to global domain groups, Windows 98 evaluated group-level policies. Because a user could belong to multiple groups, the administrator determined an execution order within the System Policy Editor. Settings from higher-priority groups superseded those from lower-priority groups.
  3. Computer-Specific Settings: The client checked for machine-specific rules matching the local NetBIOS computer name. If not present, it applied the Default Computer settings.

After evaluating these sections, Windows 98 merged the values into the local registry. Machine policies were written directly into HKEY_LOCAL_MACHINE, while user and group policies were written into HKEY_CURRENT_USER.

The "Tattooing" Phenomenon and Security Limitations

Unlike the modern Windows Group Policy architecture, Windows 98 system policies modified the actual target keys in the registry rather than separate, volatile policy keys. This behavior was commonly referred to as "registry tattooing." If a network administrator subsequently removed a restriction from CONFIG.POL, the restriction remained permanently embedded in the client's local registry (USER.DAT or SYSTEM.DAT) until the administrator explicitly created a countervailing policy to enable the restricted feature.

Furthermore, Windows 98 lacked the underlying NT kernel architecture, access control lists (ACLs), and file-level security. Consequently, policy processing in Windows 98 acted as an operational deterrent rather than a hardened security boundary. Advanced users could potentially bypass applied policies by booting into Safe Mode, editing the local registry prior to network logon, or pressing the Escape key at the logon prompt if standalone workstation bypass settings were not explicitly hardened.