Chapter 14: Group Policy Explained

Microsoft's group policy is one of the best management tools ever created for any computer system. No other operating system has anything nearly as sophisticated (although Novell's ZENworks comes the closest). With a few clicks of a mouse, nearly every local computer behavior can be managed. For instance, if a computer worm is found that abuses a particular program or service, the associated program or service can be disabled or turned off with one group policy setting change. Users can be prevented from running a particular program or only allowed to run an approved set of executables. File permissions can be set per user, per organization unit, or per domain. This chapter discusses group policy in detail, including every default OS security setting available in Windows XP SP2 and Windows Server 2003 SP1. Chapter 15 will continue the discussion and detail how group policy should be applied for maximum efficiency and effectiveness.

How Group Policy Works

Note 

In one sentence, group policy essentially applies local registry entries and settings that could otherwise be done programmatically or manually, although a few features go beyond that simplified description. Group policy requires Windows 2000 and later computers and Active Directory, although policies can be applied locally using the Local Computer Policy or templates on non-domain computers. XP Home Edition does not support group policy, Local Computer Policy, or the traditional security template tools.

Group policy can be applied by configuring group policy objects (GPOs) in Active Directory. You can configure an unlimited number of GPOs, and each GPO can have a single setting or, literally, hundreds. The GPOs are then attached to Active Directory organization units (OUs) or container objects (e.g., domain, Built-in Users, etc.). If permissions are appropriately set, the settings contained in the GPO apply to the users or computers located in the various OUs and container objects. Multiple GPOs can apply to a single user or computer, and when settings conflict the last one applied wins. Group policy settings can also be applied using the Local Computer Policy object, but any settings that conflict with nonlocal settings will be overwritten. Administrative templates and security templates, which can also contain group policy settings, can be applied locally or imported into GPOs. Chapter 15 will cover the group policy application pathway in detail.

Accessing Group Policy

Group policy settings can be set using GPOs, Local Computer Policy, or locally applied templates. Technically, only settings configured in GPOs are called group policy, but many of the settings that can be set in GPOs can be set in the latter two mechanisms as well.

Group Policy Object Editor

Group policies are often set in Active Directory using an interface that can interact with GPOs. When Active Directory was first released with Windows 2000 Server, GPOs could be created, modified, or deleted using any of the following management console tools:

• Active Directory Users and Computers

• Active Directory Domains and Trusts (domain-level GPOs only)

• Active Sites and Services (site-level GPOs only)

Most GPO work was done using the Active Directory Users and Computers console. In order to create or view GPOs, the user accessing the GPO through the console must have Read and Modify permissions to the GPO (even if they are only viewing the GPO), which is only given to administrators by default. In Active Directory Users and Computers, the administrator would first right-click an OU or container object as the focus, and then choose Properties ð Group Policy (see Figure 14-1). There you can create, modify, and delete group policies.

Figure 14-1

Group Policy Management Console

The original Group Policy Editor console (see Figure 14-2) needed a better interface. For one, in order for an administrator to review or modify a policy, they had to find it first. Locating which OU or container the policy was attached to wasn't always easy. The Group Policy Management Console (GPMC) was released around the same time as Windows Server 2003. Once any group policy manager has used it, they never go back to the original editor. It can be downloaded separately from www.microsoft.com/downloads or as part of one of the newer service packs.

Figure 14-2

The GPMC (see Figure 14-3) allows an administrator to view all group policies in one location, or to see which group policies are attached to which OUs and containers. You can easily see which group policies are directly associated with a particular OU or container, or which GPOs are inherited from parent objects. Even the language used to manage GPOs is improved, substituting more natural language names for the older technical language (e.g., Enforced vs. No Override). The GPMC is the natural way to view and modify GPOs.

Figure 14-3

Local Computer Policy Editor

Every computer, whether stand-alone or in a domain, also has a Local Computer Policy object. It is applied whenever the computer boots and is applied prior to any user logging on it. It can be configured by choosing Start ð Administrative Tools ð Local Computer Policy. Alternately, it can be started from the command line using Start ð Run, and typing in Gpedit.msc in the Open dialog command prompt. Strangely, starting the Local Computer Policy console either way results in a console entitled Group Policy on workstations or Group Policy Object Editor (see Figure 14-4) on servers. This can be confusing because the consoles configure local policy and not group policy. Local Computer Policy has many, but not all, of the same configuration settings as GPOs (covered in more detail in Chapter 15).

Figure 14-4

Templates

Most GPOs have Administrative Templates settings installed by default, and more can be imported. Administrative Templates often control many default Windows applications, and other applications (e.g., Microsoft Office, Internet Explorer) if vendors provided them. Administrative templates are covered in more detail below. Security templates can also be created and imported.

Security templates contain most, but not all, of the security settings that can be configured in a GPO. Security templates can be imported into GPOs and applied locally against machines (including non-domain machines). Security templates can be created manually (using text editors) or using the Security Templates MMC console. Security templates can be applied locally by importing them using Secedit.exe or the Security Configuration and Analysis MMC console. Templates applied locally tattoo the registry, meaning any changes they make will not automatically be removed if the template is removed.

