Return to index.
While Windows 98 is not a true multi-user OS (in the sense that it doesn't implement any local file security checks), it does have support for multiple user profiles to keep different users' settings apart.
The Control Panel 'Passwords > User Profiles' dialog enables multiple user profiles, which are managed through the 'Users' control panel. (Opening 'Users' and going through the wizard will also enable the same option.)
Each user can have their own separate HKCU registry, plus their own 'Application Data' or 'Desktop' or other folders that are enabled to be per-user.
HKLM\Software\Microsoft\Windows\CurrentVersion\ProfileList\%USER%
C:\WINDOWS\%USER%.PWL
C:\WINDOWS\Profiles\%USER%
Although Windows 95 supports this feature, it lacks the UI for managing users (there is no 'Users' control panel yet') – new users can be created by logging in for the first time, but not easily deleted. (This doesn't matter much as there's no user list at logon either, so the profiles can just quietly accumulate, or be manually deleted via Regedit.)
A somewhat confusing parameter is the "Primary Network Logon" selection in the 'Network' Control Panel dialog:
This option lets you choose from the 'Client' components installed in the list immediately above, plus an additional "Windows Logon" option that is built-in.
The way it seems to work is that all installed providers get loaded, and all have a chance to display a logon prompt, in unknown order except for the "Primary" provider being the first. For example, if "Windows Logon" is primary, then it will show its dialog first and will pass the credentials on to "Client for Microsoft Networks", which may then show its own dialog if needed.
If primary provider, shows a list of local users (only if the feature is enabled in 'Passwords > User Profiles') and validates against their local password file (%USER%.PWL).
If not primary provider and an unknown username was received from the primary provider, will prompt to create a local profile (although this may actually be the doing of the "Windows Logon" provider – I'm not sure).
Shows the "Welcome to Windows" username/password prompt. Validates against local password file (%USER%.PWL). If an unknown user was input, will prompt to create it.
The password is checked against the .PWL even if the provider is not primary, so the same user can have different 'network' and 'Windows' passwords, causing two logon dialogs to show up. (This can be avoided by reversing the provider order – selecting the "Windows Logon" provider as primary and allowing the "Microsoft Networks" provider store the network password in the .PWL file.)
However, this provider remembers the last used username and will skip the prompt if the last-used user's local password is blank.
Shows the "Enter Network Password" username/password prompt. By default, performs no validation and merely remembers the password for later use with SMB connections (meaning that if the provider is not primary, it will only inherit the password from the previous provider and won't show its own dialog).
Can be configured to validate logons against NT domain controller. In this mode, an additional 'Domain:' field becomes available at logon time. (In case of multiple domains with trust relationships, the initially configured domain needs to be local so that its domain controllers may be discovered via NetBIOS.)
Additionally, if the provider is not primary it will still show a network logon dialog in case the primary password failed validation, and will offer a checkbox to store the domain password in the Windows password list. (However, the PWL cannot store usernames, so this option is only effective when local and network usernames match.)
Enables domain-level password checking for local logons (otherwise the provider only stores the password for later use with outbound connections, but doesn't immediately validate it).
Enables domain-level user checking for inbound SMB connections (otherwise share-level security is used). The folder sharing dialog changes from its traditional share-oriented mode to being user-oriented as in WinNT (including per-user access levels).
Doesn't affect local logon in itself, but relies on having valid SMB credentials to retrieve user lists (as there is no 'machine' account), so it is best paired with "Log on to Windows NT domain".
