Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Group Policy Tools

Group Policy Editor (GPE) is the native Windows tool for managing Group Policy. The GPE snap-in can be added to an MMC console and is opened when a GPO is created or modified from the Group Policy property pages of a container in Active Directory Users and Computers. The GPE is easy to use and provides basic utility. However, it does not provide many features that are essential for managing Group Policy. You cannot tell, for example, the impact of a combination of multiple GPOs on a specific workstation, server, or user. You cannot copy the GPO or export it and use it in another domain. You cannot even print the policy. To examine the settings in the policy, you must browse through the policy, opening many subcontainers to determine if anything in them is set.

A new tool, the Group Policy Management Console (GPMC), fills in these holes. The tool, which can be downloaded by licensed owners of Windows Server 2003, can be used to manage Group Policy in a Windows 2000 domain. GPMC can only be run on a Windows XP Professional or Windows Server 2003 computer. While it is not necessary to obtain the tool to create and use GPOs, without the tool, it is much more difficult to manage Group Policy.

NOTE: GPMC for Windows 2000 Domains

Although you can manage a Windows 2000 domain with GPMC, some features of GPMC are only available with Windows Server 2003 and Windows XP clients.

After GPMC is installed on a DC, attempting to create or edit a GPO using the Group Policy property page of an object will not work. Instead, doing so will provide a link, as shown in Figure 7-24, to GPMC, instead of access to the GPE. When GPMC is used to manage Group Policy and Edit is selected from a context menu, the Group Policy Editor is loaded.

Figure 7-24. The GPMC replaces the Group Policy Page. You can still invoke the Group Policy Editor from the GPC, but options that affect policy implementation are configured using GPMC.

Group Policy Editor

If you have installed GPMC, you will still use GPE to edit a GPO. However, if you installed GPMC, some features of GPE will be managed in the GPMC interface. Prior to installation of GPMC, GPE can be used to do the following:

Create a GPO and edit its features

Manage a GPO inheritance

Filter a GPO application

After GPMC is installed, only GPO editing is done using the GPE.

Creating, Linking, and Editing GPOs

To create a GPO, you will edit a blank template until it contains the desired settings. For the settings to be applied, the GPO must be linked to a SOM. GPO creation and linking are two separate actions. It is possible to have a GPO that is not linked to SOM, and it is possible to link a GPO to many SOMs. Prior to the installation of GPMC, a new GPO is created using the property pages of a SOM and is linked automatically to that SOM. When GPMC is used, a GPO may be created and linked to a SOM using one operation or two.

To create a new GPO, follow these steps:

Select the Group Policy tab, as shown in Figure 7-25.

Figure 7-25. New GPOs are created using the New button.

Click New.

Enter a name for the new GPO and click OK.

To edit the GPO, select the new policy and click Edit.

Edit the policy by selecting a container and navigating to the specific option. Then open the item from the details pane, as shown in Figure 7-26.

Figure 7-26. The entire policy is listed for viewing or editing.

[View full size image]

When the edit is complete, close the GPO by closing the policy windows.

An existing policy can be edited by opening it from the Group Policy property page of the SOM, or it can be loaded in an MMC console and edited. To edit a GPO in a console, follow these steps:

Open the console by using the Add/Remove Snapins choice from the File menu of an empty console and selecting Group Policy Object Editor.

On the Welcome page of the wizard, use the Browse button to locate the policy to edit, as shown in Figure 7-27, and then click OK.

Figure 7-27. Select the policy to edit by browsing the Active Directory objects where the policy can be linked.

Click Close; then click OK to return to the console and edit the policy.

Controlling GPO Inheritance Using GPE

The Active Directory structure is hierarchical, and GPOs are processed according to where they are linked in that structure. The following rules of inheritance apply:

GPOs can be linked to sites, domains, and parent and child OUs.

GPOs are inherited by users and computers whose accounts reside either directly in a container or in a child container of these objects.

All of the security settings from all GPOs are applied cumulatively, unless there is a conflict.

A conflict is resolved by allowing the last setting to overwrite all previous settings. For example, if the DNS Server service is disabled in a GPO linked to the domain but is set to start automatically in a GPO linked to the OU within which a server account is located, the server, if DNS has been installed, will be able to start the DNS service successfully. A server whose account may be elsewhere in the domain (where no other GPO makes a change) will not be able to start the DNS service, even if the service is installed.

Modifying this standard behavior is sometimes necessary. GPOs in Windows 2000 and Windows Server 2003 domains can be marked to block the inheritance of other GPOs to prevent a GPO from overriding settings and allow machine settings to be reapplied over individual settings. Best practices require that these techniques are applied sparingly. Many problems with Group Policy processing are discovered not to be problems at all. Instead, they are traced back to the unwise, unauthorized, or simply "set and forget" usage of these properties.

Block Inheritance

The Block Inheritance property is used to prevent inheritance of a GPO. The configuration and management of computer and user accounts may be so critical that it is necessary to block potential changes from a GPO linked to an object above. For example, to manage users and computers in an OU, a GPO may be created and configured to apply security and other configuration settings appropriate for these accounts. Settings configured in the GPO linked to the OU will automatically override any settings configured in GPOs linked at the domain or site level. However, if some settings are not configured at the OU level and are configured at the domain or site level, the settings will be inherited by the OU. There are hundreds of settings, and it is possible for an inherited setting to aversely impact users and computers. To prevent this from happening, two things can be done. First, all non-policy configured settings can be set so that they match the default settings for users and computers in the OU. Second, the Block Inheritance setting can be selected, which will block inherited settings.

