Managing Change through Group Policy (part 1) - Working with Local Policies

System settings in Windows are controlled through changes in either the graphical interface or the command line. These changes are recorded in the System Registry, a central database that is located on each Windows system and is used to store configuration settings and otherwise control the behavior of a computer. As seen in Figure 1, the Vista registry is divided into hives or sections that either affect the computer or the users who rely on it to perform work. The registry can be controlled both locally and centrally, most often through a special control engine called Group Policy. Group Policy works through Group Policy Objects, special components of Windows that contain thousands of settings — about 2,450 settings in fact — each designed to control one single aspect of the operating system.

Figure 1. The Vista System Registry

GPOs are designed to define the way a system — desktop or server — appears and behaves. This includes items such as the contents of the Start menu, icons on the desktop, ability to modify the desktop, ability to run various software products, and more. GPOs can be used to manage settings that affect PCs, servers, and users. This makes GPOs not only the most powerful management infrastructure for Windows systems, but also the engine of choice for object management. This is why you should endeavor to work with and understand GPOs as much as possible.

GPOs can control several aspects of a computer. They can

• Modify the contents of registry hives

• Assign logon, logoff, startup, and shutdown scripts

• Be used to redirect data folders, moving precious user data to central locations so that it can be backed up and otherwise protected

• Deploy software to PCs

• Manage security settings

In addition, if you don't find the one setting you need to control, you can always add a custom administrative template to the mix and make your own modifications to the systems you administer.

As seen in Figure 2, GPOs contain thousands of settings. Each can be modified within the GPO and then saved into one object. This object can then be applied to hardware, affecting computer settings and therefore any user that interacts with them. Or the object can be applied to the users themselves, making sure that no matter which system they use, it will behave in exactly the same way each time they log on to Windows Vista.

Figure 2. A Group Policy Object

GPOs can be applied singly or in combination with other GPOs. GPO settings are assigned first for computers and then for users. GPO settings are cumulative and, depending on the order they are assigned, some settings may be overridden by others. Because of this, properly designing both the content of each GPO and the order in which the GPOs will be applied to the systems under your care is important. You should ensure that each GPO you design is targeted at a single object type, whether users or computers. Segregating GPOs in this manner will not only improve the speed with which each GPO is processed, but will also help in your delegation of administration structure.

1. Working with Local Policies

Each Windows computer system includes a local Group Policy, called the Local Security Policy (LSP). The local GPO is read each time the computer is started. However, if the computer is part of a domain — a network managed by Active Directory (AD) — this local GPO is often superseded by domain or central GPOs. Generally, the Local Security Policy contains fewer settings than do its central counterparts, partly because of its purpose and intent and partly because of the mechanism it uses to apply the settings.

Although central or directory GPOs include thousands of settings that control everything from the look of the desktop to the power settings of a computer, the LSP only includes items that are focused on security. As shown in Figure 3, this includes the following:

• Account Policies or the policies that control both password settings and account lockouts

• Local Policies or the policies that determine if you will audit activity on the computer, which user rights you will grant, and which security options you want to set

• Windows Firewall with Advanced Security or the settings that control which programs can talk to your computers and which programs can talk from your computer to others

• Public Key Policies or the policies that let you encrypt data on your computer

• Software Restriction Policies or the policies that control which software is allowed to run on your computer

• IP Security Policies or the policies that control how secure your communications with other computers will be

Organizations often elect to include content that is normally excluded from central GPOs into the local GPO. LSPs are often ideal to special settings that need only be applied locally or because their application is resource intensive. Because the LSP is applied as soon as the computer starts, it can provide a first line of defense, even and especially if your computer is no longer connected to the network. For this reason, you should include as many settings in the LSP as possible and then copy it to each system as it is installed.

Local policies are a boon for disconnected systems, but like the connected system, they presuppose that you have some form of control over the PC. To standardize systems, you must copy the policy you want to implement onto each one and then reboot them to make sure the policy is actually applied because it is only applied at system startup. Doing this is not very effective unless you need to rely on the local policy for specific purposes.

Every computer running Windows XP, Windows Vista, or Windows Server includes a local GPO by default. The settings in this default file are applied to each computer at every startup. Organizations that want to standardize certain elements of the desktop and other computer behavior should configure this policy object with default organizational settings and make sure this file is part of the installation set for each computer. Because these GPOs are local, they can also be different on each computer. To make the best of local GPOs, you should define a given set of parameters for each computer type (workstations, mobile systems, or kiosk computers) and change them as little as possible.

The local GPO is located in the %SYSTEMROOT%\SYSTEM32\GROUP POLICY folder. To view this folder, you must enable two settings in the Folder view options (Windows Explorer => Organize Menu => Folder and Search Options => View tab):

• Show hidden files and folders

• Hide protected operating system files (Recommended)

If you disable the later this generates a warning dialog box. The best practice in this regard is to enable the setting to capture a copy of the local GPO you want to deploy, then disable the setting afterward.

Local Security Policies are managed through a special console called Local Security Policy. This console is located in Administrative Tools.

Figure 3. The Local Security Policy

Local Security Policy contents

LSPs can contain several different security settings and, because they are your first line of defense, should be configured to provide a minimum level of security for each computer system connected or not in your network. Look to the recommendations of Table 1 to configure your LSP.

To make any changes in the Group Policy Editor — the engine that lets you modify the contents of the LSP — use the Tree pane to click on the item to change, then move to the Details pane to double-click on the setting to change. Modify the setting through its dialog box. Use the Explain tab to find more information about each one of the settings.

Using Multiple Local Security Policies

Windows Vista has the ability to include more than one single local GPO on each computer system. It applies these local GPOs in layers much as it applies central GPOs. As in previous versions of Windows, the first layer applies it to the computer system itself. The second applies to a local group, either the Administrators or a Users group. The third can apply a local policy to specific local user accounts. This gives you a lot more control over computers that may or may not be connected to an AD structure — computers in a workgroup, for example — but it still limits you to the content of the local policy only.

By default, you can only edit one single LSP with the Local Security Policy editor in Administrative Tools. The LSP lets you modify the behavior for the local computer system only. In order to modify and create more than one LSP on a system, you need to create a custom LSP console. To do so, follow these steps:

Figure 4. Creating a Multiple Local Security Policy