Enhance Security Through Registry Permissions

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.