To set block inheritance, follow these steps:

Select the Group Policy property page from the SOM's property pages.

Select the Block Policy inheritance check box, as shown in Figure 7-28.

Figure 7-28. Block Inheritance can be set to prevent the application of a GPO from a parent object.

Click OK.

No Override

The No Override or, as it is called in GPMC, Enforcement property ensures that a Block Inheritance setting has no effect. In an environment where the responsibility for GPOs is delegated, it is possible that the administrator of an OU might inadvertently or maliciously use Block Inheritance and therefore thwart the organization's security policy. The security policy specified in a domain or parent OU is blocked when Block Inheritance is set. It is also possible that some policy settings in a GPO are so critical that it is desirable to ensure that no present or future GPO will override them. In either case, setting the No Override/Enforcement property of a GPO will ensure that the GPO settings of a parent object are inherited. If Enforcement is set on an inherited GPO, and Block Inheritance is set on a local GPO, then Enforcement will win.

To set No Override, follow these steps:

Open the Group Policy property page of the SOM.

Double-click on the policy in the Enforce column of the GPO.

Click Close.

Loopback

The loopback property is used to reapply the user portion of the GPO applied to the computer account after all GPOs have been applied. This option may be required when it is desirable that a specific security policy is applied, no matter which user logs on to the computer. This is a good policy for kiosks or other public computers where both employees and non-employees may log on. Ordinarily, when a user logs on, he inherits user settings from each GPO that is applicable to his account. His environment will be configured exactly the same way, no matter which workstation he uses, as long as policy can be obtained and as long as the computer supports the settings in the policy. This user-based consistency is desirable in most circumstances. However, there may be a situation in which it is preferred that every user is treated the same or a situation where it would be undesirable if the elevated privileges of administrators or other privileged users was applied. Instead, it must be ensured that no matter who the user is, he has limited access and privileges on the specific system or network. Situations where this is important are those where a specific computer(s) is used for a unique purpose. Examples of kiosks are computers in a mall used for gift selection, a workstation on a plant floor used for product location, a lobby kiosk that provides public information, an Internet browsing station at a conference, a computer in a learning lab, and so on. You can imagine, for example, what might happen if an unprotected public system was used by a domain admin, who then left it without logging off. If the next user is able to access the system before the logon times out, this user may now have administrative privileges on the network. He certainly has them on the current computer. To ensure that this type of vulnerability does not occur, use loopback processing.

Unintended Consequences

During a recent consultation, the network administrator of a school complained that his Group Policy computer lockdown efforts were not being applied to workstations in the student labs. He reported that students had still been able to access and change operating system features and change registry settings that should have been blocked by Group Policy.

Using GPMC, I quickly established that the Group Policy should have worked as he expected. We visited the lab, and I logged on using a student account and was unable to make any of the changes he said the students could. I suspected that either students had administrator account credentials or perhaps an administrator had visited the lab and not logged off. The school did not have auditing enabled for workstations in the lab.

