How the Registry Is Architected

Windows IT Pro

- Advertise

How the Registry Is Architected

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

Note: You may also see REG_DWORD represented as REG_DWORD_LITTLE_ ENDIAN or REG_DWORD_BIG_ENDIAN. These are still four-byte values, but the ENDIAN designator indicates how the value is stored in memory. LITTLE_ENDIAN values are stored from low-order byte to high-order byte (the default for REG_DWORD values), and BIG_ENDIAN values are stored from high-order to low-order. Normally, you aren’t exposed to this issue unless you’re programming against the Registry.

The hardest data type to manipulate manually is the REG_BINARY type. These values hold binary data that does not correspond to simple configuration options. For example, options with respect to how a user’s Microsoft Outlook profile is configured are kept within REG_BINARY values in HKEY_CURRENT_USER. The normal method for modifying these configuration options is through the Outlook client configuration menus. Therefore, attempts to change these values directly through one of the available Registry editors can often result in corrupt data.

REGISTRY HIVES — THE FILES BEHIND THE REGISTRY

As I mentioned previously, the Registry is a kind of database. Every database has physical files stored on disk that hold the data you view. The Registry is no exception. The Registry comprises a set of files — called hives — that are stored on the hard drive of your Win2K system. Specifically, Registry hives are stored in %systemroot%\system32\config. Win2K loads hive files at system start, and they become the Registry keys we discussed. The hives that are stored here, on the hard drive of your Win2K system, correspond to actual keys within the Registry subtrees. Table 2 shows how each hive file stored in the config directory corresponds to the actual subtree key.

As you can see, almost all of the Registry subtrees discussed are captured in these five hive files. The missing piece is HKEY_CURRENT_USER, whose hive file is kept elsewhere. Because HKCU is really the user’s profile, it makes sense that the hive file for this subtree be kept with the user’s profile, and indeed it is. The hive for HKCU is the file ntuser.dat within the %systemdrive% \documents and settings\<username> folder.

Note: Win2K now uses the Documents and Settings folder from the root system drive (i.e., C:) to store user profiles. This keeps user data out of the system folder, data that made it hard to secure this folder properly. Note, however, that if you upgrade an NT 4.0 system to Win2K, profiles are left under %systemroot%\profiles to prevent problems with hard-coded paths to this location that may be stored in HKCU and HKLM.

Within the %systemroot%\system32\config folder, you see a number of other files related to the Registry and a number which are not. For example, each of the five Registry hives has a corresponding .log file. This log file is really a transaction record of changes made to the Registry since the system has been up. Changes to the Registry are actually written to the log files first, rather than to the actual hive files. Only when the log changes have been written to the hive is the log reset. If a system failure occurs during a write to a hive, the log changes are applied to the hive to bring it up to date at the subsequent boot.

Warning: You can’t manipulate the log files manually to perform a rollback.

In addition to the log files, you also see the five Registry hive files shown in Table 2 with a .sav extension — specifically SAM.sav, Security.sav, Software.sav, System.sav, and Default.sav. These files are created when you install Win2K on a system. They represent the pristine, never-modified hive files for each of those keys.

You also see the three files (or more if the Win2K device is an AD domain controller or DNS server) that hold Win2K event log information — each has an .evt extension. They are not Registry hive files and are used exclusively by the event logs to store log information. One last file you see is related to Win2K recovery. The System.alt file is a duplicate copy of the system hive file. When Win2K begins to boot up, if it is unable to load the normal System hive file, it uses System.alt as a backup.

REGISTRY SECURITY

One of Win2K’s major selling points over the Win 9x product line is its security capability. Security has been incorporated into the OS kernel, to the extent that all resources, whether files or processes, can be secured. The Registry is no exception. Stored within the hive files that make up the Registry are permissions related to who has access to a given key and what access they have.

Permissions
Just as with the Win2K file system (NTFS), each Registry key and subkey has an Access Control List (ACL) associated with it. Each ACL comprises any number of Access Control Entries (ACEs).

Note: Permissions are assigned only to Registry keys. They don’t extend to the Registry values themselves. Instead, the rights defined on the key determine whether a given user or group has the ability to view and modify the values contained therein.

An individual ACE describes the user or group that has been granted access as well as the kind of access allowed. For example, Figure 10 shows the ACL for the key HKLM\Software\Microsoft.

