News Analysis

Designing an access control strategy for the Registry

Ed Tittel

Designing Security for a Microsoft Windows Server 2003 Network The following excerpt is from Chapter 6 of the MCSE Exam Cram 2 book "Designing security for a Microsoft Windows Server 2003 network" written by Ed Tittel, courtesy of Sams Publishing. Click to purchase, check out the complete book excerpt series or go straight to the practice exam if you think you're ready to be tested.

Designing an access control strategy for the Registry

By default, only administrators have permissions to view or change the Registry. You can assign permissions to each of the keys in the Registry to allow certain users to make changes to the keys. You can also use the system to audit the Registry to determine which users have made changes or even attempted to make changes to the Registry. Your access control strategy for the Registry should include the following:

  • Designing a permission structure for Registry objects
  • Analyzing auditing requirements

Designing a permission structure for registry objects

In Windows Server 2003, all system information is centrally located in the Registry. The information is stored in containers called keys. The two main keys are HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE. One incorrect edit to the information contained in these keys can potentially disable the operating system. For this reason, only administrators should have access to the Registry on most computers. Users indirectly make changes to the Registry when they use GUI tools, such as Control Panel or Display Settings. These changes are much safer than changes made directly to the Registry.

Some applications and some hardware require a Registry edit to function properly. You might want to allow certain users to make the changes to the Registry so that you don't have to make them every time. If you choose to allow a user to make changes to the Registry, you need to ensure that he has the training and the knowledge to make the changes correctly.

You can assign permissions on each key of the Registry in much the same way that you assign permissions to files or folders. To do so, access the Registry using the regedt32.exe or regedit.exe tool, right click the key that you want to change, and click Permissions. The Permissions dialog box opens, as shown in Figure 6.9. You can then add a user and give him the permissions required to make the change. As always, you should only give him the minimum level of permissions required to make the appropriate changes. You can also use Group Policy to assign permissions to multiple users and computers at the same time.

TIP: You should rarely need to give a user Full Control permissions on a Registry key.

Analyzing auditing requirements

You only need to audit the Registry if you feel that someone is making changes to it without your approval. If troubleshooting a problem seems to indicate that a change was made to the Registry that could not have been made by another tool and could not have been made by accident, auditing the Registry is in order. In this case, you should audit the specific key where the change was made. You can set the auditing for the key in the Advanced section of the permissions for the key, as shown in Figure 6.10. In this case, you might want to audit the Everyone group for access to the Registry key because the list should not be large and because you want to ensure that everyone is included in the audit.

Figure 6.9: You can set permissions for each key in the Registry.

Figure 6.10: You can set audit entries in Advanced Security Settings for each key in the Registry.

You've finished all the excerpts. Are you ready to be tested?: Try your hand at these 10 Exam Cram prep questions

Click for the book excerpt series or purchase the book here.

Email Alerts

Register now to receive IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

COMMENTS powered by Disqus  //  Commenting policy