5.11 Securing Registry Keys in Windows NT

When using RegEdt32 under NT, you'll notice a few things that differ between Windows 2000 and NT. For starters, the Security menu has more commands in it; when you use these commands, the user interface is different as well. However, for the most part the underlying behavior is the same. If anything, NT is less flexible than Windows 2000 because it doesn't have all the same inheritance and permission controls.

5.11.1 Setting Permissions

The SecurityPermissions... command displays the Registry Key Permissions dialog (see Figure 5.18). To use it, select a key in any root key window, then give the command. When the dialog opens, it shows which key you've selected and which account owns it (you can't change either of them from the dialog, however). The controls in the dialog give you access to the permission settings for the key.

Figure 5.18. Registry Key Permissions dialog

• The "Replace Permission on Existing Subkeys" checkbox tells RegEdt32 whether to apply the permission changes you specify to all subkeys of the current key or not. When subkeys are created, they inherit the parent key's access controls. However, by the time you change the parent key's access controls, the subkeys may have different controls in place. Use this option only when you intend to override any access controls that have been applied to subkeys.

• The Name field lists the current access controls in force on the key. Each line in the list shows an account name and the DAC granted to that account. The standard DACs are listed in Table 5.2 and Table 5.3. The Type of Access combo box lets you change the DACs for any account in the Name list. Changes you make are immediately reflected in the list, but aren't applied until you click OK.

• The Add... button allows you to use NT's standard "Add Users and Groups" dialog (see Figure 5.19) to add new accounts to the ACL. The accounts you add from this dialog appear in the Name list with Full Control as the default DAC; make sure you change this to avoid opening a security hole.

Figure 5.19. The Add Users and Groups dialog

5.11.2 Auditing Registry Key Activity

Auditing allows you to keep a trail of evidence to identify problems and pin their start down to an exact time. NT's auditing facility lets you audit specified actions taken by specified accounts. For example, you can audit any attempt to change security policy by any accounts, or you could audit failed attempts to log on by a single account. This combination of specifying who and what makes auditing pretty flexible.

5.11.2.1 Enabling auditing on an NT machine

While auditing is useful, it also takes time. By default, NT leaves system auditing turned off. Before you can audit Registry access (or anything else), you have to enable auditing on the machine you want audited.

You do this with the User Manager or User Manager for Domains,^[6] yet another of the standard administrative utilities NT includes to simplify your job. Here's how to enable auditing on a single server or workstation:

^[6] Which one you get depends on whether you're using Windows NT Workstation or Server. Workstations always get the vanilla User Manager, and servers (in or out of a domain) always get User Manager for Domains. Fortunately, they're very similar, so I'll treat them here as identical.

Figure 5.20. The Audit Policy dialog

Once you take these steps on a machine, you won't have to do them again; auditing on that machine will remain enabled unless you manually turn it off using the same procedure. You do, however, have to execute these steps on every machine for which you want to enable auditing. Once you've done so, you can actually turn on auditing for the Registry.

5.11.2.2 Telling RegEdt32 what to audit

The Registry Key Auditing dialog, shown in Figure 5.21, appears when you choose the SecurityAuditing... menu command.

Figure 5.21. The Registry Key Auditing dialog

This dialog can be a little confusing at first, so a look at what its controls do will demystify it some:

• The "Registry Key" field shows you what subkey you've selected, but it doesn't tell you what root that subkey belongs to. You may need to move the entire Registry Key Auditing dialog around to make sure you're auditing the key you intended to audit.

• The "Audit Permission on Existing Subkeys" checkbox tells RegEdt32 whether you want the audit changes you specify to apply to all subkeys under the selected key or just the selected key. If you audit all subkeys of a large root key like HKLM, your performance will suffer. Sometimes, though, this type of shotgun auditing is necessary so you can see which keys are being changed when you don't know in advance which ones you need to audit.

• The "Name" list shows which accounts will be audited. You can think of this list like the FBI's Most Wanted list: names on this list are the ones scrutinized, while other names are ignored. The Add... and Remove buttons let you change the members of this list using an interface like the one shown in Figure 5.19. In addition to actual user accounts, you can audit the built-in accounts like Everyone, INTERACTIVE, and SYSTEM.

• The two columns of checkboxes in the "Events to Audit" group are the meat of this dialog, since they control what actions are logged for the specified accounts. Each of the DACs listed earlier in Table 5.2 may be audited. When you check a DAC's Success checkbox, the system creates an audit record any time an account on the Name list succeeds in using that DAC. Conversely, the Failure checkbox causes NT to generate an audit record when a listed account tries to use the DAC and fails.

  For example, let's say you add the account peanut to the audit list for HKLM\Software\Microsoft, then check Success for Create Subkey and Failure for Write DAC. Once you save those settings, NT generates an audit record whenever peanut succeeds in creating a new subkey under the selected key or fails while trying to change the DACs for an ACL entry.

As you'd expect, the OK and Cancel buttons allow you to preserve or discard changes you make in this dialog.

5.11.2.3 Reviewing the audit records

Once you've told RegEdt32 what to audit, you still need to see the audit entries that have been generated. If you're accustomed to administering Unix machines, you're probably familiar with the syslog service. NT has a similar feature; it keeps an event log that applications and system components may write to. The NT event log is actually three separate logs: one for system data, one for application-generated data, and one for security data. Auditing messages (no matter their source) go into the security log.

To view these log messages, you'll need to use Microsoft's Event Viewer application. A complete discussion of how to use the Event Viewer is outside the scope of this book, but the basic process is simple enough to boil down into a few concise steps:

Figure 5.22. The Event Viewer application

Figure 5.23. Registry audit event detail display

5.11.3 Changing Key Ownership

Like every other object in NT's world, each Registry key has an owner. As with Unix, NT allows the owner to control access to objects it owns to a certain extent; the superuser or Administrator account can always take ownership of an object and change its permissions when necessary. NT does, however, provide a standard auditing mechanism that logs all manually initiated changes of ownership, so you'll always have an audit trail that shows when someone's taken over one of your objects.

When you use this command, you're telling RegEdt32 to change the owner of the currently selected key and all its subkeys to the current account. This blanket change of ownership can lead to unexpected behavior, since many NT components assume they'll always have unrestricted access to all subkeys of HKLM and many subkeys of HKCU and HKCR. However, it's usually a good idea to set appropriate ownership of HKU 's subkeys, as well as those subkeys of HKLM that are safe to reset. The best way to set ownership is with a utility like David LeBlanc's everyone2user, which is discussed in Section 9.4 in Chapter 9.

If you insist on doing it manually, RegEdt32 allows you to take ownership of Registry keys with the SecurityOwner... command. The Owner dialog, pictured in Figure 5.24, shows you what key is selected and which account owns it. The Take Ownership button changes the key's (and its subkeys') ownership to whatever account you're logged in as, while the Close button cancels the command without changing anything. Of course, if you don't have Administrator privileges you can't take ownership of any key you don't already own.

Figure 5.24. The Owner display