As we were returning to his office where I intended to propose loopback and auditing, the administrator was paged. He then proceeded to log on to a lab computer and use it to complete a request. His pager went off again, and he started to leave the lab without logging off. I called his attention to it, logged him off, and followed. Later I was able to explain loopback and my opinion on doing administrative work from a student lab (you shouldn't). It turned out that lab supervisors had administrative privileges and did use student computers. In the hectic atmosphere of the lab, they often forgot to log off, or they logged on and allowed students to use their account to install software. The student access problem was solved with a change in procedures, which now specify that student computer lab computers must be remotely administered, and the implementation of a loopback policy.

Loopback processing has two modes: merge and replace. In practical application, however, few loopback situations require the merge mode. In the merge mode, the user's settings are kept, but the computer policy user settings are applied. Since they are applied last, if there is any conflict, the computer policy settings will win; however, any configuration not set by the loopback policy will remain. Replace mode ensures that none of the user's settings is available.

To set loopback replace mode, follow these steps:

Open the GPO for editing.

Navigate to Computer, Administrative Templates, System, Group Policy, and double-click to open the User Group Policy Loopback Processing Mode in the details pane.

Select Enabled.

Use the drop-down box to select Replace, as shown in Figure 7-29.

Figure 7-29. Loopback is configured by using GPO Administrative Templates.

Click OK; then click Close.

Filtering by Groups

The Security property page of a GPO defines which groups receive the policy. Those groups given the Read permission and the Apply Group Policy permission will be assigned the policy. By default, the Authenticated Users group is assigned these permissions. This means that the GPO will be read and applied to all accounts that exist in the SOM where the policy is linked. It is possible, however, to manipulate the application of a GPO by adding specific groups to the security page and either giving them the Allow or Deny Apply Group Policy permission. Best practices recommend that if you need to filter by groups, you should add all groups that should receive the policy and remove the Authenticated Users group. By default, a group that is not given this permission will not receive the policy.

Windows Server 2003 introduces another way to modify the application of a GPO: WMI filters. Windows Management Instrumentation (WMI) is a way to manage Windows computers. WMI filters on GPOs are used to limit the application of the GPO to computer or user accounts that meet specific characteristics. Rather than filtering a GPO application by membership in a group, a dynamic group can be created. The dynamic group consists of a collection of accounts with a specific characteristic. For example, a WMI filter could select all computers that have a specific network card, or all users who work for a specific manager, and apply a GPO only to those computers or users. If a computer's network card was replaced with another model, or the user was assigned to a new manager, the accounts would no longer be a part of the dynamic group and would not receive the policy. Likewise, if a new computer received the specific network card, or a new employee was transferred to the manager's department, the accounts would become part of the dynamic group and would receive the policy.

WARNING: Watch out for WMI Errors

If an error occurs during the use of a WMI filter on a GPO, GPO processing may be affected. If the error is known, the GPO will be applied, although the WMI filter may not be used. However, if the error is unknown, the GPO may not be processed at all. More information can be found in the Knowledge Base article 814613 at http://support.microsoft.com/default.aspx?scid=kb;en-us;814613.

A Practical Use for WMI

Even though some environments do not use DHCP, disabling the DHCP client service is not recommended because the DHCP client service may also be used to automatically update DNS records. When the DHCP client service is disabled, DNS updating must be done manually. In a locked down environment, however, policy may require the disabling of all non-essential services. In one such environment, the decision was made to disable the DHCP client service and take the responsibility for manually updating any changes to the statically assigned DNS records. Everything worked just fine, until some new network cards were installed. Machines with these cards installed ceased to function on the network. They could not communicate with other computers. Re-enabling and starting the DHCP client service had no effect. After a reboot, however, they returned to full function. Because the computers were joined to a Windows Server 2003 domain, a WMI filter was created to ensure that computers with the offending network card receive a policy that enables the DHCP client service, while other computers do not. Because the filter works on a machine characteristic, there was no need to create a special OU of these machines, and when a computer received a change in network card, it was automatically detected, and the computer received the right policy.

Resultant Set of Policy

One of the problems with Group Policy in Windows 2000 is that it can be difficult to determine the actual results of a Group Policy implementation. It's difficult to keep straight the impact of multiple policies and the options that can impact inheritance. There is no native Windows 2000 tool to help do this. A Windows 2000 resource kit tool, gpresults, can be used to determine the outcome for a single user logged on to a specific workstation. In effect, it reads the policy applied. You must, however, log on as that user at that machine to use the tool. Afterward, you must analyze the text-based report and examine other information to determine the results. If you want a picture of policy at another machine or the effect of policy on the current machine but for a different user, the process must be repeated.

A second problem with Windows 2000 Group Policy is its inability to help in the design of a Group Policy architecture. Policies have to be created and assigned to real computers and users to confirm the results.

Using a new tool in Windows Server 2003 domains solves both of these problems. This tool is Resultant Set of Policy (RSoP). The tool can poll existing policies by using logging mode or planned policies by using planning mode and display the results. When logging mode is used, the effect of GPOs on a specific computer and user are evaluated by connecting to the computer. When planning mode is used, any combination of user and computer account location can be selected to test the effect of the GPOs that are linked to the location and the combinations of policies applied. Planning mode allows the determination of the "what if" effect of GPOs. Because no actual computer is accessed, planning mode can be used even before a computer is joined to a domain. All GPOs, including site, domain, and OU policiesmay be reviewed, depending on the mode. (Local and site policy, for example, cannot be evaluated for a computer that does not yet exist because no local policy is established and there is no way to tell what site the computer might ultimately be located in.) RSoP uses the Common Information Management Object Model (CIMOM) database (the CIM-compliant object repository) through Windows Management Instrumentation.

RSoP queries are created using the Resultant Set of Policy Wizard, which is accessible as a snap-in loaded into an MMC, by right-clicking a site, domain, or OU object, and from the Group Policy Management Console. (Once GMPC is installed, the wizards supplied with GPMC are always used.) If the created query is saved, it can be accessed again to refresh or modify the query.

To create an RSoP planning mode query, follow these steps:

Open Active Directory Users and Computers.

Right-click the SOM, select All Tasks, and then select Resultant Set of Policy (Planning Mode) from the context menu. The User and Computer Selection page is populated with the SOM, as shown in Figure 7-30.

Figure 7-30. Confirm that the correct user and computer container, user, or computer account is selected.

[View full size image]

Accept the selected container for user and computer accounts, and click Next.

If desired, select simulations of slow network connection or loopback processing.

Select the site and click Next.

Add or remove security groups to simulate user membership and click Next.

Select whether or not to assume that the user meets criteria for specific WMI filters and click Next.

Select whether or not to assume that the computer meets criteria for specific WMI filters and click Next.

Review selections.

10.

Select a domain controller on which to process the simulation; then click Next.

11.

Some time may elapse. Click Finish when the process is complete.

12.

The Resultant Set of Policy is displayed in an MMC, as shown in Figure 7-31, and can be browsed to view the results.

Figure 7-31. The RSoP Wizard displays results in an MMC, which can be saved for viewing and analysis and to be used to refresh or change the query.

[View full size image]

RSoP planning and logging can be generated from an MMC to which the Resultant Set of Policy snap-in is added.

To do RSoP logging:

Add the snap-in to a console.

Select Generate RSoP Data from the Action menu.

On the welcome page of the wizard, select Next.

From the mode selection page, select Logging mode, as shown in Figure 7-32, and click Next.

Figure 7-32. The RSoP snap-in can be used to generate planning or logging RSoP data.

[View full size image]

Select the computer to generate data for. The computer must exist and be reachable.

Select whether to display computer and user settings or just user settings and click Next.

Select the user to display, as shown in Figure 7-33, or select not to display user results (display computer policy settings only) and click Next.

Figure 7-33. Select the user for which to display the policy.

[View full size image]

Review your selection and click Next. Click Finish when complete.

Group Policy Management Console

GPMC provides the answers for many Group Policy management issues and concerns, empowers the Group Policy administrator, and has the potential for eliminating the need for third-party products and for reducing staff requirements. GPMC provides all of the following:

An easy-to-use GUI, making Group Policy easier to use

Backup, restore, and copying of GPOs

HTML reporting of only the GPO settings that are actually configured

HTML reporting of Resultant Set of Policy (RSoP) data

Simplified management of Group Policy security

Import and export of GPOs and WMI filters

Copy and paste of GPOs and WMI filters

Scripting of policy tasks exposed within the tool (it does not include the ability to script settings within a GPO)

The ability to administer Windows 2000 GPOs

GPMC can be used to manage Group Policy for multiple domains and multiple forests and is an effective Group Policy troubleshooting tool. These capabilities will be described and illustrated in Chapters 8 and 10, respectively. This chapter will look at using GPMC in a single Windows Server 2003 domain.

Installing and Configuring GPMC

GPMC is not a native Windows Server 2003 utility. It was released after Windows Server 2003 shipped, but it is available as a free download. The console can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyId=F39E9D60-7E41-4947-82F5-3330F37ADFEB&displaylang=en.

While GPMC can be used to manage Windows 2000, Windows XP Professional, and Windows Server 2003 computers, it must be installed on a Windows XP Professional or Windows Server 2003 computer. If Windows XP is used, it must have the following:

Service Pack 1

The Microsoft .NET Framework

The post SP1 hotfix (QFE 326469), which updates gpedit.dll to version 5.12600.1186, which is required by GPMC

To install GPMC, follow these steps:

Double-click the gpmc.msi package and then click Next.

Read and accept the End User License Agreement (EULA). Note that the license specifies that you must have a valid license for Windows Server 2003 to run the utility. Click Next.

If installing on Windows XP, if the gpedit.dll has not been updated, you will be prompted to install post SP1 hotfix 326469. The hotfix is delivered with the download and can be installed at this time.

Click Close to complete the installation.

To open the GPMC console, you can do one of the following:

Click Start, click Run, type GPMC.msc, and click OK.

Use the Group Policy Management shortcut from Administrative Tools.

Open GPMC from the property pages of sites, domains, and OUs.

Create a custom GPMC console by adding the Group Policy Management snap-in to an MMC.

First Looks

When first loaded, the GPMC console, as shown in Figure 7-34, displays the forest in which the account used to run the utility exists. Additional forests can be loaded and managed if the account has authority to manage Group Policy within those forests. Each forest will have three or four containers: Domains, Sites, Group Policy Modeling, and Group Policy Results. (The Group Policy Modeling node will not be present in a pure Windows 2000 forest.)

Figure 7-34. GPMC is a tool that provides superb management of Group Policy.

[View full size image]

The Domains and Sites containers have subnodes. Each domain in the forest is represented below the domain node, while each site is represented below the site node. Group Policy Modeling and Group Policy Results work like the RSoP logging and planning modes, respectively.

Expanding a domain container displays a policy-based view of Active Directory and lists additional Group Policy elements. All GPOs that are linked to the domain can be reviewed from the Group Policy Objects container, or by expanding the Domains or OU containers. WMI filters are also listed.

The Group Policy Objects container holds the GPOs, whereas the SOMs (Domains, OU, Sites) contain only the links from that SOM to the GPOs. GPOs can be linked to more than one SOM. This fact is graphically displayed. The detail pane of a selected SOM displays three tabs, as shown in Figure 7-35. In the figure, below each SOM, links are displayed as a shortcut, while in the Group Policy Objects container, they are shown as little scrolls without the shortcut arrow. This graphical illustration shows that the GPO exists separately from any container (SOM). This distinction is true in Windows 2000 and in Windows Server 2003, but in Windows 2000, the GUI does not aid in its understanding and instead gives the false impression that a GPO does not exist separately from a container. It's also important to understand that GPO-related operations, such as backup and copy, must be performed from the GPO, not from the link.

Figure 7-35. Each SOM is defined by several property pages.

[View full size image]

In addition to the Linked Group Policy Objects tab, the Group Policy Inheritance tab, as shown in Figure 7-36, displays a list of GPOs that are inherited from parent containers by the SOM in the order of their application (precedence). The list does not include any Site policies. Read the list from the bottom up to see the order in which the policies are applied. In the figure, the default domain policy is applied, and then the F01 policy. Settings in the F01 policy will have precedence over most settings in the default domain policy. (Exceptions are the domain Account policy and User rights on the domain policies, as outlined earlier.)

Figure 7-36. All inherited GPOs are listed with the exception of Site policies because these may vary depending on the computer and user account and what site they are in.

[View full size image]

The Delegation tab, as shown in Figure 7-37, details the delegated administrative permissions on the SOM. The drop-down list is used to view the Link GPOs, perform group policy modeling analysis, and read group policy results data permissions. Note that both inherited and explicit permissions are listed. To view delegated permissions at the GPO level, you must examine the property pages of the GPO.

Figure 7-37. Delegated permissions are listed. You must change the drop-down list to view different permissions.

[View full size image]

GPO-specific properties can be examined by double-clicking on the GPO. Scope, Details, Settings, and Delegation tabs are available.

Scope is detailed in Figure 7-38 and displays what SOMs the GPO is linked to; which users, computers, and groups the GPO will apply to; and which WMI filter the GPO is linked to.

Figure 7-38. The Scope pane is used to determine where the GPO is linked.

[View full size image]

The Details tab of a GPO provides information relative to the GPO, including whether or not the user or computer portions of the GPO are enabled.

The Settings tab displays only the settings configured for this GPO.

The Delegation tab lists the explicit permissions on this GPO and will include the users, computers, and groups to which the GPO will apply.

GPMC Options

Several options are available to customize how GPMC works. The following options can be selected from the View, Options menu of the GPMC.

Options
Customizes the location of columns for some tables.

Reporting
Sets the location of .adm files used for reporting. The default search path for .adm files is the system folder and then the SYSVOL folder of the GPO. You can, however, override this option to provide a custom location.

General
Enables or disables several options:

Enable or disable trust detectionBy default, a two-way trust with a forest is required to add the forest to GPMC. You can remove this distinction, allow connection, and work with a one-way forest-trust, or use the Stored User Names and Passwords feature for Windows XP and Windows Server 2003 to enable access to untrusted forests.

Enable or disable confirmation of GPO or GPO link distinction.

Display domain controller name beside domain name.

Basic Operations

Creating, editing, testing, protecting, reporting, backup/restore, and copy/paste are all basic Group Policy management processes available via GPMC. Other operations, such as setting the DC to use for Group Policy, can also be managed from the console.

Setting the DC to Use for Group Policy Development

By default, GPMC, like its predecessor the Group Policy Editor, will default to using the primary domain controller emulator DC in the domain to access Group Policy information. It is possible to use another DC as the location for storage of the GPO, but arbitrary DC selection is not a good idea. A policy should be established that selects and maintains a specific DC as the GPO location for all GPOs that can be created by the same group of administrators. If Group Policy management is delegated and distributed, such as on an OU-by-OU basis, then selection of a single DC is of less importance. The reason for limiting the DCs is that the use of multiple DCs can cause issues due to replication. If two different administrators are editing the same GPO, but on different DCs, what will be the result? It is possible that the GPOs will become out of synch, or that policy written by one administrator will be overwritten by another. The end result is that policy may be different than intended. Good reasons for using multiple DCs are as follows:

The administrator in charge of Group Policy for a specific domain, OU, or site is not physically present in the location where the default or preselected GPO management DC resides. In this case, a WAN connection would be required for him to modify GPOs. To avoid this, a local DC can be selected for his use. Administrators at other physical locations should not select different DCs if they also are privileged to modify Group Policy for that domain.

If the majority of the users and computers affected by the policy are in a location different from the default DC used for GPO management, a DC at their location as the configuration point for modification of GPOs that affect them may be a good choice. If it is, replication latency will be less of a factor for these users. Because policy is available locally, users will be more likely to quickly receive policy changes. This can be especially important if the changes are to security settings.

Management of Group Policy is delegated and distributed. In this case, all domain-linked GPOs are created and managed on a single DC, but GPOs linked to a specific OU may be created on different DCs. Again, the arbitrary selection of a new DC for each OU would be pointless. However, there may be reasons, such as the two preceding examples, that would make this desirable. It may also be used when it is desirable to limit administrative access to specific domain controllers; in this case, ensuring that administrative authority does not extend to other DCs can be accomplished by allowing the management of GPOs on a DC. However, you should be cautious in deploying this solution because any administrative function that can modify replicated data on a single DC will in essence modify all other DCs due to replication. In addition, if not done carefully, restricting access to specific DCs can cause issues for users in normal day-to-day operations.

To select the domain controller to use:

Open GPMC, right-click the domain, and select Change Domain Controller from the context menu.

Right-click the site to set the domain controller to be used for site policies.

In the Change Domain Controller dialog box, as shown in Figure 7-39, select from the following choices:

The domain controller with the Operations Master token for the PDC emulator
The default.

Figure 7-39. A DC can be specified for use to modify a GPO.

Any available domain controller
The first domain controller that responds to GPMC will be used.

Any available domain controller running Windows Server 2003 or later
This is important if you want to do Group Policy modeling.

This domain controller
Select a specific DC from the provided list. If selecting a domain controller to be used for a site GPO, you can also select which domain the DC should be from.

NOTE: Site GPO Storage

Because a site can contain domain controllers from many domains, which DC will be used to store a site GPO? By default, the PDC emulator in the domain of the administrator who created it is used. With GPMC, you can select the domain controller to be used for this purpose.

Creating a GPO Using GPMC

A GPO can be created using GPMC in several ways. Once the GPO is created, the Group Policy Object Editor is used to define the settings for that GPO. The GPE tool is the same tool used in Windows 2000 and in Windows Server 2003 prior to installing GPMC.

The choices for creating a GPO using GPMC are as follows:

Right-click on any domain or OU and choose Create and Link a GPO here from the context menu. This operation creates the GPO and links it to the domain or OU selected.

Use a script.

Right-click the Group Policy Objects node in any domain and click New. A new, unlinked GPO is created.

To edit the settings in any GPO, right-click the GPO and select Edit.

Scoping GPOs

Determining and assigning the computer and user accounts that will be impacted by a GPO is called scoping the GPO. To scope a GPO, follow these steps:

Link the GPO to a domain, site, or OU by doing one of the following:

Create a GPO by right-clicking on a SOM and choosing Create and Link a GPO here.

Link an existing GPO to a SOM by right-clicking the site, domain, or OU node and choosing Link an existing GPO here. (This is like choosing the Add button in the Group Policy user interface prior to installing GPMC.)

Drag a GPO from the Group Policy Object node to an OU in the same domain.

Use security filtering on the GPO. Prior to GPMC, this required using the ACL editor to set the Read and Apply Group Policy permissions for specific users and groups. With GPMC, the user or group is added to the Scope tab for the GPO or GPO link. This automatically sets the Read Group Policy permission. However, should you want to deny these permissions, you must use the ACL editor.

Use a WMI filter on the GPO. WMI filters dynamically determine the scope of GPOs based on attributes. The scope of a GPO consists of the users and computers it will be applied to. WMI client-side support is only available for Windows XP Professional and Windows Server 2003. (Windows 2000 will ignore WMI filters.) The filter is always evaluated on the client computer. This means that each client computer will examine the WMI filter to see if it applies. Be sparing with the application of WMI filters because they can mean extended processing time.

GPMC Reporting

Documenting a GPO without GPMC is a tedious manual chore. GPMC provides extensive HTML reporting. Reports can be viewed and printed. Representative reports are as follows:

Settings in GPOClick the Settings tab of the GPO or GPO link pane to produce a report like the one shown in Figure 7-40.

Figure 7-40. Use the show all link to see all settings in the GPO, or only view selected areas. Only those settings that are configured will display.

[View full size image]

Group Policy Modeling (RSoP planning)

Group Policy Results (RSoP logging)

When RSoP logging is performed, some settings may not be displayed. Microsoft lists the following items:

IE Maintenance section; does not include the details of Content Ratings

IE Settings in Preference mode

Some cookie settings

Customized Java settings in Zones and Privacy

Some details for Wireless and IPSec settings

To save a report, right-click on the SOM and select Save Report (or select Save Report from the Action menu), name the report, and then save it as an XML or HTML file. The report can then be printed after opening the file.

Reports, as shown in Figure 7-41, are automatically displayed in a condensed fashion and only show areas where settings are established. This simplifies their viewing. To examine the settings, you need only expand the appropriate category. To expand all of the settings, you can use the show all option at the top of the report. In the Administrative templates portion of the report, additional meaning, the "Explain" information, can be viewed by clicking the setting name, as shown in Figure 7-42.

Figure 7-41. A full report of the GPO settings can be produced by clicking the Settings tab.

[View full size image]

Figure 7-42. Administrative Template settings can display the "Explain" information.

[View full size image]

Using GPMC to Ensure Group Policy Permission Consistency

When permissions are modified on a GPO using GPE or GPMC, they are modified on both the GPO information in AD and in sysvol. Permissions can also be set outside of these interfaces, so it is possible for them to become out of synch. Permissions settings in both areas must be the same, or policies will not be properly processed. GPMC checks permission consistency in Windows Server 2003 domains when the GPO is selected. If there is a problem, a dialog box warning appears that, if the user is authorized, allows the user to click OK and fix the sysvol permissions to be the same as those in Active Directory.

Windows 2000 domain GPOs can be checked for this issue by looking at the Default Domain Policy and the Default Domain Controllers Policy from the GPMC. There actually is a bug in Windows 2000 with respect to this issue. The ACLs on the sysvol portion of the GPO are set to allow inheritance, but they should not be. Because of this, the permissions can easily be out of synch with the permissions set in the Active Directory. To correct the error, examine the GPOs in GPMC and when prompted to click OK to make the permissions match, do so. The permissions will be synched with the ACLs on the Active Directory portion of the GPO, and the allow inheritance feature will be removed.

Backup and Restore

When Backup is selected from the context menu, a copy of the GPO is made to the file system. Backup also serves as the export function for the GPO. A GPO backup can be used with either the restore or import function. The backup includes each of the following:

The GPO GUID and domain name

The GPO settings

WMI filter links (not the filter itself)

Permissions settings on the GPO

An XML report of the GPO settings

Backup does not include items that are not stored outside the GPO. (Only items that are stored in sysvol or AD portions of the GPO are backed up.) The following items, which many think are part of the GPO, are not stored with the GPO and thus are not backed up:

WMI filters. (These can be backed up separately using GPMC.)

IPSec Policies. (Export to a file from the IP Security Policy snap-in.)

Links from the SOM to the GPO.

WARNING: Backups Create New Security Issues

Being able to back up a GPO allows the restoration of an Active Directory Group Policy environment. However, anyone who can access the backup, copied, or exported GPOs has a large amount of information about the security configuration of the enterprise. This is not information that should be exposed. Only authorized administrators, security teams, and auditors should have access to this information. The location and the DACLs set on the files are critical. GPO backups should be treated as carefully, if not more carefully than, other backups. On- and off-site storage locations are important. In addition to providing an attacker with security information, a backup might be used in an attack. Older, incorrect GPOs might be restored in place of the correct versions, thus weakening security. Ensure that access to these files is limited and that access to all GPMC operations is limited to those trusted individuals who are authorized to perform them.

Restore takes a backup and puts it back in the domain just the way it was when it was backed up. The GUID of the original GPO is used, as is the domain information. You cannot use a backup and restore to move a GPO to another domain. The restore replaces the GOP setting, the ACLs on the GPO, and the WMI filter links.

To back up a GPO, follow these steps:

Right-click on the GPO in GPMC and select Backup from the context menu.

Provide a file system location, name of file, and description, and then click Back Up, as shown in Figure 7-43.

Figure 7-43. GPOs may be saved to the file system. Make sure this is done to a secure locationnot somewhere where unauthorized individuals can access the file.

Click OK.

To back up all GPOs, follow these steps:

Right-click on the Group Policy Objects node and select Backup All from the context menu.

Provide a file system location and description.

Click Back Up; then click OK.

Rapid Adoption Is Not the Best Policy

Shortly after the introduction of the GPMC, many companies downloaded the tool and immediately put it to use without thoroughly understanding it. Sound familiar? Like any new tool, you should always use GPMC first in a test environment, read all the documentation, and note any inconsistencies, warnings, and unique issues. If White Star Electronics had done so, it might not have spent hours troubleshooting GPO restore issues.Chapter 9). To restore a GPO that has been deleted, use the Manage Backups dialog box as described in the next section, "Managing Backups."

