Some of the main topics in this chapter are

• Preventing access to the Registry Editor
  
  
• Securing individual Registry keys in Windows NT 4.0
  
  
• Auditing Registry keys in the Windows NT 4.0 Registry

Windows NT 4.0 makes it very easy to manage the security of the Registry. You can do things as simple as blocking a user's access to the Registry Editor. You can also manage the security of individual branches and Registry keys. Here's what you'll learn in this chapter:

• If your only concern is preventing users from tampering with the Registry, use Windows NT 4.0's file permissions to prevent them from even getting at the Registry Editor.
  
  
• Windows NT 4.0 creates an Access Control List (ACL) for each and every Registry branch and key. This list determines who can and can't access each key. You can modify these permissions for an entire branch or just a specific Registry key.
  
  
• Windows NT 4.0 enables you to audit what a user does in the Registry. You can audit both successes and failures for a variety of event types.

• Windows NT 4.0 also provides a mechanism to control who can access the Registry remotely. This mechanism is a completely cryptic way to control remote access to the Registry. This section shows you how to do it, nonetheless.

Blocking a User's Access to the Registry

The easiest way to prevent a clumsy user from messing up the Registry is to prevent him from getting at the Registry Editor. You don't have to worry about the permissions of individual Registry keys at all. If the user has no access to the Registry Editor, it doesn't matter. Here are some methods you can use to completely prevent access to the Registry through the Registry Editor:

• Maintain complete control of who can log on to the server with administrative privileges. I've worked in many shops in which just about every programmer had some sort of administrative privilege to the server. You should maintain more control than this if you want to secure your server.
  
  
• Short of actually removing REGEDT32.EXE and REGEDIT.EXE from a server, you can place restrictions on which groups and users can actually run the Registry Editor. Locate REGEDT32.EXE in C:\WINNT\System32, right-click it, and then click the Security tab. Do the same for REGEDIT.EXE in C:\WINNT. You'll see a dialog box that looks like Figure 44.1. Change the permissions for REGEDT32.EXE as necessary, and click OK. This only works if you're using NTFS.

Fig. 44.1

I recommend that you remove permission to REGEDT32.EXE and REGEDIT.EXE for everyone but the Administrators group.

• Control access to each user's profile by changing the permissions on the hive's file in Windows NT Explorer. Locate the user's profile in C:\WINNT\Profiles, and change the permissions for it just as you did in the previous bullet for REGEDT32.EXE.

---

CAUTION: Don't try changing permissions for the other hives you find in C:\WINNT\System32\Config. Windows NT 4.0 automatically manages the permissions on these files. You can cripple your NT system if you tinker with these.

---

Changing the Access Control List (ACL) for a Key

You can control who has access to a particular branch or Registry key. For example, you can prohibit users from removing any subkeys under HKEY_CLASSES_ROOT, or you can allow only administrators to change a custom key you've added to the Registry.

In general, however, you should change the ACL only for Registry keys that you've specifically added in order to support your own needs. In other words, I don't recommend that you tinker with the ACL for the Registry keys that Windows NT 4.0 or other programs install in your Registry. NT automatically manages those for you. Why? Changing an ACL to No Access for a key that the system must have access to in order to start can prevent Windows NT from starting.

---

TIP: You can change the ACL for a Registry key whether you're using NTFS or FAT.

---

If you really must change the ACL for a Registry key, use the Registry Editor and follow these steps:

1. In REGEDT32, select the branch or Registry key for which you want to change the ACL.

2. Choose Security, Permissions to reach the Registry Key Permissions dialog box (see Figure 44.2).

Fig. 44.2

Look familiar? This dialog box is similar to the File Permissions dialog box shown in Figure 44.1.

3. Select Replace Permission on Existing Subkeys if you want to update the permissions for all subkeys under the selected key.

4. Click Add to add names to the list of groups and users who you want to be able to access this Registry key. Select a name and click Remove to remove a name from the list of groups and users who you don't want to be able to access this Registry key.

5. For each name in the list, change its permissions by selecting the name and selecting a type of permission in Type of Access. Table 44.1 describes each type of access. Full Control is the default value.

6. Click OK to save your changes.

Table 44.1 Access Types for Registry Keys

Access Type	Description
Read	The selected group or user can read the key's contents, but not change the key.
Full Control	The selected group or user can read, change, or delete the Registry key.
Special Access	The selected group or user has the permissions set in the Special Access dialog box, which pops up right after selecting this option. See the next section, "Auditing Registry Access," for more information.

---

NOTE: If you've changed the ACL for a Registry key, turn on auditing for failures and test the system thoroughly to make sure that it still works as expected. If you encounter errors, check the event log to find out why. After you're satisfied that the change didn't prevent Windows NT 4.0 from working properly, turn off auditing. Otherwise, restore the ACL for the Registry key, and try again.

---

Auditing Registry Access

Setting up permissions for branches and individual Registry keys is only the first front. The second front is to audit what goes on in the Registry. Windows NT 4.0 logs when a user unsuccessfully attempts to do something with a Registry key. You can also have NT log all access to the Registry, but that's a bit of a grind on NT's resources.

---

TIP: You can use auditing to determine what Registry keys an application adds or changes.

