1.3 Advantages Offered by the Registry

The Registry offers a number of significant benefits to programmers, users, and administrators. These benefits stem from the characteristics just described.

1.3.1 It Keeps Everything Tidy

Instead of the dozens (or even hundreds) of separate INI files typically found on a Windows 3.1 machine, Windows NT/2000 machines usually only have a few, and those typically belong to 16-bit legacy applications that can't use the Registry. Windows 2000 itself uses the Registry for its configuration data, as do almost all 32-bit applications written for Windows 9x and NT/2000. There's more to tidiness than just the reduction in clutter that comes from eliminating INI files, though. Centralizing where configuration information is stored makes it easier for administrators to back up, restore, and secure the data.

1.3.2 It Provides Security

Access control for the Registry comes in two sizes. First, you can set individual workstations or servers to disallow any remote Registry connections. While this is secure, it also makes it impossible to use the System Policy Editor to set and inspect policies on that machine. A better and more fine-grained solution is to use the built-in ACL features. As I mentioned earlier, each Registry key, from the root keys on down, can have its own set of access permissions in the form of ACLs that apply to the keys.

Each access control entry (ACE) in an ACL actually has two parts: a permission (as shown in Table 1.1) and the account or group name that holds the permission. You'll learn more about these permissions in Chapter 5. ACL permissions are usually written like this, with the holder first and the permission following:

Everyone:Read
paul:Full Control
Engineering:Full Control

Table 1.1. Registry Access Permissions

Permission	What It Allows
Read	Read-only access to a specific key, its subkeys, and their values (includes Query Value and Enumerate Subkeys)
Full Control	All of the above rights; Full Control allows the holder to do literally anything to the keys with that permission
Query Value	Getting the data or contents of a specific key's value
Set Value	Changing the value of a specific key
Create Subkey	Creating a new subkey under the key that holds this permission; the new subkey inherits the parent's permissions unless they're explicitly changed
Enumerate Subkeys	Traversing all subkeys of a specific key and getting their full pathnames
Notify	Getting or setting auditing notifications
Create Link	Creating a symbolic link (such as a shortcut or a Unix symlink) that points to another key in the Registry
Delete	Removing the specified key, its subkeys, and all associated values
Write DAC	Changing the Discretionary Access Control (DAC), or permissions, on the specified key
Write Owner	Changing the owner associated with the specified key
Read Control	Reading the ACL for the key

Any account or group that is listed in the ACL has the matching permission; any group or account that's not in the ACL can't getaccess. This gives precise control over Registry access, since anyone you don't explicitly include in an ACL can't get access.

In addition to whatever accounts you've defined on your workstation or domain, you can use the operating system's built-in accounts and groups. In particular, you'll see the Authenticated Users pseudo-account^[5] that grants read access to most keys in the Registry, while the Administrators groups usually have Full Control access to all keys. Since many NT software installers require write access to the HKEY_LOCAL_MACHINE\Software and HKEY_CURRENT_USER\SOFTWARE subkeys, you'll often see them tagged with Everyone:Full Control. Applications that use the Windows Installer--which includes any application written exclusively for Windows 2000--are smart enough not to require this access, but many administrators will want or need to run software designed for NT on their Windows 2000 machines.

^[5] Authenticated Users isn't really an account; it's a special token that matches any authenticated user. NT 4.0 SP3 introduced Authenticated Users, which is similar to the older (and deprecated) "Everyone" pseudo-account.

It's also worth mentioning the SYSTEM account name; SYSTEM refers to processes and services owned by the kernel, so it's usually used to grant Full Control access to many of the keys in HKEY_LOCAL_MACHINE.

Besides their access controls, Registry keys also have owners; for example, the Administrators group owns the HKEY_LOCAL_MACHINE\HARDWARE subkey. You can restrict access to parts of the Registry by changing their ownership to a single account to which you control access; since any account that's not in an ACL won't have any access, everyone except the owner is locked out.

As an additional security feature, NT allows you to create an audit trail of access to, and operations on, the Registry. When you enable auditing for a key, you specify two things:

What actions you want audited

You can create an audit trail of the success or failure (or both) of all of the permissions in Table 1.1 except Read, Full Control, and Write Owner.

Which accounts are audited

The accounts you specify will generate audit trail entries when they attempt one of the actions you specify.

The auditing data is written to the Windows 2000 event log, where you can view it with the Event Viewer MMC snap-in or parse it with programs or scripts you've written.

1.3.3 It Allows Remote Management

Every computer running Windows 2000 has a Registry. If you're supporting more than one of these machines on a network, you'll be happy to know that the Registry supports network inspection and modification. This capability, which is built into RegEdit and RegEdt32, allows you to troubleshoot and fix some types of Registry problems on network machines from your desktop. In addition, network Registry access makes it possible to automatically inspect the Registry of every machine on your network--a valuable way to gather statistical ("how many of our machines are still running Netscape Navigator 2.x?") or configuration ("what machines have impala.oreilly.com as one of their DNS servers?") data.

The old-style system policy mechanism requires network access to the Registry; there are also a number of useful administrative tools and utilities that build on network Registry access. For example, the ERDisk product from Aelita (http://www.aelita.net) allows you to build an emergency repair disk (ERD) for a machine across the network; in fact, you can automatically build updated ERDs for all the machines on your network every night if you like. Microsoft's System Management Server (SMS) product makes heavy use of network Registry access.