A GPO that is backed up prior to a domain rename cannot be restored. Make sure you do a new backup of GPOs immediately after a domain rename.

To restore a GPO that still exists, follow these steps:

Right-click on the GPO in the Group Policy Objects container and select Restore from Backup from the context menu.

In the Restore Group Policy Object Wizard Welcome page, click Next.

Enter or browse to the GPO location and click Next.

Select the backup and then click Next.

Review the settings and click Finish.

Click OK.

Sample scripts that perform basic functions are provided with GPMC. To back up, use the provided script BackupGPO.wsf or BackupAllGPOs.wsf. To restore a GPO(s), use the example scripts RestoreGPO.wsf or RestoreAllGPO.wsf. Information about GPO backups can be found by using the QueryBackuplocation.wsf script.

Managing Backups

Information on backups, and the ability to delete, organize (sort), restore, and view backup settings, is located in the Manage Backups dialog box.

To access the Manage Backups page:

Right-click on the Domains container and select Manage Backups from the context menu.

Right-click on the Group Policy Objects container and select Manage Backups from the context menu.

Enter or use the Browse button to locate and select the file location of the backups and click OK.

Import

A backed up GPO can be imported to an existing GPO. Import can be used to restore a GPO or to completely replace the existing settings in a GPO with the settings in the backup GPO. Import can be used to move GPO settings from one domain to another, even if the new domain is in another forest, and even if there is no trust relationship between the original and destination domain.

