An Easy Fix for a Sticky GPO Security Problem

Ease the pain by automating account creation.

• By Derek Melber
• September 01, 2004

The problem stems from the Registry changes that occur when you configure a policy under Computer Configuration|Windows Settings|Security Settings|Local Policies|Security Options. Most of these settings are simple Registry value changes that affect the computer the GPO targets. That means any user with administrative access to the Registry on the target computer can change the setting, even if the GPO policy configures the setting.

This might come as something of a shock, since Microsoft likes to claim that GPOs are bulletproof, secure, non-tattooing and stable. I won't try to make the case that such claims are 100 percent wrong, but in this case, at least, some education and guidance is in order.

Let's walk through a real-world example to help visualize the issue. Assume you've enabled the "Do not display last user name in logon screen" policy in a GPO that affects all computers and users in the domain, including administrators. When the logon screen appears following the CTRL-ALT-DEL key sequence, this policy removes the username of the last person who logged on to the computer, increasing security by obfuscation. You apply the policy to every user who logs on to the computer, including administrators.

Now the rub: Assume that Joe is the user who uses the computer account named Joe_XP1. Company policy requires users to be local administrators on their own computers so they can install applications and security updates. Therefore, Joe has administrative privileges on Joe_XP1. With this access, Joe can open the Registry editor, find the DontDisplayLastUserName Registry value, and change the value to 0—thus disabling the policy. The next time Joe (or any user) logs on to Joe_XP1, the username will appear in the Username textbox on the logon screen.

What about after the GPO has time to refresh or the computer is restarted? Neither action will fix the problem, because the GPO won't think anything's wrong. The GPO is aware only of the GPO version number, not the actual policy settings of that version. This version number is stored in the GPO and on the computer that it updates. In our example, the Registry value has changed, but not the GPO version number. Since the two version numbers match, the GPO passes on any configurations for the computer.

The solution to this problem is quite simple. A GPO policy, named "Security policy processing," controls how to handle GPO refreshes with regard to version checking. The policy is located under the Computer Configuration|Administrative Templates|System|Group Policy node in the GPO. When configuring this policy you'll see a check box labeled "Process even if the Group Policy objects have not changed." When this is checked, the GPO version is not evaluated for the Security Options settings in the GPO. Instead, all of the settings are configured on the computer as if it were the first time the GPO was being applied. This will occur at every refresh interval (by default every 90 minutes) and every time the computer is restarted.

Other settings to consider include:

• Use GPOs to deploy software, eliminating the need for users to be local administrators.
• Use GPOs to disable users from using Registry editing tools.

Even though the default GPOs don't combat local changes to GPO settings, there are GPO settings that can ensure the security is enforced on target computers.