The Registry is a critical area of the operating system. It has some limited built-in security to reduce the risk of settings being inadvertently changed or deleted. Additionally, some areas of the Registry are available only to certain users. For example, HKLMSAM and HKLMSECURITY are available only to the LocalSystem user. This security in some cases might not be enough, however, to prevent unauthorized access to the Registry. Because of this, you might want to set tighter access controls than the default permissions, and you can do this from within the Registry. You can also control remote access to the Registry and configure access auditing.
One of the best ways to protect the Registry from unauthorized access is to make it so users can't access the Registry in the first place. For a server, this means tightly controlling physical security and allowing only administrators the right to log on locally. For other systems or when it isn't practical to prevent users from logging on locally to a server, you can configure the permissions on Regedit.exe and Reg.exe so that they are more secure. You could also remove Registry Editor and the REG command from a system, but this can introduce other problems and make managing the system more difficult, especially if you also prevent remote access to the Registry.
To modify permissions on Registry Editor, access the %SystemRoot% folder, right-click Regedit.exe, and then select Properties. In the Properties dialog box, select the Security tab, as shown in Figure 14-9. Add and remove users and groups as necessary, then set permissions as appropriate. Permissions work the same as with other types of files. You select an object and then allow or deny specific permissions. See Chapter 21, for details.
To modify permissions on the REG command, access the %SystemRoot%System32 folder, right-click Reg.exe, and then select Properties. In the Properties dialog box, select the Security tab. As Figure 14-10 shows, this command by default can be used by administrators, BATCH (scripts), INTERACTIVE (from the command line), SERVICE (LocalService user), and SYSTEM (LocalSystem user). Add and remove users and groups as necessary, then set permissions as appropriate.
Keys within the Registry have access permissions as well. Rather than editing these permissions directly, I recommend you use an appropriate security template as discussed in Chapter 38. Using the right security template locks down access to the Registry for you, and you won't have to worry about making inadvertent changes that will prevent systems from booting or applications from running.
That said, you might in some limited situations want to or have to change permissions on individual keys in the Registry. To do this, start Registry Editor and then navigate to the key you want to work with. When you find the key, right-click it, and select Permissions, or select the key, then choose Permissions on the Edit menu. This displays a Permissions For dialog box similar to the one shown in Figure 14-11. Permissions work the same as for files. You can add and remove users and groups as necessary. You can select an object and then allow or deny specific permissions.
Many permissions are inherited from higher-level keys and are unavailable. To edit these permissions, you must access the Advanced Security Settings dialog box by clicking the Advanced button. As Figure 14-12 shows, the Advanced Security Settings dialog box has four tabs:
Figure 14-12. Use the Advanced Security Settings dialog box to change the way permissions are inherited or set and to view auditing settings, ownership, and effective permissions
Permissions The Inherited From column in the Permissions tab shows from where the permissions are inherited. Usually, this is the root key for the key branch you are working with, such as CURRENT_USER. You can use the Add and Edit buttons in the Permissions tab to set access permissions for individual users and groups. Table 14-2 shows the individual permissions you can assign.
Table 14-2. Registry Permissions and Their Meanings
Permission
Meaning
Full Control
Allows user or group to perform any of the actions related to any other permission
Query Value
Allows querying the Registry for a subkey value
Set Value
Allows creating new values or modifying existing values below the specified key
Create Subkey
Allows creating a new subkey below the specified key
Enumerate Subkey
Allows getting a list of all subkeys of a particular key
Notify
Allows registering a callback function that is triggered when the select value changes
Create Link
Allows creating a link to a specified key
Delete
Allows deleting a key or value
Write DAC
Allows writing access controls on the specified key
Write Owner
Allows taking ownership of the specified key
Read Control
Allows reading the discretionary access control list (DACL) for the specified key
Auditing Allows you to configure auditing for the selected key. The actions you can audit are the same as the permissions listed in Table 14-2. See the section entitled "Registry Root Keys" earlier in this chapter.
Owner Shows the current owner of the selected key and allows you to reassign ownership. By default, only the selected key is affected, but if you want the change to apply to all subkeys of the currently selected key, choose Replace Owner On Subcontainers And Objects.
Effective Permissions Lets you see which permissions would be given to a particular user or group based on the current settings. This is helpful because permission changes you make in the Permissions tab aren't applied until you click OK or Apply.
Hackers and unauthorized users can attempt to access a system's Registry remotely just like you do. If you want to be sure they are kept out of the Registry, you can prevent remote Registry access. Remote access to a system's Registry is controlled by the Registry key HKLMSYSTEMCurrentControlSetControlSecurePipeServersWinreg. If you want to limit remote access to the Registry, you can start by changing the permissions on this key.
If this key exists, then the following occurs:
Windows Server 2003 uses the permissions on the key to determine who can access the Registry remotely, and by default any authenticated user can do so. In fact, authenticated users have Query Value, Enumerate Subkeys, Notify, and Read Control permissions on this key.
Windows Server 2003 then uses the permissions on the keys to determine access to individual keys.
If this key doesn't exist, Windows Server 2003 allows all users to access the Registry remotely and uses the permissions on the keys only to determine which keys can be accessed.
Inside Out: Services might need remote access to the Registry
Some services require remote access to the Registry to function correctly. This includes the Directory Replicator service and the Spooler service. If you restrict remote access to the Registry, you must bypass the access restrictions. Either add the account name of the service to the access list on the Winreg key or list the keys to which services need access in the Machine or Users value under the AllowedPaths key. Both values are REG_MULTI_SZ strings. Paths entered in the Machine value allow machine (LocalSystem) access to the locations listed. Paths entered in the Users value allow users access to the locations listed. As long as there are no explicit access restrictions on these keys, remote access is granted. After you make changes, you must restart the computer so that Registry access can be reconfigured on startup.
Note
Windows Server 2003 has an actual service called Remote Registry service. This service does in fact control remote access to the Registry. You want to disable this service only if you are trying to protect isolated systems from unauthorized access, such as when the system is in a perimeter network and is accessible from the Internet. If you disable Remote Registry service before starting the Routing and Remote Access service, you cannot view or change the Routing and Remote Access configuration. Routing and Remote Access reads and writes configuration information to the Registry, and any action that requires access to configuration information could cause Routing and Remote Access to stop functioning. To resolve this, stop the Routing and Remote Access service, start the Remote Registry service, and then restart the Routing and Remote Access service.
Access to the Registry can be audited as can access to files and other areas of the operating system. Auditing allows you to track which users access the Registry and what they're doing. All the permissions listed previously in Table 14-1 can be audited. However, you usually limit what you audit to only the essentials to reduce the amount of data that is written to the security logs and to reduce the resource burden on the affected server.
Before you can enable auditing of the Registry, you must enable the auditing function on the system you are working with. You can do this either through the server's local policy or through the appropriate Group Policy Object. The policy that controls auditing is Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAuditing. For more information on auditing and Group Policy, see Chapter 21 and Chapter 38, respectively.
Once auditing is enabled for a system, you can configure how you want auditing to work for the Registry. This means configuring auditing for each key you want to track. Thanks to inheritance, this doesn't mean you have to go through every key in the Registry and enable auditing for it. Instead, you can select a root key or any subkey to designate the start of the branch for which you want to track access and then ensure the auditing settings are inherited for all subkeys below it (this is the default setting).
Say, for example, you wanted to audit access to HKLMSAM and its subkeys. To do this, you would follow these steps:
After you locate the key in Registry Editor, right-click it, and select Permissions, or select the key, then choose Permissions on the Edit menu. This displays the Permissions For SAM dialog box.
In the Permissions For SAM dialog box, click the Advanced button.
In the Advanced Security Settings dialog box, select the Auditing tab.
Click Add to select a user or group whose access you want to track.
After you select the user or group, click OK. The Auditing Entry For SAM dialog box is displayed, as shown in Figure 14-13.
For each permission, select the type of auditing you want to track. If you want to track successful use of the permission, select the adjacent Successful option. If you want to track failed use of the permission, select the adjacent Failed option. Click OK to close the dialog box.
Repeat Step 6 to audit other users or groups.
If you want auditing to apply to subkeys, ensure the Allow Inheritable Permissions From The Parent To Propagate option is selected.
Click OK twice.
