In-Depth
Ensuring Group Policy Security Settings Are Consistent
Security settings deployed with Group Policy are highly efficient but not guaranteed by default. With a few extra steps you can guarantee that these security settings apply persistently to computers.
- By Derek Melber
- 12/15/2004
Most companies are leveraging Group Policy to configure security and other environment settings on the computers in the domain. Your company is probably no different if you are running Windows Active Directory. The problem with this method of security deployment is that the IT staff and auditors become overconfident, believing that the settings are being deployed properly.
I don’t want to scare you into thinking that security settings in a GPO are no good. Rather, I want to show you their loopholes -- and the solutions. Microsoft has built these solutions into Group Policy, but you have to know they exist before you can configure them properly.
In this article I'll make all of the loopholes (and solutions) clear. We'll start by exploring key security settings, and will then discuss where the vulnerabilities reside when you change these security settings. Finally, we will review where the settings exist that can help reduce the vulnerabilities.
The Anatomy of a Security Setting
With almost 2000 settings, there are too many options that can cause confusion within a standard Group Policy.
The security settings that I will discuss here are under the Security Options node. You can find this node by opening a Group Policy Object in the Group Policy Object Editor and following this path:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Figure 1 also shows this path and what you will find under the Security Options node.
Now that you've located the settings in the GPO, we can explore what the settings will do to a computer once they are applied.
Almost every setting listed under the Security Options node modifies the Registry. Each setting is linked to a Registry value, which controls an aspect of the computer’s operating system and behavior.
When the GPO is applied to a computer, the settings that have been preconfigured using the Group Policy Object Editor are sent to the computer, thus changing the Registry values.
What Can Cause These Settings to Fail?
I don’t want to give the impression that Group Policy is in any way unstable. Group Policy is very reliable and stable. However, with the wrong settings configured, and incorrect security measures taken, these highly important security settings can be altered.
The security settings in a GPO alter the Registry on the target computer. Since the setting is just an update to the Registry, anyone with administrative privileges to the Registry and these Registry values can alter the settings. Even though a GPO deploys the security setting, these settings can be changed manually from the local computer.
There are two privileges that give the local users access to their Registry. Both need to be controlled to help ensure your security settings are not altered.
Administrators group: This group exists on every client and server in the domain. This group is stored in the Security Accounts Manager (SAM) and provides administrative privileges to the computer. This means that any user with membership in this group has full control over the computer, including the Registry.
Registry Editing Tools: There are two Registry editing tools: regedit.exe and regedt32.exe. These tools provide an interface to view, modify, and create Registry keys and values. These tools can be accessed quickly just by typing the tool name at the command prompt, which will open up the tool and the Registry contents, as shown in Figure 2.
Ensuring Security Settings Apply Consistently
There are three configurations that need to be in place and monitored to ensure that these local security settings are not modified. If the security settings are modified, it is almost impossible to track that they have been changed. This leaves the computer vulnerable and insecure.
The first configuration consideration is simple: do not place any user accounts in the Administrator's group on clients and servers. (Being in the Administrator's group gives full control to the entire computer.) Following this guideline should not pose a problem, since most users don’t need administrative privilege to use applications or access resources from their computer.
Tip: Administrators group membership can be controlled by a GPO. The setting is called Restricted Groups and can control the members of any group, as well as the other groups in which the controlled group is a member. To get more information about Restricted Groups visit http://www.windowsecurity.com/articles/Using-Restricted-Groups.html.
Another configuration you should make is to restrict user access to Registry editing tools. This is a Group Policy setting that is located under the User Configuration\Administrative Templates\System\Prevent access to Registry editing tools setting in a default GPO. This will prohibit targeted users from using the two default Registry editing tools, but won’t restrict them from accessing a third-party tool that updates the Registry. However, removing their ability to have administrative access will prevent them from installing a third-party Registry editing tool, which makes this setting extremely valuable.
A final setting that you can make controls how the security settings themselves get applied. To understand how this works completely, I'll briefly discuss how GPOs apply to computers.
When a computer starts, it communicates with the domain controller, which has the GPOs stored on them. The domain controller investigates whether the GPOs have been applied to the computer already by checking a version number associated with the GPO to the version number stored on the computer it is going to update. If the version numbers are not the same, the new GPO settings will apply to the computer (either for the first time or to update the changes made to the GPO). If the version numbers are the same, then the settings in the GPO are not applied, since the version number indicates they should be in synch.
The problem arises when the local administrator makes a change to the Registry that does not alter the version number on the local computer or the GPO. Thus, after the Registry is manually changed, the GPO shows that it should not apply again, since the version numbers match.
To configure the security settings in the GPO to apply to the target computers, even when the version numbers match, you will need to configure another GPO setting. This setting is located under Computer Configuration\Administrative Templates\System\Group Policy\Security Policy Processing. After you double-click this setting, you will see another dialog box that has a check box labeled “Process even if the Group Policy objects have not changed,” as shown in Figure 3.
|
Figure 3. This policy will reapply the security settings each time the GPO refreshes, regardless of the GPO version number Click to enlarge |
Once this GPO setting is configured, all of the security settings in the GPO will apply at each refresh interval (by default every 90 minutes), even when the version number is the same.
Summary
The security settings in Group Policy are very important to ensuring all computers in the domain are properly configured and secure. In a default environment, these settings are susceptible to being tampered with and changed to insecure values.
Steps such as removing all user accounts from the Administrators group and restricting access to Registry editing tools can help reduce the access to these security settings that reside in the Registry. However, one of the best methods to ensure these security settings are applied is to enforce them to reapply at every GPO refresh interval. This setting, in conjunction with eliminating access to the Registry itself, will reduce the exposure to having a computer vulnerable for very long.
Additional articles by Derek Melber