9.7 Miscellaneous Good Stuff

So far in this book, you've learned how to use a variety of tools to modify, back up, and restore the Registry. At this point, though, you might be wondering what you can actually do with some of these tools. There are some common and necessary administrative tasks involving the Registry; knowing how to perform them will help keep the machines under your care stable, secure, and safe.

9.7.1 Changing the Registry Size

Since the Registry is a collection of hives, most of which are actually disk files, you might not realize that Windows 2000 (and NT) actually maps the entire Registry into memory. Doing so makes it possible for Registry calls to perform efficiently; however, it means that as the Registry grows it takes up a larger proportion of the virtual memory space in your system. To prevent the Registry from sucking up too much space in the system's page file, the system maintains an internal parameter called the Registry Size Limit, or RSL. The RSL sets an upper bound on how much address space the Registry may occupy; however, as you add software and users to your machines, the Registry gets larger. If it gets so big that it starts to bump up against the RSL, problems will occur. (Go to the Microsoft Knowledge Base at http://www.microsoft.com/kb/default.asp and search for "Maximum Registry Size" to see a long list of such problems, most of which are reasonably obscure.)

By default, the RSL is set at about 20-25% of the total virtual memory allocation for the system. This limit is a maximum, not a guarantee, and the limit set by the RSL doesn't actually mean that much space is reserved, just that the system can't use more than that. There's a complex relationship between the total size of the pool of available virtual memory and the RSL; in general, you should keep the RSL at 80% or less of the total virtual memory allocation. Failure to do so can result in impressive performance losses.

The Virtual Memory dialog (see Figure 9.8) shows you the current RSL and the current amount of space in use by the Registry. If the current size is more than 80% of the RSL, you should increase it. When choosing a new RSL, be sure to keep it below 80% of the total virtual memory size; in general, you shouldn't ever need to increase it above 33% of the virtual memory size. If you need more space even with an RSL 33% as big as your virtual memory stash, consider increasing the size of your virtual memory, then increase the RSL.

Figure 9.8. The Virtual Memory dialog

You adjust the RSL through the Virtual Memory dialog pictured in Figure 9.8; how you get to it depends on whether you're using Windows 2000 or NT. In Windows 2000, open the System control panel and click on the Advanced tab, then click the Performance Options button. In Windows NT, open the System control panel and click on the Performance tab. In either case, once the Performance dialog appears, click the Change button in the Virtual Memory control group, and the Virtual Memory dialog appears. Type a reasonable value into the Maximum Registry Size field, then click OK and close the Virtual Memory dialog and the System control panel. You re then notified that your changes won't take effect until the next restart.

9.7.2 Auditing Registry Access

In Section 5.9 in Chapter 5, you learned how to apply auditing controls to any key in the Registry. Since Windows 2000 and NT store so much critical configuration data in the Registry, auditing some of it is a good idea; there are a number of keys you can audit to keep an eye on potential security problems or to catch users doing things they shouldn't be.

Windows components and applications often determine whether a specific key is present by trying to read it and noting if the attempt fails. This is normal, and it's so common that I recommend you avoid auditing failed attempts on the Read, Query Value, or Enumerate Subkeys operations; doing so generates lots of unnecessary audit log entries.

Once you turn on auditing, the events you specify are stored in the system's event log. Since the event log files are your record of what auditable events have taken place, you need to make sure that they're protected against tampering too! Set their permissions to include Full Control for CreatorOwner, SYSTEM, and Administrators and Read for Everyone, then make sure no other users have write access to the log files.

9.7.2.1 Making sense of the audit log

When you enable auditing, the security reference manager process writes an audit entry to the security event log whenever one of the conditions you specify comes true. Here's a sample entry:

12/2/97 11:27:19 PM Security Success Audit Object Access 560 Administrator BOOMBOX 
    Object Open:
    Object Server:  Security
    Object Type:    Key
    Object Name:    \REGISTRY\USER\S-1-5-21-34824712-245319459-1244863647-500
    New Handle ID:  240
    Operation ID:   {0,47947}
    Process ID: 2161664032
    Primary User Name:  Administrator
    Primary Domain: BOOMBOX
    Primary Logon ID:   (0x0,0x1E35)
    Client User Name:   -
    Client Domain:  -
    Client Logon ID:    -
    Accesses        Create sub-key 
        
    Privileges      -

I got this by turning on file/object access auditing in User Manager, then using RegEdt32 to audit HKCU for successful Create Subkey access requests. Once I did, every time I created any subkey under HKCU, I got a new audit record like the one in the example.

As you can see, this record tells me what key was the target of the request (the Object Name field), what username made the attempt (along with that user's domain), and what access or privileges were requested. If you want to routinely scan your event logs for Registry accesses, I suggest using a tool such as SomarSoft's DumpEvt (http://www.somarsoft.com), writing your own Perl script to parse the Event Log using functions in the Win32::EventLog module or using a third-party tool like RippleTech's LogCaster (http://www.rippletech.com).

9.7.2.2 Tracking software installations or reinstallations

Any software that uses the Registry (which means any package wearing the "Designed for Windows" logo, plus lots of others) leaves tracks in either HKLM\SOFTWARE or HKCU\SOFTWARE. Microsoft's recommendation is that software vendors create their own subkey of one of these two keys, so you'll see lots of entries like HKLM\Software\Netscape and HKLM\SOFTWARE\Qualcomm. You can audit these keys directly, or you can audit only specific subkeys of interest. For example, if you want to see an audit notice whenever someone adds new software to a machine, you can add an audit entry for "Create Subkey" on HKLM\SOFTWARE. If instead you wanted to know when someone installs only software made by Netscape, you can audit "Create Subkey" on HKLM\SOFTWARE\Netscape and HKCU\SOFTWARE\Netscape.

The need to do this is relaxed somewhat in Windows 2000, since users' privileges to install software are more constrained. Users can install applications for themselves, but they can't install software other users can run; only administrators can do that. Accordingly, you may not find it necessary to audit HKLM.

9.7.2.3 Guarding against Trojan horses

Windows 2000 and NT allows administrators to install one or more DLLs that validate passwords before passing them to the logon subsystem. The NetWare gateway tools shipped with NT use such a DLL, and the documentation for what such a DLL should do is available from Microsoft. This opens the door for a user to install a password-grabbing DLL that just stores the password in a file without changing it, then passes it on to the logon subsystem. The list of these DLLs is maintained in the HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages key. I strongly recommend that you set appropriate permissions and turn on auditing for this key.