To import a GPO, right-click the GPO under the Group Policy Objects node and follow the wizard.

Copy

The GPO copy process uses an existing GPO to obtain settings, which it then transfers to a new GPO in a new domain. (If the copy function is used in the same domain, it will link the GPO to the new SOM instead of producing a new GPO.) Copying a GPO is like copying a file to a new location. In the file copy process, the original file still exists, and a new file is created. In the GPO copy process, the copied GPO still exits unmodified, and a new GPO with the same settings is created at the new location. No intermediate step, such as placing a backup of the GPO in the file system, is performed. To copy a GPO, creation rights in the destination domain and read access to the source GPO are required. Trust is required between the source and destination domains.

Practical Copy and Migrate Scenarios

As wonderful as the ability to back up and restore GPOs or duplicate a GPO in a new OU within the domain is, even more powerful is the ability to migrate policy to a new domain and forest. In addition, you can reproduce exactly the entire GPO structure in a test environment or rebuild your current structure in the event of cataclysmic disaster. Both of these scenarios will be discussed in Chapter 8.

Delegating Group Policy

Group Policy changes can either increase or decrease the security level of every computer in the forest. Therefore, creation of GPOs and their management is by default restricted to the Group Policy Creator Owners group. Members of this group can create and manage Group Policy. However, the ability to delegate some of the workload of Group Policy is an intrinsic part of proper Group Policy Management. Like many administrative privileges, Group Policy management can be assigned in a granular fashion. Authority can be given at a specific domain or OU level, and authority does not have to be carte blanche. The privileges of creating, editing, linking, and performing modeling or results analysis in addition to creating or editing WMI filters GPOs can be granted or denied separately. You can design a Group Policy delegation strategy that includes security to meets your needs.