One of the big differences between Administrative templates and Security templates is that when Security templates are imported, the settings they contain will take effect after importing. Imported Administrative templates enable an administrator to review new application settings and set particular settings, but will not immediately change any settings merely after being imported. Imported Security templates always set configuration choices. Administrative templates reveal choices.

Good computer security requires that administrators effectively and efficiently apply the right combination of settings using GPOs, Local Computer Policy, and templates. Chapter 15 is devoted to this discussion. In defining a security policy plan, it helps to understand how GPOs work under the hood.

GPO Internals

Logically, when a GPO is created, the resulting registry entries and local settings are created in Active Directory (i.e., group policy container) and stored on a domain controller's System Volume (Sysvol) folder. Each GPO gets its own subfolder (named after the GPO's GUID) under the Sysvol parent directory, and various other files and folders are created to hold the GPO settings that will be applied locally. If GPO settings are configured that result in registry entry changes, the following process occurs:

1. When the GPO Editor is started, a temporary registry tree is created for the USER and MACHINE hives. All settings that can affect a user are stored in the USER section. All settings that can affect a computer are stored in the MACHINE hive.

2. When an administrator navigates and configures the various sections of a GPO, the appropriate entries are written to the temporary registry tree.

3. When the GPO Editor is closed, the temporary registry tree is exported to Registry.pol files in GPO's GPT\Machine and GPT\User areas on Sysvol.

4. Whenever a GPO is view or read, Registry.pol settings are read back into a temporary registry tree for viewing and modification.

The GPOs are stored on the Sysvol awaiting computers and users to request group policy application. This is an important point. Computers and users must request group policy to be applied. Microsoft only built the necessary files and processes into Windows 2000 and later (refer to Figure 14-1). The Winlogon.exe and Userenv.dll processes manage the client-side application of GPOs and Local Computer Policy. Various local client files deal with the different parts of the GPO (e.g., security settings, IE settings, etc.). For instance, security settings configured in a GPO are managed by the Scecli.dll file, also known as a local client extension. Microsoft Windows comes with a set of built-in client-side extension files, which do the hard part of collecting and applying group policy settings. The client-side extensions are updated in each newer version of Windows and can be modified and updated by programmers and third-party vendors.

Group Policy Application

Behind the scenes, group policy is applied using the following steps:

1. When a computer starts and accesses Active Directory, it uses the Lightweight Directory Access Protocol (LDAP) to retrieve a list of all the relevant GPOs affecting the OU or container that contains the computer object (each user or computer in Active Directory can only belong as a member of a single OU or container).

2. Active Directory and the client-side extensions work in concert to build the correct resulting Registry.pol files for the MACHINE (and eventually, USER) registry hives.

3. The Server Message Block (SMB) protocol is used to download the GPO files to the local host.

4. The client-side extension (CSE) files work to interpret the downloaded GPO settings and apply them to the computer (or user).

Registry settings stored in the Registry.pol file in every GPO on the Sysvol are then pulled down to the local client and overwrite or modify the client's existing Ntuser.pol file(s). Computer policies are applied whenever a domain computer logs on to a domain (or whenever the computer starts if a Local Computer Policy is defined). Computer settings are stored in the computer's All Users profile. User policies are applied whenever a user first logs on and are saved to the user's personal profile (%Userprofile%). Administrative template policy settings are always applied first. Security policies are applied during the computer and user logons, and reapplied at period intervals, with a maximum default of every 16 hours.

Note 

This is a very simplified version of the GPO application process.

Policy versus Preferences

Group policy settings are written to two local registry hives as the primary targets:

 HKLM\Software\Policies HKCU\Software\Polices 

GPO settings are also applied to the following keys as a backup target:

 HKLM\Software\Microsoft\Windows\CurrentVersion\Policies HLCU\Software\Microsoft\Windows\CurrentVersion\Policies 

These are the preferred locations for GPO registry settings to be written and are known as Fully Managed or True policies. Anything written here will be "undone" if the GPO that applied it no longer applies. GPO settings written to the above registry keys are normally the only ones shown in the Group Policy Editor console when viewing Administrative templates.

GPOs can contain registry keys and settings that target registry entries outside of the fully managed keys. Anything written to registry keys outside the previously listed fully managed "GPO registry keys" will tattoo the registry and will not be undone if the related GPO is unlinked or disabled. GPO settings written outside these areas are known as preferences. Fully managed policies supersede preferences in conflicts, although if there are existing preferences and the fully managed policies are removed, the Preference settings previously in conflict will again become effective. Preferences can only be seen in the GPO Editor console by selecting Administrative Templates ð View ð Filtering, and then clearing the Only show policy settings that can be fully managed setting.

Accessing group policy settings and applying them is the easy part. Figuring out what group policy settings to configure and apply is the harder part. There are several hundred default settings you can review and configure. Most of the settings are moderately documented, but the following section will document all the default GPO settings from Windows XP Pro SP2 and Windows Server 2003 SP1.