If you have answered yes to any of these questions, you are at risk of being overconfident regarding the security of all of the computers in your organization. This is a common scenario and one that is under documented within the Windows community.
In all reality, Microsoft has not made a big deal about this issue, due to the other security related issues that they have been working on, as well as they don’t want to let the cat out of the bag that some security settings are not as strong as you might think. However, they should be talking more about this issue, since they have a fix for it already, built-in to Group Policy and Active Directory.
In this article, we will go over the structure of the security settings, to give you a good understanding of where things might be modified. Then, we will go over the vulnerabilities regarding these security settings. Finally, I will guide you through some excellent tips on how to ensure that the security settings are deployed and enforced for all computers within Active Directory.
The Anatomy of a Security Setting
First, let’s make sure we are all on the same page with regard to the Group Policy security settings that I am referring to. There are plenty of settings within a default Group Policy Object (GPO), so the clarification is important.
If you jump into the Group Policy Object Editor for any GPO, you will need to open up the GPO to the following node, which can also be seen in Figure 1:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Figure 1: Security Options node within a standard GPO
These security settings are created within the Group Policy Object Editor by the sceregvl.inf file. The list you see in Figure 1 is only the default list of security settings. You can customize this list of settings by tracking down the security setting and where it needs to be configured. Then, you can customize the sceregvl.inf file and add the new setting to all GPOs. To get the full details on how to do these steps, refer to one of my recent articles on “Customzing Security Templates, which can be found at http://www.windowsecurity.com/articles/Customizing-Windows-Security-Templates.html.
If you were to crack open the sceregvl.inf file, you would see that most of these settings are Registry values. The sceregvl.inf file does two important tasks. First, it creates the interface for the Group Policy Object Editor. Second, it lists the Registry path and value that will be updated, as well as the possible data that the Registry value can be set to.
All of the security settings in this area of the GPO modify the HKEY_Local_Machine handle key of the Registry on the target computer. There are none of these Registry values that exist under the user’s portion of the Registry. You can see that from the path of all of the Registry values that are shown in the sceregvl.inf file, shown in Figure 2.
Figure 2: All of the Registry values in the sceregvl.inf file modify the HKEY_Local_Machine handle key on the target computer.
So, you can clearly see that these security settings are nothing more than a fancy way of updating the Registry on a target computer.
How Can These Settings Fail?
There are a couple of ways that Group Policy application fails. We only want to discuss the ways that the security settings can fail to configure the target computers successfully.
To get more information about why GPOs fail and how to fix most problems, you can get access to a free book on “Troubleshooting GPOs” at www.mcpmag.com/resources.
Since the security options portion of a GPO updates the Registry on the target computer, it might be easy for the user of the target computer to access the Registry, find the Registry value, and change the value to a less secure configuration. The end user might do this to gain access to operating system features, eliminate annoying security screens, or to decrease security on their computer to increase network communication. In any case, some users will have access to the Registry values updated by the GPO and can make changes to them.
The number one loophole around this access is to give the user of the target computer “Administrative” privileges over their computer. This is typically done by adding the user’s User account to the Administrators group on their computer. The Administrators group can include members from both the local Security Accounts Manager (SAM) and the domain’s Active Directory. When a user account is added to this group, the user has full control over the entire computer, including access to vital parts of the Registry.
How to Ensure the Settings Apply
When you go to the effort of configuring and implementing security through GPOs, you want to feel comfortable knowing that those settings will always be applied to the computers. You also want to know that the local users can’t control the Registry, thus modifying the settings that you have implemented. There are a couple of methods to help ensure that the security settings can’t be modified, but if they are modified, the GPO pushes the settings back down to the computer.
First, don’t give the user of the computer local Administrative privileges. There are only a few instances when this is required, and even in these cases it can be avoided. If the user does not have administrative privileges, they won’t be able to control the computer at the level required to modify the Registry and bypass security.
Second, you can configure a GPO to remove the ability for the users to access the Registry editing tools. This is not a fool proof method to protect the Registry, but it does restrict most end users from causing problems. This GPO setting is located under:
User Configuration\Administrative Templates\System\Prevent access to Registry editing tools
This is a simple Enabled/Disabled policy, which needs to be set to Enabled to restrict the access to the Registry editing tools by the targeted users.
Finally, you can set another GPO policy to enforce the security settings down to a computer every time GPOs are refreshed. The default behavior of GPOs is to refresh every 90 minutes. However, the GPOs will not reapply the settings unless the GPO version number has changed. The only way the version number changes is to have a change occur within the GPO. Therefore, if the local user changes the Registry, the GPO setting will not be reapplied at the next refresh, since the GPO version has not changed.
To enforce the security settings down to the target computers, you will need to modify the following GPO policy, which is also shown in Figure 3.
Computer Configuration\Administrative Templates\System\Group Policy\Security Policy Processing
Inside this policy, you will check the box labeled “Process even if the Group Policy objects have not changed.”
Figure 3: This policy will reapply the security settings each time the GPO refreshes, regardless of the GPO version number.
Forcing the GPO to reapply the security settings at each refresh can cause a minor hit to performance, if there are many security settings and many GPOs set to enforce the policy settings. If just one GPO has this configured, there should not be any problem with performance.
With security settings being deployed through GPOs positioned to be so important, you need to take all precautions to ensure the settings deploy properly and stay configured. You can eliminate the users of the computers from having administrative privileges, but this will only get you so far. You also need to ensure they don’t have access to the Registry editing tools. The final setting is to enforce the security settings from the GPOs to reapply at each refresh interval. This will ensure that even if the end user finds a way to modify the Registry, the setting will be placed back to the proper GPO security level within 90 minutes.