Using GPMC to Obtain RSoP

Using GPMC to produce RSoP is also easier than doing so with the RSoP tool. GPMC can be used to obtain planning and logging data.

GPMC can be used by a user with read privileges to produce a report on the settings in the GPO. Prior to GPMC, a report could only be viewed by examining the GPO in the Group Policy Editor; however, this required read and write permissions. Auditors do not need write permissions and in fact eschew them. With write permissions, an auditor could modify the very information she is charged with providing an analysis of, which would be a conflict of interest and a violation of the separation of duties security principle.

GPO Delegation

The Group Policy Objects Delegation tab displays all users and groups that can create GPOs in the domain. Three privileges can be granted at the SOM level:

Linking
Use the Delegation tab of the SOM.

Group Policy Modeling (available only to domain admins by default)
In a Windows Server 2003 schema forest, this can be delegated from GPMC using the Delegation tab of a domain or OU. The privilege is called "Perform Group Policy Modeling Analyses" and can be found on the Permissions drop-down box of the Delegation tab on the SOM.

Group Policy Results
A permission normally only granted to members of the local Administrators group or the local administrator of the target computer. The permission is also referred to as the Generate Resultant Set of Policy (Logging) permission.

To delegate creation of WMI filters, use the Delegation tab of the WMI Filters pane. WMI filters are stored in the domain's system container in AD, so permissions applied to this container can also delegate the same rights. Two possible permissions are available: Creator Owner (can create new WMI filters, but has no access to WMI filters created by othersby default, members of Group Policy Creator Owners), and Full Control (by default, domain admins and enterprise adminscan create own and full control on all WMI filters in the domain). You can also apply permissions to a specific WMI filter, either Edit or Full Control. All users have, by default, read permission to all WMI filters. This is necessary to allow Group Policy processing on the client and cannot be removed.