As you can see, there are four ACEs for this particular ACL, with all but the Everyone group having Full Control over the key. The Everyone group has the "Special Access" right over this key. There are three predetermined types of access that you can choose from this dialog box — Read, Full Control, and Special Access. Each of the three provides a different level of control and offers different rights to a given Registry key. In Win2K, there are ten different rights that you can grant to a user or group with respect to Registry keys (Table 3).

Because access to certain keys within the Registry constitutes a privileged operation (e.g., access to SAM, Security, machine policy, user policy), you find that a default Win2K installation attempts to secure these critical keys to prevent a normal user account from changing and sometimes even from reading them.

You probably won’t have occasion to modify Registry permissions frequently, unless you need to take advantage of certain Win2K security features that aren’t enabled by default. However, the Security options available within the Win2K Security Configuration Manager tool (and distributable via AD Group Policy Objects (GPOs)) provide a mechanism for centrally defining templates that can enforce specific ACLs on specific Registry keys across many machines.

Auditing
In addition to being able to specify permissions on Registry keys, you can audit different types of access to the Registry. This audit is similar to the auditing function within NTFS. Figure 11 shows an example of the kinds of auditing you can do on a given key, which correspond to the permissions you can grant on keys.

In this case, I define auditing on a set of events on the HKLM\System key and all of its subkeys. When you define auditing on the Registry, just as with the file system, you have to specify the user or group whose access you wish to audit. In Figure 12, I specify auditing the group Authenticated Users. Any users who meet the criteria I specify in the check boxes trigger an audit event.

You can, of course, audit individual users or groups. Audit events on Registry access are stored in the Security event log. This is an important point, because auditing tasks like Registry access can generate a huge number of event log events. If you use the option to modify settings on your event logs and you limit their physical disk size, they can fill up easily. The wider your scope of auditing, both with respect to the number of keys you audit and the number of users whose access you monitor, the more data you capture. Use auditing judiciously. Audit for failures rather than successes, if that provides the data you need. This way, only exceptions are logged, rather than any access to a particular key. It can quickly become meaningless if you audit too much.

Note: Before you turn auditing on within the Registry, you must enable the auditing function on the machine or domain controller that you want to monitor. If you audit Registry access on a workstation or member server, you can enable auditing via the local GPO. If you audit Registry access on domain controllers, you can either define a local Group Policy for each domain controller, server, or workstation, or define a Group Policy for the domain, site, or organizational unit (OU) in the AD, where your devices reside. You can access this option via the Microsoft Management Console (MMC) snap-in for Group Policies. To access a local GPO per machine, type gpedit.msc from the Start Menu, Run dialog while logged onto the console of the machine. To access the audit policy, go to the computer configuration node, then drill down to Windows Settings, Security Settings Local Policy, Audit Policy. If you enable the "Object Access" policy (Figure 13), for both success and failure, this is sufficient to enable auditing within the Registry.

Ownership
Ownership is another aspect of Registry key security that you can set. Being an owner of a key, just as being an owner of a file, lets you change the security settings — either permissions or auditing — for that key. The ability to take ownership of a Registry key is not automatic. If you have the Write Owner permission on the given key, then you can take ownership of it. Figure 14 shows the dialog box you can use in Regedt32 to take ownership of a Registry key.

Tip: The Write Owner access right can obviously be dangerous from a security perspective, and it should be given out judiciously. In general, a default Win2K installation does not grant this right to normal users for most system-related Registry keys. There is also a user right defined within Win2K security to "Take Ownership" of a resource. This right is granted by default to local Administrators group on Win2K Professional or Server.

Warning: If users have the user right defined within Win2K user rights security to "Take Ownership" of a resource, they can take ownership of a Registry key even if they are not explicitly granted the Write Owner right on that key

REGISTRY MEMORY USAGE

Just as understanding the basic structure of the Registry is an important aspect of successful Registry troubleshooting, understanding how the Registry uses system resources can make your Registry troubleshooting more effective.

Like other system data structures, the Registry is loaded into physical memory when Win2K starts up. Some elements of Win2K’s system components may not be paged out of physical memory. The Registry, however, can be sent out to a page file if physical memory becomes scarce. The Registry resides in an area of "system" memory called the paged pool. The paged pool is allocated at system startup, based on the amount of physical memory installed on the system. The amount of memory allocated to the Registry is called the "Registry quota."

