Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Managing Windows Server 2012 Systems : Managing the Registry (part 8) - Securing the registry - Auditing registry access

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
12/17/2014 3:33:11 AM

Controlling remote registry access

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. One way that remote access to a system’s registry can be controlled is through the registry key HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\Winreg. 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:

  1. Windows Server 2012 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.

  2. Windows Server 2012 then uses the permissions on the keys to determine access to individual keys.

If this key doesn’t exist, Windows Server 2012 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.

Windows Vista and later Windows versions disable remote access to all registry paths by default. As a result, the only registry paths remotely accessible are those explicitly permitted as part of the default configuration or by an administrator. In Local Security Policy, you can use Security Options to enable or disable remote registry access. With Windows Vista and later Windows versions, the following additional security settings are provided for this purpose:

  • Network Access: Remotely Accessible Registry Paths

  • Network Access: Remotely Accessible Registry Paths And Subpaths

These security settings determine which registry paths and subpaths can be accessed over the network, regardless of the users or groups listed in the access control list (ACL) of the Winreg registry key. A number of default paths are set, and you should not modify these default paths without carefully considering the damage that changing this setting might cause.

You can follow these steps to access and modify these settings in the Local Security Settings console:

  1. Open Local Security Policy. If you enabled Show Administrative Tools as a Start setting, you’ll see a related tile on the Start screen. Another way to do this is by pressing the Windows key, typing secpol.msc into the Apps Search box, and then pressing Enter.

  2. Expand the Local Policies node in the left pane and then select the Security Options node.

  3. In the main pane, you should now see a list of policy settings. Scroll down through the list of security settings. As appropriate, double-tap or double-click Network Access: Remotely Accessible Registry Paths or Network Access: Remotely Accessible Registry Paths And Subpaths.

  4. On the Local Policy Setting tab of the Properties dialog box, you’ll see a list of remotely accessible registry paths or a list of remotely accessible registry paths and subpaths, depending on which security setting you are working with. You can now add or remove paths or subpaths as necessary. Note that the default settings are listed on the Explain tab.

Note

Windows Server 2012 has an actual service called the 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 the 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.

Auditing registry access

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 3 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 Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.

After 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 want to audit access to HKLM\SAM and its subkeys. To do this, you follow these steps:

  1. After you locate the key in Registry Editor, press and hold or right-click it, and select Permissions, or select the key, and then choose Permissions on the Edit menu. This displays the Permissions For SAM dialog box.

  2. In the Permissions For SAM dialog box, tap or click the Advanced button.

  3. In the Advanced Security Settings dialog box, tap or click the Auditing tab.

  4. Tap or click Add to display the Auditing Entry For dialog box. Click Select A Principal to display the Select User, Computer, Service Account, Or Group dialog box.

  5. Type the name of a user or a group account. Be sure to reference the user account name rather than the user’s full name. Only one name can be entered at a time.

  6. Tap or click Check Names. If a single match is found for each entry, the dialog box is automatically updated and the entry is underlined. Otherwise, you’ll see an additional dialog box. If no matches are found, you’ve either entered the name incorrectly or you’re working with an incorrect location. Modify the name in the Name Not Found dialog box and try again, or tap or click Locations to select a new location. When multiple matches are found, in the Multiple Names Found dialog box, select the name or names you want to use and then tap or click OK.

  7. Tap or click OK. The user or group is added as the Principal, and the Auditing Entry For dialog box is updated to show this. Only basic permissions are listed by default. Click Show Advanced Permissions to display the special permissions, as shown in Figure 14.

  8. Use the Applies To list to specify how the auditing entry is to be applied. The options include the following:

    • This Key Only The auditing entries apply only to the currently selected key.

    • This Key And Subkeys The auditing entries apply to this key and any subkeys of this key.

    • Subkeys Only The auditing entries apply to any subkeys of this key but not to the key itself.

      Use the Auditing Entry For dialog box to specify the permissions you want to track.
      Figure 14. Use the Auditing Entry For dialog box to specify the permissions you want to track.
  9. Use the Type list to specify whether you are configuring auditing for successful access, failed access, or both, and then specify which actions should be audited. The events you can audit are the same as the special permissions listed in Table 3.

  10. Repeat steps 4–9 to configure auditing for other users or groups.

  11. The auditing entries are applied to subkeys by default through inheritance. If you want to replace the auditing entries on all child objects of this key with this key’s auditing entries, select Replace All Child Object Auditing Entries With Inheritable Auditing Entries From This Object.

  12. Tap or click OK twice.

Other -----------------
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 11)
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 10)
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 9)
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 8)
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 7)
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 6)
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 5)
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 4)
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 3)
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 2)
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server