To manage delegation for a GPO, use the Delegation tab of the GPO, as shown in Figure 7-44, or permissions directly on the GPO. These privileges are more granular and include the following:

Read
Read the GPO

Edit settings
Read, write, create child objects, delete child objects

Edit, delete, and modify security
Read, write and create child objects, delete child objects, delete, modify permissions and modify owner (apply group policy right is not set)

Read as used in security filtering
Displayed but cannot be set from GPMC

Custom
Displayed but cannot be set from GPMC; combinations of rights such as deny

Figure 7-44. For each GPO, specific rights can be delegated.

[View full size image]

Deny can be set using GPMC, but you must use the Advanced tab.

GPO Planning and Analysis Modeling

Implementation of an extensive Group Policy design is a daunting task. The more computers and users that must be managed, and the more diverse the roles are that they play, the harder it is to keep track of the hundreds of settings and multiple GPOs that are implemented. It is also difficult to design a GPO strategy for a large enterprise. Windows Server 2003 introduced the MMC snap-in RSoP, which can be used in both logging and planning mode.

GPMC provides an interface to this process. Group Policy Modeling can be used to plan and design a GPO hierarchy and see what the results will be. Group Policy Results allow the administrator to examine the current GPO structure and determine what its impact is on a specific user or computer. In a Windows 2000 forest, no Group Policy Modeling node exists.