To verify that the Registry uses paged pool memory, we can perform an easy test using the System Performance Monitor tool. The System Performance Monitor tool is a Microsoft Management Console snap-in that provides basically the same functionality as NT 4.0’s Performance Monitor (PerfMon) tool. In Figure 15, you see that I have loaded PerfMon and am logging the Memory->Pool Paged Resident Bytes counter, which tells me how many bytes within the paged pool are in use.

As you can see, there is an increase in the amount of used paged pool about halfway through the graph. A short time later, it returns to its original value. I created this reaction by temporarily loading a hive file (specifically another user’s ntuser.dat profile) into the Registry on this machine. (I describe the load and unload functions in "Viewing and Manipulating the Registry.") This load operation caused the amount of paged pool the Registry uses to increase by roughly the size of the ntuser.dat file. A short time later, I unloaded the temporary hive, and the memory usage returned to its original value.

If you need to view or modify the current Registry quota on a machine, right-click My Computer, choose Properties, select the Advanced tab, choose Performance Options, and click Change within Virtual Memory. You find the Registry quota (which you can change), as well as the current size of the Registry in memory (Figure 16).

The important thing to remember about the Win2K Registry quota is that you are no longer storing the SAM within the Registry on domain controllers. This means that the page pool memory requirements for the Registry are much smaller than they were in NT 4.0. Nonetheless, in Win2K, Microsoft set the Registry Quota (also known as Registry Size Limit) at a higher percentage of Paged Pool than in NT 4.0. The Registry quota, which had been dynamically set at system boot time to 25 percent of the Paged Pool size, with Win2K, is set at 33 percent. This means that Registry Quota can grow to be a larger percentage of the available system paged pool than previously. You can still modify this value artificially, however, if you find that you need more Registry quota.

DIFFERENCES BETWEEN THE WINDOWS NT 4.0 AND WIN2K REGISTRIES

To begin with, the Win2K Registry is very similar in structure to the Registry in previous versions of Windows NT. It still comprises hive files, which the OS loads at boot time. Although new features have been added within each subtree of the Win2K Registry, the subtrees themselves remain primarily the same.

One notable exception to this is the storage of the SAM database. In NT 4.0 and earlier versions, the SAM for a given NT domain running on an NT domain controller, was just another Registry hive. As I mentioned earlier in the chapter, in Win2K, the SAM for a domain is now part of the AD — a replicated database running on each domain controller based on the Microsoft JET technology. Win2K domain controllers actually emulate the SAM in order to down-level NT 4.0 and 3.5x domains.

Although the SAM has been reduced in function to performing a recovery role on Win2K domain controllers, you will recall that it still has a place as a Registry hive on Win2K Workstations and Member Servers, and still is used to store the local security database for these devices.

The other significant difference you find in the Win2K Registry is the use of user-specific classes. As I mentioned in the section on Registry subtrees, this new feature lets COM classes and application associations follow users as they work at different machines. This is new in Win2K, and it works hand-in-hand with the software installation features that are part of AD-based Group Policies and the Windows Installer Technology. In "The Registry and the Active Directory," I discuss how these new technologies interface with the Registry and use it to increase application and user portability.

SUMMARY

In this chapter, we have reviewed the structure and function of the Win2K Registry. The Registry comprises subtrees that contain keys, subkeys, and values. HKEY_LOCAL_MACHINE and HKEY_USERS are the only "real" subtrees. The other three subtrees — HKEY_CURRENT_CONFIG, HKEY_CURRENT_USER, and HKEY_CLASSES_ROOT — are all aliases to keys within the first two. Values can take many data types, including string, multistring, and numeric.

Hives are the actual files that back HKLM, HKU, and, in the case of user profiles, HKCU. Registry keys can have security associated with them just as the NT File System can, and you can modify the security through tools such as Regedt.

We considered how the Win2K Registry uses memory, allocating a certain percent (33 percent) from the paged pool to establish a Registry "quota." Finally, we examined some of the differences between the Win2K Registry and the Registry of previous versions of NT. Specifically, we saw that the SAM and Security hives formerly found in the NT 4.0 Domain Controllers have been replaced by the Win2K Active Directory database, which can emulate the SAM for downlevel devices. The last new element in the Win2K Registry is the use of user-specific Class storage that lets file associations and OLE/COM Class registrations roam with the user’s profile.

Page: 1, 2, 3

ADS BY GOOGLE