You would set the Ignore flag when you don’t want to replace a subkey whose parent key has been defined as such. For example, suppose I create a Registry security template that sets the HKEY_LOCAL_MACHINE\System key to Everyone:READ ONLY. I choose the Replace option, which propagates this ACL to all subkeys under System and removes any other ACLs that may be present there. Now suppose I want to keep the current ACLs in place on the CurrentControlSet key under System. I could use the Ignore flag on this subkey to ensure that the Replace flag does not impact security.
Once you modify an existing security template or create a new one that contains the Registry security settings you need, you can then distribute it to other machines. If you already use Group Policy Objects (GPOs) and the AD, then you can use them to distribute your security settings. If not, you can manually copy the .inf template file you create to a set of target machines and initiate a security configuration on them manually using the secedit command.
Explaining the details of how to design and deploy your GPOs would require a book. However, below I specifically discuss how to use GPOs (and manual tools) to distribute Security Templates snap-in templates to your workstations to modify Registry permissions.
Using GPOs to Distribute Security Template Configurations
If you already have a GPO defined for a given Domain, Site, or organizational unit (OU), it is easy to incorporate your security template .inf file into it. To load a particular template file, bring up the GPE MMC tool and drill down into Computer Configuration, Windows Settings, Security Settings. Right-click the Security Settings item and select Import Policy. From there, you can select a template .inf to use for this GPO.
Once this template file is part of the GPO, the AD distributes the GPO to all users and machines that are subject to it. Machine-specific GPOs, such as those for Registry security, are delivered once when a system restarts and periodically thereafter while the system is running, depending upon how you set the frequency. (Frequency can be controlled via an Administrative Templates policy.)
As an example of how this works, I present a configuration template in the Security Templates snap-in called “custom registry.inf.” Basically, all this template does is set Replace security on the key HKLM\Software\Myapp. Within my AD is a GPO called “OU Security” that I create on an OU called “Finance.” I bring up the GPE, focused on the OU Security GPO for the Finance OU, and then import the “custom registry.inf” template into the GPO. Figure 4 shows the GPE loaded with my custom Registry template.
Once my template is loaded, I can either modify it within the GPO or simply leave it as is. When the GPO is processed by a machine, the Registry security I specified is enforced.
I can also choose to manually process a security configuration template on a workstation or server. In cases in which I don’t use GPOs (e.g., on downlevel clients running NT 4.0 or Win2K workstations or servers that aren’t part of my AD domain), there is a mechanism for manually executing a security configuration. All Win2K workstations and servers (and NT 4.0 devices running Service Pack 4 and greater with the Security Configuration engine installed) come with a command-line utility called Secedit. Secedit’s sole job is to automate from the command-line what the Security Configuration Manager and GPOs do through a GUI interface. With Secedit, you can perform a security analysis against a system, configure a system according to a security configuration template, generate a template from the currents system’s security configuration database (the security database kept on each Win2K system tracks which security templates are currently available for that system), refresh the current policies, and validate that a given template is syntactically correct.
For discussion, I review the configuration and refresh the two options relevant to managing Registry security. Let’s go back to my previous example in which I created the template called “custom registry.inf.” The first step to manually initiate a configuration on a device using Secedit is to copy my custom template file to a place where the workstation or server can get to it. Once I do that, I issue the following command:
When I issue this command my “custom registry.inf” file is imported into the workstation’s or server’s local security database (secedit.sdb by default). The /cfg option informs Secedit that it is to import my .inf file into the default database, appending it to any existing .inf files that have already been imported to this device. If I choose the /overwrite option, my custom .inf file overwrites all other previous configurations for this machine. The /areas option lets me specify which areas within a security configuration template I want to process. If I don’t specify this option, all areas are processed if they are contained in the template. Because my custom template only contains Registry security, I choose to process only this area (using the “regkeys” keyword). Once I issue this command, my custom template is imported into the database and then applied to the workstation or server.
If at some point in the future I wish to trigger a re-application of the contents of my current security configuration database, I can use the /refreshpolicy option of Secedit as follows:
Secedit /refreshpolicy machine_policy
Because Registry security settings are machine-specific, this command tells Secedit to process the machine-specific policies only. To periodically reinforce your security policy, you can issue Secedit commands remotely or through a scripting process. If you aren’t using GPOs to distribute security policy, you can use the Win2K Task Scheduler and the secedit.exe command-line utility to perform periodic updates of security policy.
MANIPULATING HIVES AND KEYS
In “How the Registry Is Architected,” I talked about the fact that the four main subkeys under HKEY_LOCAL_MACHINE (SAM, Security, Software, and System) and the one key, Default, under HKEY_USERS, are really just “hive” files that the Registry has loaded. I also mentioned that the file ntuser.dat, located within a user’s profile, is the hive file for HKEY_CURRENT_USER. A particular Win2K installation uses these hive files to form the current Registry subkeys for that installation. As such, when that Win2K installation is loaded and running, these files are open by the OS and can’t be accessed or deleted.
Loading and Unloading Hives
However, there are circumstances when you may want to view the contents of a hive file outside its normal state of being loaded by an active system. A perfect example of this is a user’s profile — ntuser.dat. You may want to look at the contents of HKEY_CURRENT_USER for a user who is not currently logged onto a Win2K workstation or server. Under these circumstances, HKEY_CURRENT_USER for that user is normally unavailable. However, it is possible to load a hive file like ntuser.dat into a temporary Registry key, where it can be viewed or manipulated and then later unloaded. There are two readily available tools to perform this kind of operation — Regedt32 for interactive use, and Reg from the Resource Kit for loading and unloading hives in a scripted fashion.
When you use Regedt32 to load and unload hives, there are specific steps to take and a number of things to keep in mind. Before you load a hive using Regedt32, be aware that a hive file can only be loaded from the root of one of the static (i.e., non-aliased) subtrees. What this means is that if you try and perform a load hive operation from, for example, HKEY_CLASSES_ROOT, you notice that the option is unavailable from Regedt32’s menu. This is expected because HKCR is really just an alias to HKLM\Software\Classes. The same behavior occurs if you try to load a hive into another hive, such as HKLM\System or HKLM\Software. In fact, there are only two places you can load a temporary hive — either into the root of HKLM or into the root of HKU. These are the only two subtrees that are not aliases and are used to load the other hive files like SAM, Security, System, Software, and Default.
Now that we know where we can load a temporary hive, let’s look at how to do it. First, highlight the root of either HKLM or HKU. Then, from Regedt32’s main menu, select Registry, Load Hive. You get the familiar open file dialog box. From here, you select a hive file that you wish to load. For example, if you want to load someone’s user profile (ntuser.dat), you might point to a directory in the %userprofile% folder on a local or remote Win2K workstation. After you select the hive to load, you must give it a temporary key name. You can pick any name except one that duplicates an existing key within that subtree. Figure 5 shows an example of this operation.
Figure 5 shows an ntuser.dat hive file from a user’s profile loaded into a temporary key called “temphive.” As you can see, the subkeys under temphive contain all the normal items you would see in HKEY_CURRENT_USER. If you examine security settings on this temporary hive, you see that they correspond to those belonging to the user account or security group that is permitted to use this profile.
Using our example of the temphive key, suppose you were to use Regedt32 to modify keys, subkeys, values, or even Registry security within this temporary key? What would happen to the original hive file? In fact, any changes you make to the temporary key are really being made to the original hive file. As soon as you make a change, that change is committed to the hive file. When you unload the temporary key (as I describe shortly), the original hive file (in this example, ntuser.dat) now contains any and all changes you made while it was loaded as a temporary key. This is an important point because there is generally neither backout nor confirmation when you make changes this way.
Once you complete use of the temporary key, it is important to remember to unload the hive file. Failure to do so can cause a lot of problems. For example, if you leave users’ profiles hive loaded and the users try subsequently to log in to their workstations, they are unable to load ntuser.dat into HKEY_CURRENT_USER because you have it loaded elsewhere. To unload a hive file, simply highlight the key that you loaded in the first step (e.g., temphive) and, from Regedt32’s menu, choose, Registry, Unload Hive.
As I mentioned earlier in the chapter, you can also use Reg from the Resource Kit to load and unload hive files via a command line. For example, suppose I have a user’s profile called ntuser.dat under c:\documents and settings\Jsmith that I want to load into a temporary key called jsmithtemp. Using Reg, I could do so using the following command:
Reg Load HKU\jsmithtemp "c:\documents and settings\jsmith\ntuser.dat"
The advantage of using Reg to perform the load operation is that I can use it as part of a scripted solution. For example, in the following listing, I use the previous Reg load statement as part of a scripted batch solution to change jsmith’s screensaver timeout:
In the listing, I start off by loading the user profile into a temporary key. Next, I make a change to the screensavetimeout value using Reg add. Finally, I unload the hive file from the temporary key. You can, of course, load any valid hive file into the Registry temporarily. This includes the software, system, SAM, and security hives from another Win2K system. The Win2K policy file from NT 4.0 (usually called ntconfig.pol) is also a valid hive file that you could load and examine in the Registry. However, beginning with Win2K Group Policies, the equivalent of the ntconfig.pol file — now called registry.pol — is no longer a hive file. It is a noneditable text file that holds the desired Registry settings.
Saving and Restoring Keys
When I talk about saving and restoring Registry keys, this is different from backing up and restoring hive files, as discussed earlier in the chapter. Specifically, you can save individual keys within a hive and restore them over the top of an active Registry at a later date. Where this might come in handy is when you need to test a change to a set of keys or values, but you want to be able to back out the change easily, without having to restore the entire hive file. To save and restore keys, you can use the same tools that you use to load and unload hives — Regedt32 and Reg from the Resource Kit.
To use Regedt32 to save a key to a file, you highlight the key you want to save, select Registry, Save Key from Regedt32’s menu, and choose a file name for the key to be saved. Note that when you save a key, all subkeys and values beneath that key are also saved. The file you create with the Save Key function is a binary, not a text, file.
Restoring a saved key is a bit trickier. Let’s use an example to illustrate the process. Suppose I have a key called MyApp under HKEY_LOCAL_MACHINE\Software. Myapp contains a number of subkeys and values. I use the Save Key feature in Regedt32 to save Myapp to a file called myapp.sav. Then, to conduct a test, I delete the key Myapp and all its subkeys and values.
Now, I want to restore the Myapp key under HKLM\Software, but the Myapp key no longer exists. Instinctively, you would highlight the Software key and select Restore from the Regedt32 menu. However, this attempts to overwrite the Software key and all of its subkeys with the contents of Myapp. That would be disastrous.
Instead, you must begin by manually recreating the Myapp key under HKLM\Software. First, highlight the Software key. Then, from Regedt32’s menu, select Edit, Add Key. Enter Myapp in the dialog box and leave the Class field blank. Now that you have created the Myapp key, you can restore the old keys, subkeys, and values on top of it.
Highlight Myapp, and from Regedt32’s main menu, select Registry, Restore and select the file you created in the save step above. The saved file overwrites the newly created Myapp key with all of the previous subkeys and values. Any security settings that you had on the saved keys are also restored.
I already discussed Reg’s ability to save keys using the reg save option. This is the same capability as when we perform a save action from Regedt32. You can use the two tools interchangeably: Regedt32 can restore keys that you save to files using Reg and vice versa.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
