GPO Security

You can view the CSEs that are currently registered on a given machine by opening the registry and viewing the subkeys under the HKEY_LOCAL_MACHINE\SOFTWARE\MicrosoftWindowsNT\CurrentVersionWinlogon\GPExtensions subkey. Each globally unique identifier (GUID)–named subkey under the GPExtensions subkey represents a CSE. Within those GUID-named subkeys are the name of the DLL that implements the policy functionality and values that control the behavior of the CSE when it processes policy settings.

One default behavior for all CSEs is that they don't reprocess a GPO's settings if the GPO hasn't changed since the last time it was processed. Windows processes a computer-specific policy such as a security policy at machine startup (or shutdown), whereas a user-specific policy is processed at user logon (or logoff). These two events are called foreground processes. In addition to performing these two processes, Windows processes policies in the background every 90 minutes (plus a skew value) on workstations and member servers and every 5 minutes on DCs. However, the CSEs skip foreground or background processing of a given GPO if it hasn't changed since the last processing cycle. So, if a user somehow makes a change to his or her local configuration that contravenes the policy that your AD-linked GPO dictates, that local change remains in effect until someone changes the GPO that controls that policy, which might not occur for some time. For that reason, the security CSE periodically refreshes the security policy, regardless of whether the GPO has changed. The MaxNoGPOListChangesInterval value of the HKEY_LOCAL_MACHINE\SOFTWARE\MicrosoftWindowsNT\CurrentVersionWinlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A} subkey controls the refreshment interval. The default value is 960 minutes (16 hours), but you can increase or decrease the interval by modifying the registry value.

If you want to ensure maximum enforcement of your security policy, you can set the security CSE to process security policy at every processing cycle, regardless of whether the GPO has changed. This extra processing will create additional overhead, of course, but you can enable the processing on a per-machine basis to ensure that your most crucial servers or workstations always have the most up-to-date security configuration.

To modify the behavior of the security CSE on a computer, open the Group Policy Object Editor and navigate to Computer Configuration\Administrative Templates\System\Group Policy\Security Policy Processing under a GPO thtat's processed by the computer. Select Process even if the Group Policy objects have not changed, as Figure 2 shows. The machine will now refresh the security policy during every foreground and background processing cycle.

I've covered some of the mechanics for deploying GPO-based security policies. Now let's look at how you can get the most from some of the more popular Windows security policy areas.

Exploiting Windows Security Policies
Windows 2003, XP, and Win2K have truly hundreds of settings that you can deploy to ensure the secure configuration of your servers and workstations. The questions are, how do you find all of these settings, and what do they all do? A good starting point for understanding security policy settings is Microsoft.

In April, Microsoft released the Windows Server 2003 Security Guide (http:// www.microsoft.com/technet/security/prodtech/windows/win2003/w2003hg/sgch00.asp), which provides security templates for a variety of typical server roles (e.g., high-security file servers and enterprise DCs). You can download similar templates for Win2K Server at http://www.microsoft.com/downloads/details.aspx?familyid=9964cf42-e236-4d73-aef4-7b4fdc0a25f6&displaylang=en#filelist. XP includes some basic security templates in the %systemroot%\security\templates folder.

To use a template in your Group Policy environment, you simply import the .inf template file into the GPO that will hold the settings by right-clicking the Security Settings node in the Group Policy Object Editor and selecting Import Policy. You can also use the MMC Security Templates snap-in to view and edit the Windows 2003 and Win2K templates, as Figure 3 shows.

Addressing Windows Vulnerabilities
If you examine the templates, you'll notice that many of them set security options under the GPO's Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options node. I call this area of security policy the vulnerability defense page because it contains settings that address Windows configuration vulnerabilities that have been identified over time.

Settings under the Security Options node let you perform actions such as renaming the administrator and guest accounts across all your boxes or turning off anonymous enumeration of SAM accounts. The Windows 2003 and Win2K security templates provide some best practices for securing your Windows boxes by turning off known vulnerabilities, but you should test the settings in your environment before widely deploying them. Some of the settings can prevent the proper operation of your network, especially if you have earlier client OSs that don't support them.

The Software Restriction Policy
I don't have the space to cover all the various security policies that are available in Group Policy, but one policy area that merits some attention is the software restriction policy. This policy is new in Windows 2003 and XP; thus, you must be running one of these OS versions to use this policy. The software restriction policy is available in a Group Policy as either per-computer or per-user settings. In a nutshell, the software restriction policy lets you prevent certain applications from running. You can restrict an application according to the X.509 certificate that signed it, its file hash value, the Internet zone it came from, or its file path.

The easiest way to explain how you can use the software restriction policy is to walk through an example. Let's say I want to prevent all users in my AD domain from being able to run any applications that are launched from the Temporary Internet Files folder under their user profile. Files downloaded by Microsoft Internet Explorer (IE) are typically stored in this folder temporarily; thus, it's a good place to restrict code execution.

The first thing I need to do is enable software restriction within my GPO by navigating to Computer Configuration\Windows Settings\Security Settings, right-clicking the Software Restriction Policies node, and choosing Create New Policies. Windows immediately creates a set of objects I can use to modify software restriction behavior and displays them in the Group Policy Object Editor, as Figure 4 shows.

The three leaf nodes in the right pane—Enforcement, Designated File Types, and Trusted Publishers—let you set global options for a software restriction policy. In most cases, you can take the defaults for each.

The Security Levels folder contains two options to choose from: Disallowed and Unrestricted. The default state is Unrestricted, which lets users run all software except for programs explicitly disallowed by the software restriction policy. The Disallowed option prevents users from running any software except programs explicitly permitted by the software restriction policy. For the purposes of this example, I use the default Unrestricted value.

The real meat of the software restriction policy is in the Additional Rules folder. If you right-click this folder, you see that you can create rules according to the four criteria I identified above. For my example, I want to create a rule that prevents any software that's located in the user profile's Temporary Internet Files folder from running. So, I create a new path rule, set the path to %userprofile%\local settingstemporary internet files, then set the security level for this rule to Disallowed, as Figure 5 shows.

When a computer processes this policy, the system won't run any application files in the Temporary Internet Files folder whose types are on the Designated File Types list. As you can see, the software restriction policy can be a powerful policy for preventing unknown executable code from running amok on your network.

More Security Controls
Hopefully, I've whetted your appetite for learning about and using all the Windows Group Policy security configuration settings in your environment. In addition to policies I've mentioned here, you can set file, registry, and service permissions and even use a restricted groups policy to control group membership. Windows 2003 offers a wireless network policy that lets you control which Access Points (APs) your wireless Windows clients can connect to and whether they must use Wired Equivalent Privacy (WEP).

Overall, Group Policy security policies give you an unprecedented amount of control over your Windows security configurations. You owe it to yourself and your company to explore these capabilities to their fullest.