Backing Up and Securing the Registry and Manipulating Hives and Keys

Windows IT Pro

- Advertise

Backing Up and Securing the Registry and Manipulating Hives and Keys

Author:	Darren Mar-Elia
Published:	August 2000
Copyright:	2000
Publisher:	Windows IT Library

Abstract
This chapter explores some key elements of manipulating the Windows 2000 Registry: backing up and restoring the Registry, securing the Registry (including using Group Policies), and manipulating hives and keys.

REGISTRY BACKUP AND RECOVERY

Windows NT 4.0 offers several ways to back up and recover the Registry or the individual hives in the Registry. The easiest way is to use the Emergency Repair Disk (ERD). The ERD simply copies local hive files found in %systemroot%\system32\config to %systemroot%\repair, with the option of copying them to a floppy as well. You also could use Resource Kit backup utilities or a third-party backup program to copy the hive files to tape.

The ERD method is of limited value, though, because you can’t copy large SAM files to a floppy, and it is only effective if you run rdisk.exe frequently. As a result, Windows 2000 (Win2K) has done away with rdisk.exe and the ERD as we know it in NT 4.0. There is still an option to create an ERD in the Win2K backup utility (discussed in the next section), but it backs up only three files: autoexec.nt, config.nt, and setup.log.

Setup.log is a list of the system files on your machine and it includes a checksum value that indicates the correct version of the file. You can use setup.log to restore corrupt system files when you boot from a Win2K CD and choose the repair option. If you run the ERD process from the NT Backup utility, you are given an option to back up current Registry hives to the repair directory on your system’s hard drive prior to creating the ERD floppy. If you choose this option, all Registry hives are copied to a directory called regback in %systemroot%\repair. This option also copies the current user’s ntuser.dat file to this folder, as well as the user-specific COM Classes portion of the user profile (to a file called usrclass.dat). This is the equivalent in NT 4.0 of running rdisk with the option to not create a floppy. If required, you can use these saved reg hives during a system repair process.

Win2K Backup
Just as in NT 4.0, Win2K provides a free utility for backing up system and data files to tape. It supports backups written to media other than tape (e.g., to fixed or removable disks). Note, however, that this limited backup utility does not support the remote storage features that Win2K provides — that is, you can’t back up to a remote media pool using the included utility.

But most importantly for our purposes, the utility does support Registry backup and restoration. Registry backup is included as part of something called “System State” backup, which also includes critical boot files and, on domain controllers, the Active Directory (AD). To use this function, start the Win2K Backup utility by selecting Start Menu, Programs, Accessories, System Tools, Backup; or type ntbackup.exe at the Start Menu, Run dialog box. When Win2K Backup starts, you see the Welcome Page, with wizards for automating the backup and restoration processes.

To back up the Registry using Win2K Backup, choose the Backup Wizard or select the Backup tab. If you use the Wizard, the next step prompts you for what you want to back up. If you run Win2K Backup on a Win2K Domain Controller, you can back up the AD as well as the Registry and data by selecting the option to back up System State data (Figure 1).

After choosing to back up the System State, you can select the media to which you want to back up. You can choose a disk file or tape. The Win2K Registry backup utility backs up all of the hives of interest in %systemroot%\system32\config, including Default, Software, System, SAM, and Security. However, it also backs up system files, user profiles, and any part of your system required to do a complete system restoration. This can potentially mean a lot of data — depending upon how large the user profiles and Registry hive files are that are stored on your machine — so be prepared to get the “baby with the bath water.” To perform selected backup of Registry hive files only, use a tool from the Resource Kit, such as Regback, which I review in a later section of this chapter.

To restore Registry hives that have been backed up with Win2K Backup, you can use the same wizard process, or you can manually select System State for restoral. Unfortunately, there is no way to separate the Registry from other System State elements. If you need to back up and restore individual hive files, you’re probably better off using one of the methods I describe later in this chapter.

Note that after the System State restoration process is completed, you need to shut down and restart the system. You won’t see the results of the restoration immediately.

Regback and Regrest
You might want to back up and restore individual hive files, but not deal with the overhead associated with running the Win2K Backup utility (i.e., all of the additional files that come with System State backup). For those situations, the Resource Kit again provides the answer — with the complementary utilities Regback and Regrest. You can use these two utilities to back up and restore Registry hive files from and to a live Win2K system. In fact, they work only on hive files that you otherwise cannot copy off while the system is up and running.

For example, if I were to try and perform a simple file copy of %systemroot%\system32 \config\Software to some other folder, it would fail with a message that another process was using the file. This is true of all five of the hive files kept in the config folder, as well as of any ntuser.dat file for a currently logged-on user. As a result, you need a tool like Regback to back up a hive while the system is up and running. In fact, Regback doesn’t work on an inactive hive file.

To use both Regback and Regrest successfully, you must have the user right that lets you back up and restore system files. This right is usually associated with the Backup Operators Local Group in a domain or on a member server/workstation.

Regback’s syntax is simple. For example, the following Regback command lets you back up the software hive file:

regback d:\backup\swsav machine software

In this example, I back up the software hive file to a file called d:\backup\swsav. Note that I must indicate the keyword machine before I tell Regback which hive file to back up. To back up Software, System, SAM, or Security, I must use the “machine” keyword. If I want to back up a default or a currently loaded user’s profile, I use the “users” keyword, as follows:

regback d:\backup\currusersav users S-1-5-21-1611495214-1983661468-569397357-1212

where S-1* represents the currently loaded user’s SID.

You can also use Regback to back up all five of the hive files to a directory without having to specify each individual file. Just type regback c:\backup, where c:\backup is a valid directory name. However, using this approach will not back up the current user’s ntuser.dat file or the user-specific classes portion of the Registry. You will have to explicitly back up these files with Regback. When you use Regback without options to back up all hives, these two files — ntuser.dat and usrclass.dat — are not included. You need to back them up individually following the example I gave for using Regback to back up HKEY_CURRENT_USER.

To restore hive files Regback has backed up, use the Regrest utility. Regrest actually moves files you backed up using Regback back into place in %systemroot%\system32\config and renames the old files as you specify. As with the Win2K Backup utility, you must reboot your system for the newly restored hive to actually be loaded. You can use Regrest to restore a hive file as follows:

regrest d:\backup\swsav d:\backup\sw.old machine software

I first specified the name of the backed up hive to restore (in this case d:\backup\swsav) and then provided the name of a file to which to back up the current Software hive (d:\backup\sw.old). Next, I specified to Regrest that this was a machine hive (rather than users). Finally, I specified the name of the target hive (software).

Registry Backup Best Practices
It is always a good idea to keep current backups of your hive files. If you have a backup utility like Win2K Backup or a third-party tool, make sure that you test backing up and restoring hives to ensure the utilities work as expected. If you choose to use Regback and Regrest, you can script a scheduled backup of selected hives using Win2K’s built-in Task Scheduler. Note that, in most cases, after you restore an individual hive file you need to restart your system to load the new hive properly.

Tip: Regback has one quirk you should know about. If you have already backed up a hive to a file, you need to either delete that file the next time you run the backup or rename the new backup. Regback can’t write a backup file over an existing file of the same name.

REGISTRY SECURITY

In “How the Registry Is Architected,” I discussed the permissions and security features available in the Win2K Registry. And in “Viewing and Manipulating the Registry,” I talked about using Regini from the Resource Kit and the third-party tool, RegAdmin, to manage Registry security. However, in Win2K there is a new way to manage Registry security centrally on many distributed systems — through the use of Group Policies and the Security Configuration Manager.

Group Policies give you the ability to define centrally managed security templates, which can then be distributed to all of your Win2K systems and enforced periodically. This makes GPO-based Registry security management ideal for larger environments. If you need to change Registry security on a few machines within your environment, then tools such as Regini are still the best choice.

Using Group Policy and Security Templates to Secure the Registry
To set and maintain centralized Win2K Registry security, you use two tools. First, you use the Security Templates MMC snap-in to create a template for a security configuration. Next, you use Group Policies in the AD to distribute and process those templates on remote machines. Group Policies are powerful objects in the AD for managing many aspects of both users and computers in Win2K. In this section, we look at just one part of that functionality — the ability to create, distribute, and enforce Registry permissions on a wide scale.

The first step in creating a distributed Registry security configuration is to use the Security Templates snap-in to create or edit a template.

Note: Related to the Security Templates snap-in is the Security Configuration and analysis snap-in, which lets you analyze security on a given system against a security template that you have defined, and then apply those template settings to the local system.

To start the Security Templates snap-in, type mmc.exe from the Start Menu, Run dialog box. Choose Console, Add/Remove Snap-In, and Add. Finally, choose the Security Templates snap-in. If you expand the Security Templates snap-in, you see a number of security configuration templates that Win2K provides out of the box. With names like basicdc, basicsv and securews, these templates are baseline security settings for various system configurations. For example, basicdc indicates a basic Domain Controller configuration. You can create custom .inf templates to match a specific security setting for your organization. For example, I can create a custom Registry template by right clicking on the D:\winnt\security\templates object within the Security Templates snap-in and selecting New Template.

By default, Security Templates snap-in templates on a Win2K system are stored in the %systemroot %\security\templates folder. Figure 2 shows the default templates in the Security Templates snap-in.

The templates are text files that can be created manually using a text editor or through the Security Templates snap-in. If you expand one of the templates, you see a number of different areas of security that you can configure, including account policy, event log settings, system services, file system, and Registry. For the purposes of this chapter, I focus on the Registry security settings within a template. If you expand the Registry node within a particular template, you see a number of Registry keys listed, as well as a permission and audit column (Figure 3).

This indicates a set of keys that have been configured for security within this template. You can add additional keys to enforce security by right clicking the Registry node within the current working template and selecting Add Key. You must choose an existing key on the system where you are configuring the template, so if you need to distribute security for a specific key, it must exist on that machine. Once you choose the key to include, you are prompted to select the security mode — Inherit, Replace, or Ignore.

The Inherit flag tells the template to set the security on this key and use the Win2K inheritance model to propagate the security changes to all subkeys within this key. The Replace flag tells the template to do just that — set security on this key and any of its subkeys, replacing any explicit security that an administrator may have defined on a subkey. Explicit security is when you define ACLs on a subkey in addition to what that subkey has inherited from its parent. Finally, the Ignore flag means you want to exclude this key from any security configuration or analysis.

Page: 1, 2

ADS BY GOOGLE