The Windows NT Registry includes many keys that you can adjust to heighten security on your systems. Many previous articles in Windows NT Magazine have discussed how to adjust these keys' values to improve security. (For more information about these articles, see "Related Articles in Windows NT Magazine," page 84.)
Instead of discussing again how to set numerous specific keys' values, this article explains how you can control which users can access a Registry key. Permission settings on Registry keys are similar to file and directory permissions, and you can easily set Registry permissions through regedt32. I recommend restricting user permissions on several important keys to protect the integrity of your systems.
Remember to be extremely careful when you edit the Registry, because Registry errors can render a system unbootable. Be sure to have a current Emergency Repair Disk (ERD) before you make any of the modifications that this article describes.
Setting Permissions
To set permissions on a Registry key on an NT Server 4.0 or NT Workstation 4.0 system that is running Service Pack 4 (SP4), open regedt32 via the Start menu's Run command. When the Registry editor opens, drill down to the key you want to set permissions for. With the key selected, choose Permissions from regedt32's Security drop-down menu. The Registry Key Permissions dialog box appears. The dialog box looks similar to NT Explorer's File Permissions dialog box; it lists user account names and the permissions associated with those accounts.
To add permissions for a user or group, click the Add button. The Add Users and Groups dialog box appears; the dialog box lists the groups in your domain. You can click Show Users to include the domain's user accounts in the list. Select the name of the account or group you want to add, choose between Read and Full Control in the Type of Access drop-down list, and click OK. To remove a user or group, select the account or group name on the Registry Key Permissions dialog box's list and click Remove.
To modify a user's or group's permissions, select the username or group name in the Registry Key Permissions dialog box, click the Type of Access drop-down list, and select Special Access. The Special Access dialog box opens, itemizing the specific permissions that the selected account or group has for the selected Registry key. To modify the permissions, select or clear the appropriate check boxes.
NT on the Software Tree
Microsoft recommends that administrators restrict users' access to certain subkeys of servers' HKEY_LOCAL_MACHINE\ SOFTWARE key tree to prevent users from tampering with the system's software. Microsoft recommends giving the Everyone group only Query Value, Enumerate Subkeys, Notify, and Read Control permissions on the HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows NT\CurrentVersion key and on the following subkeys of that key: AeDebug, Compatibility, Drivers, Embedding, Font Drivers, FontCache, FontMapper, Fonts, FontSubstitutes, GRE_Initialize, MCI, MCI Extensions, Ports (and all of Ports' subkeys), Type 1 Installer, Windows3.1MigrationStatus (and all of Windows3.1MigrationStatus' subkeys), and WOW (and all of WOW's subkeys). Microsoft also endorses restricting users to the same four permissions on the Uninstall, Run, and RunOnce subkeys of the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion Registry key.
Changing permissions on the performance library key, HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib, is a good idea. By default, the Everyone group has Read access to this key, which can leave a system's performance data open to intruders who are snooping around for information. I suggest removing the Everyone group's Read access for the Perflib key and providing only the Interactive group with Read access. This change gives access to the performance counter keys only to the System account, members of the Administrators group, and accounts that have logged on interactively.
Finally, you should restrict user access to the HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows NT\ CurrentVersion\ProfileList key. By default, the Everyone group has Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, and Read Control permissions on this key. This permission set lets users modify their profiles without an administrator's knowledge. I recommend removing these values for the Everyone group. However, when new users log on to an NT system for the first time, they need access to the ProfileList key. If you remove the Everyone group's permissions, you need to give the Interactive group Query Value, Create Subkey, Enumerate Subkeys, Notify, and Read Control permissions.
The Root Class, User, and System Hives
I recommend restricting the Everyone group's permissions to Query Value, Enumerate Subkeys, Notify, and Read Control on several Registry keys outside of the HKEY_LOCAL_MACHINE\SOFTWARE key. First, restrict the Everyone group to these permissions on all subkeys of the HKEY_CLASSES_ROOT hive to prevent users from tampering with object classes and their associations—for example, changing which program opens a certain type of file.
Second, restrict the Everyone group to the same four permissions on the .DEFAULT subkey of the HKEY_USERS hive. NT uses the user profile that the system stores in the HKEY_USERS\.DEFAULT key to create a profile for users who haven't logged on to the system before. Protecting the key prevents users from tampering with numerous desktop and system settings—for example, changing some of Internet Explorer's (IE's) basic security settings.
Finally, to strengthen system security, restrict the Everyone group to the same set of four permissions on two subkeys of the HKEY_LOCAL_MACHINE hive: \SYSTEM\CurrentControlSet\ Services\LanmanServerShares and \SYSTEM\ CurrentControlSet\Services\UPS. Restricting access to these two keys helps administrators prevent users from tampering with a system's share points or using the UPS key's ImagePath entry to execute software you don't want the users to run. After you set the UPS subkey's permissions, adjust permissions on any associated command files that your UPS service uses. Command files need to give access only to the System account and to members of the Administrators group. The System account and Administrators group need the Full Control permission set for command files if you prevent all other accounts from accessing these files.
Applications' Registry Entries
You'll probably also want to restrict users' permissions on Registry keys that relate to the primary applications you run. Microsoft products' installations and upgrades usually add keys to the Registry. Many third-party products' installations also change the Registry. To protect your crucial applications, you need to limit permissions on these keys. For example, if you install IE 4.x, you'll find a new subkey named RunOnceEx in the HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\ Windows\CurrentVersion Registry key. You need to adjust permissions on the RunOnceEx subkey because NT automatically executes any programs in the RunOnceEx key's value and removes the programs from the key, which lets users execute rogue programs on the system. Limit the Everyone group's permissions on the RunOnceEx key to Query Value, Enumerate Subkeys, Notify, and Read Control.
After you install software on your system (whether the software is from Microsoft or a third-party vendor), you need to inspect your Registry to see which keys the installation modified or created. You can use several tools to find these Registry changes. I like Regmon, which Mark Russinovich and Bryce Cogswell created. (You can download the tool from http://www.sysinternals.com/regmon.htm.) Regmon runs under NT or Windows 9x on Intel and Alpha platforms. The utility monitors all access to the Registry during a specified period and clearly reports which keys the system accessed. However, Regmon isn't always the best tool for tracking Registry changes during software installations, because it sometimes creates loads of log entries that you need to examine to figure out which Registry values changed.
Instead, you might prefer to use a tool such as Sysdiff, which comes in the Microsoft Windows NT Server 4.0 Resource Kit. You can use Sysdiff to make a preinstallation image of your Registry by dumping the Registry to a file before you install new software. After the new software's installation completes, you can use Sysdiff to make a postinstallation Registry image and compare the two images. Sysdiff will quickly reveal any differences between the pre- and postinstallation Registry images. You can then examine the installation's changes and consider the changes' implications for your network's security.
If you don't have Sysdiff in your security toolkit, I urge you to add it as soon as possible. Sysdiff is well worth the cost and effort of purchasing and installing the resource kit. (For information about how to use Sysdiff, see the resource kit documentation and Help files.)
When you find that a software installation has changed some of your system's Registry keys, consider which users need which permissions on those keys. Many third-party applications require read and write access to keys that they install, so you can't simply limit everyone except administrators to Read access on all SOFTWARE subkeys. Configure permissions on keys that software installations create or modify to limit users and groups to the minimum level of access that they need.
Don't Save RAS Passwords!
Finally, I would like to share one Registry value that you might not know about but that can be very important to your network's security. NT's Dial-Up Networking (DUN) service presents dialog boxes in which users enter usernames and passwords to connect to a network via RAS. These dialog boxes often include a check box labeled Save This Password or Remember This Password. Telling NT to remember your DUN passwords is quite handy, because the practice saves you from remembering the passwords. But having NT save DUN passwords poses a risk to your network. The problem with this functionality is that NT must store the passwords in a location that allows easy retrieval, and if NT can easily retrieve passwords, so can an intruder. Consider the implications for your network if someone steals a notebook computer that stores a user's NT DUN passwords. The thief can easily access your network. Ouch!
Disabling NT's ability to store DUN passwords is usually the best way to protect yourself from this danger. On your NT DUN client, drill down to the Parameters key, and add a REG_DWORD entry entitled DisableSavePassword. The existence of this value prevents the Save This Password check box from appearing in DUN dialog boxes.
Ongoing Security
I hope this article has made you aware that you can strengthen NT by adjusting aspects of the system's Registry. Microsoft adds and removes Registry adjustments with each new OS and application revision. If you don't remember anything else from this article, at least remember to examine your Registry before and after adding, upgrading, or removing software on a particular system and adjust security accordingly.
