9.3 Limiting Remote Registry Access

In Windows NT 3.51 and earlier, any user could access the Registry on any machine over the network. From a security standpoint, this was much too liberal; NT 4.0 (and 3.51 with SP4 or SP5) defaults to allowing only members of the Administrators group to access the Registry remotely. This is considerably more secure than the original permissions.

However, this setting may not suit your environment. Sometimes allowing any member of the Administrators group access is still too permissive, since some high-value machines may warrant the added security of allowing only a single account or group to access their registries over the network. Conversely, you may want to proactively allow other users and groups to remotely connect to, and edit, Registry data on some machines.

9.3.1 Turning Off Remote Access Entirely

Windows 2000 introduces a new system service (the Remote Registry Service) that actually handles remote requests for Registry access. If you turn this service off, no incoming requests are accepted, period. By default, the service is started automatically at boot time, but if you disable it using the Computer Management snap-in (or stop it manually), no one can connect remotely and flip through your Registry.

9.3.2 Limiting Access to Authorized Users

In Windows 2000 and NT 4.0 , you can control which users, groups, and services may access the Registry on a particular machine by setting the ACL for a single Registry key, namely HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg. The kernel grants remote access to a machine's Registry only to those entities named in the ACL attached to the key.

Before proceeding, I should point out that this restriction key controls access to the Registry as a whole. You may still enforce more stringent controls on individual keys. For example, you can grant one group of users access to the Registry by setting the restriction key permissions accordingly, but if you put access controls on other keys those users can see, the most restrictive set of controls wins out.

9.3.2.1 Creating the restriction key

Before you can take advantage of this feature, the restriction key must exist on your computer. By default, Windows 2000 Server and Advanced Server (as well as NT Server 4.0) include this key, and administrators have Full Control access to it. If you don't have the key present, and you want to restrict access, you have to manually add the restriction key to your Registry. Here's what to do if you don't already have this key available:

Depending on your machine, you may find that you have some parts of the restriction key; for example, NT Workstation 4.0 with no service packs has the HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers key itself, but it doesn't have the winreg subkey that's needed to actually make the restrictions work.

9.3.2.2 Setting permissions on the restriction key

Once you've verified that the winreg key exists, you can use the SecurityPermissions... command to give it an ACL. The permissions applied to this key govern which users and groups can access your Registry via the network.

The Registry Key Permissions dialog (shown in Figure 9.2) allows you to change the users and groups that can access the key, as well as modify permissions for those users and groups that you choose to allow access. (If you need a refresher, see Chapter 5.)

Figure 9.2. Setting Registry key permissions

Windows 2000 and NT 4.0 installations by default have permissions like those shown in Figure 9.2: the Administrators or Domain Admins group have Full Control rights, as will the system and the account that created the key. You can add new users and groups to this list and give them permissions commensurate with what you want them to do; for example, you might grant read-only access to all domain users while restricting Full Control access to a single named account. Change whatever else you want, but leave the system and CREATOR OWNER permissions alone; the kernel and Registry subsystem depend on these permissions to gain access to the key themselves.

Some system services, such as the directory replicator and the print spooler, require remote access to the Registry. If you change the access control entries on the winreg key, these services may stop working. To avoid this problem, make sure the local accounts that run the replication service and the print spooler have explicit permissions in the ACL for the winreg key.

9.3.2.3 Allowing exceptions

You may also choose to loosen the leash on your Registry a bit by allowing exceptions to the access control rules specified by the permissions on the winreg key. These exceptions can be expressed in two ways: you can provide a list of keys that are exempt from the access controls, or you may specify a list of users who have free access to specific keys and their values.

Both methods are governed by values you add beneath HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg\AllowedPaths.

• The Machine value, of type REG_MULTI_SZ, accepts a list of Registry paths. Any path listed here is visible to any machine on the network. By default, this key contains a set of paths that enable the replicator, print spooler, event logger, and kernel to function properly: System\CurrentControlSet\Control\ProductOptions and Software\Microsoft\Windows NT\CurrentVersion for the kernel, System\CurrentControlSet\Control\Print\Printers for the print spooler, System\CurrentControlSet\Services\Eventlog for the event logging service, and System\CurrentControlSet\Services\Replicator for the directory replicator. Windows 2000 machines also have a set of keys for Terminal Server (System\CurrentControlSet\Control\TerminalServer, TerminalServer\UserConfig, and TerminalServer\DefaultUserConfig) and content indexing (System\CurrentControlSet\Control\ContentIndex).

• The Users value (also a REG_MULTI_SZ) lists Registry paths that will be made available to any member of the Users or Domain Users group. This key is empty by default, and you should probably keep it that way unless you have a compelling reason to exempt individual users from the restriction key-imposed controls. In general, if you have a user who needs unusual access, it's better to put the user account into a group and assign the group a permission entry on the restriction key.

Access granted via either of these methods is still subordinate to permissions you've applied directly to individual keys. For example, if you use the SecurityPermissions... command to apply Everyone:Read access to HKLM\Software\Netscape\Netscape Navigator, then add that same path to the Machine value, remote users won't be able to change the values under that subtree: the explicit ACL you've added overrides whatever access was granted by the Machine entry.