---

Auditing changes in the Registry involves a two-step process. First, you have to turn on auditing in the User Manager by following these steps:

1. Open User Manager or User Manager for Domains.

2. Choose Policies, Audit. You see the Audit Policy dialog box shown in Figure 44.3.

3. Select Audit These Events and select Success or Failure for each type of event you want to audit. In particular, at the very least you should select Failure for File and Object Access.

4. Click OK to save your changes and close the User Manager.

---

TIP: Drag a shortcut to the Event Viewer into your Start menu's StartUp group so that you can check audit events frequently.

---

After you've enabled auditing in the User Manager, you need to enable auditing in the Registry. You can enable auditing for a specific key or for an entire branch of the Registry:

1. Select the branch or Registry key that you want to audit. For example, if you've recently changed the ACL for a Registry key, select that key.

2. Choose Security, Auditing to reach the Registry Key Auditing dialog box (see Figure 44.4).

3. Select Audit Permission on Existing Subkeys if you want to audit all subkeys under the selected Registry key. If you're not careful about the size of the branch you select, your system could grind to a halt.

Fig. 44.3

File and Object Access events include events that occur in the Registry.

Fig. 44.4 The Registry Key Auditing dialog box works similarly to other auditing dialog boxes in Windows NT 4.0.

4. Click Add to add names to the list of groups and users who you want to audit. Select a name and click Remove to remove that name from the list of groups and users who you want to audit.

5. Select a name in the list of groups and users, and change the Success or Failure for each type of event you want to audit. Table 44.2 describes the types. At the very least, you'll want to audit the Set Value and Delete events so that you know when someone has done something that could harm the system.

6. Click OK to save your changes. If you didn't select Audit Permission on Existing Subkeys, the Registry Editor asks whether or not you want to audit all subkeys under the selected key.

Table 44.2 Types of Audit Events

Audit Event	Description
Query Value	Log events that try to open the key with Query Value access
Set Value	Log events that try to open the key with Set Value access
Create Subkey	Log events that try to open the key with Create Subkey access
Enumerate Subkeys	Log events that try to enumerate subkeys under the selected key
Notify	Log events that try to open the key with Notify access
Create Link	Log events that try to open the key with Create Link access
Delete	Log events that try to delete the key from the Registry
Write DAC	Log events that try to determine who has access to the key
Read Control	Log events that try to determine the owner of the key

After you enable auditing for the Registry, you can view the events you're auditing in the Event Viewer. Open the Event Viewer, and choose Log, Security. You'll see a dialog box similar to Figure 44.5.

Fig. 44.5

The Event Detail dialog box tells you who changed the Registry, when he made the change, and what key the change affected.

---

NOTE: Consider limiting your audit to failures for the File and Object Access type of event. This limits the numbers of entries in the Event Viewer and reports failed attempts to access the Registry. This also prevents the heavy burden on the computer that comes from auditing too many types of events for too many Registry keys.

---

Controlling Remote Access to the Registry

In the previous sections, you learned how to control who can access each Registry key. You can also use this ACL for a special Registry key to determine who can access the Registry remotely. This method is a bit cryptic, but it works.

When a user tries to remotely connect to the Windows NT 4.0 Registry, NT checks the ACL for this Registry key (I'll just call it winreg from now on):

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg

One of two things can happen:

• If Windows NT finds winreg in the Registry and the user has permission according to the ACL for winreg, the user is allowed to remotely connect to the Registry. In other words, the ACL for winreg determines which users can remotely access the Registry. Then the ACL for each key the user tries to access defines what the remotely connected user can and can't do to it.

• If Windows NT doesn't find winreg in the Registry, it enables all users to remotely connect to the Registry. The ACL for each key then defines what the remotely connected user can and can't do to it.

To change the ACL for winreg, thus controlling who can remotely connect to the Registry:

1. Open REGEDT32 and add HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Control\SecurePipeServers\winreg to the Registry.

2. Select the new key, and choose Security, Permissions to reach the Registry Key Permissions dialog box (see Figure 44.6). By default, Windows NT 4.0 gives full control to administrators and pretty much everything but delete permission to users.

3. Add, remove, or change the permissions as you learned in "Changing the Access Control List (ACL) for a Key," earlier in this chapter.

4. Click OK to save your changes.

Microsoft makes some specific recommendations for creating a highly secure installation. They recommend that you change the ACL for the following Registry keys so that the Everyone group only has Query Value, Enumerate Subkeys, Notify, and Read Control access:

HKEY_LOCAL_MACHINE\Software\Microsoft\RPC and all its subkeys

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Profile List

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Compatibility

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Drivers

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Embedding

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Fonts

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\GRE_Initialize

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\MCI

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\MCI Extensions

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Port and all of its subkeys

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WOW and all of its subkeys

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows3.1 MigrationStatus and all of its subkeys

HKEY_CLASSES_ROOT and all its subkeys

If you don't recall how to use Special Access for a key, see "Changing the Access Control List (ACL) for a Key," earlier in this chapter (unless otherwise noted, don't change the ACL for an entire branch--only the given key).

---

© Copyright, Macmillan Computer Publishing. All rights reserved.