Modeling a Group Policy Hierarchy

GPMC provides the ability to simulate policy deployment. No GPOs are actually applied, but the results of applying the GPOs can be determined. Known as Resultant Set of Policy (RSoP) Planning Mode in Windows Server 2003, Group Policy Modeling, as it's called in GPMC, requires a domain controller that is running Windows Server 2003 in the forest, but it can simulate a resultant set of policy for any Windows 2000, Windows XP Professional, or Windows Server 2003 computer in the forest. A special service, Resultant Set of Policy Provider, runs on the Windows Server 2003 computer and must be enabled for the process to work. In Figure 7-45, Group Policy Modeling is selected, and you can see in the details pane queries that have already been performed.

Figure 7-45. Previous queries are displayed and can be accessed from the Group Policy Modeling node.

[View full size image]

To do Group Policy modeling, you must create GPOs. You can provide a test forest (best practice), provide a test domain, or do modeling by creating empty OUs. In each case, you do not populate the OUs or domain with real user or real computer accounts. It is enough to use dummy accounts. In a large environment, you can do much modeling on a single test domain controller in its own test forest.

To model Group Policy, follow these steps:

Right-click the Group Policy Modeling container and select Group Policy Modeling from the context menu. (You can also open the wizard directly from a SOM, and the wizard will pre populate the User and Computer Selection page of the wizard.)

On the Group Policy Modeling Wizard welcome page, click Next.

Select a domain controller to process the simulation.

Enter or browse to the container to be used for user information.

Enter or browse to the container to be used for computer information, and then click Next.

Continue the wizard as listed in the RSoP section.

The report is displayed in the details pane.

The report summary tab displays information that impacts the results, including these:

A list of GPOs that will be applied

Security group members affected

WMI filters that are applied

The settings configured during modeling

The Settings tab displays the settings that will be applied, and the Query tab displays the parameters used to create the query. The results of the query are available for later review, or the query can be re-run after changes in the GPOs have been made. You must delete any queries that are no longer needed.

To save a copy of the report to the file system, follow these steps:

Right-click on the query in the details pane and select Save from the context menu.

Enter or browse to a location and enter a filename; then click Save.

The GPMC tool provides HTML reporting of the results but does not provide the precedence information provided by the RSoP MMC snap-in. The HTML report tells you the final resultwhat setting will be applied. The precedence information in the RSoP MMC snap-in shows where all settings are coming from. The Advanced View option (right-click on the query in the console pane and select Advanced View) will open the RSoP MMC snap-in and provide information on every GPO that attempts to set the setting and what it would have set the setting to.

Determining the Results of Group Policy Implementation

The Group Policy Results node of the GPMC can be used to analyze the exact security configuration for users and computers in a production environment. The analysis, the resultant set of policy logging mode, is useful for confirmation of expected results, troubleshooting issues of policy application, and auditing security implementation against official policy for compliance. The data is especially important because it is not simulated on the DC but rather calculated at the target computer. However, the client must be running Windows XP or Windows Server 2003. GPMC cannot be used to get Group Policy Results data for a Windows 2000 computer. Using the logging tool is similar to using the RSoP console and the Group Policy Modeling tool in the GPMC.