Designing, Deploying, and Tracking Group Policy Controls

One of the most important considerations when designing GPOs is efficiency. You want to define and link the minimum number of GPOs to satisfy your security policy. Creating too many GPOs will increase the time and effort you’ll need to administer and maintain your security policy. Having too many GPOs also increases the possibility of errors and opportunities for attackers to compromise your systems. The simplest environment would be one in which you define one set of GPOs that applies to all computers and all users in all domains. Unfortunately, few environments end up being that simple. Functional demands often require different controls for various computers and users.

GPO Application Order

You can define several layers of GPOs that work together to ensure you enforce your security policy for all computers and all users. Windows gives you the ability to create high-level GPOs that enforce large-scale security settings and more specific GPOs that allow you to fine-tune settings for specific situations. Recall from earlier in this chapter that Windows applies GPOs in a specific order. Knowing this order lets you put more generic settings in GPOs that Windows applies first, and more specific settings in GPOs that Windows applies later in the process.

Recall that Windows applies GPOs in this order:

  • Local GPOs—GPOs defined and stored on the local computer

  • Site GPOs defined in AD—GPOs defined in AD for a specific site

  • Domain GPOs—Domain-wide GPOs defined in AD

  • Organizational unit GPOs—OU GPOs defined in AD

Design your GPOs with this order in mind. Since Windows applies OU GPOs last, any global GPO settings should go here. Identify any settings you want to enforce for all computers and users and define GPOs that you link to one or more OUs. Then, you can define GPOs and link them to lower-level containers for settings that do not apply to all computers or users. Since OU GPOs have the largest scope, they are the easiest to implement and maintain. Start by reviewing your OU structure. You should ensure your OU structure realistically represents your functional organizational structure as closely as possible. OU designs that closely represent functional structures make it easier to create appropriate OU-level GPOs that satisfy your security policy. For example, suppose your security policy requires specific application and object access for members of the Human Resources (HR) Department. If you define all users in the HR Department in the HR OU, it is easy to create GPOs for the OU that affect all HR Department users.

All security control design starts with your security policy. Once you validate your OU design and identify the controls you’ll need to satisfy your security policy, you can define the control scope. In the context of GPO settings, the scope of any control is the group of computers or users to which each GPO applies. Settings scoped to the OU level should exist in OU GPOs. You can define any settings that apply only to some computers or users in local, site, or domain GPOs. You can also define limited scope GPOs at the OU level and use filters to limit the scope. You’ll learn about GPO filters later in this chapter. As a general rule, define GPO settings either at the lowest level that includes all of the desired computers and users or at the OU level using filters when the OU approach meets your needs. For example, you can define any settings that apply to all users for a specific computer in either a local GPO, site GPO, or a filtered OU GPO. The main difference is that Windows stores local GPOs on the affected computer and stores site and OU GPOs in AD. OU GPOs also make administration simpler since you define and link GPOs at a single level.

Security Filters

Windows applies GPOs to all computers and users in a container by default. That means all computers and users in an OU will inherit any OU GPOs defined for that OU by default. You can change that behavior with security filters (FIGURE 6-9) if you want an OU GPO to apply only to some computers or users in the OU. The GPMC allows you to add as many security filters for GPOs as necessary to satisfy your security policy. You can limit a GPO to users, groups, or computers. Once you define a security filter, Windows will apply that GPO only to subjects defined in the filter. This option gives you much more control over how Windows applies GPOs you define at the OU level.

Group Policy Management window with security filtering options is shown.

FIGURE 6-9
GPO security filters.

Courtesy of Microsoft Corporation.

GPO Windows Management Instrumentation Filters

Windows Management Instrumentation (WMI) is the infrastructure Windows uses to maintain and exchange management and operations data. WMI filters give you even more control over when and where GPOs apply. You can create multiple WMI filters for each domain and then, link each filter to one or more GPOs. You can link only one WMI filter to each GPO. Windows evaluates the GPO’s WMI filter before applying a GPO and proceeds only if the WMI filter expression evaluates to TRUE. WMI filters allow you to query the target environment and apply security settings only in certain situations.

For example, suppose you want to apply a GPO only for computers that are running Microsoft Windows Vista Ultimate. You could define a WMI filter that would restrict the GPO to the desired machines. Windows uses the WMI Query Language (WQL) to define the queries for the filters. WQL is a subset of the SQL language many database engines use to query data. The following WQL query will return TRUE when the target computer is running Microsoft Windows 8.1 Pro:

Select * from Win32_OperatingSystem where Caption = Microsoft Windows 8.1 Pro.

If the target computer is running Microsoft Windows 8.1 Pro, Windows will apply the GPO. This additional feature gives administrators the ability to define GPO scope at a very specific level of detail. Once you define the WMI filter in the GPMC, you can link the filter to any GPO by just selecting the desired WMI filter from the drop-down list in the GPO’s WMI Filtering section (FIGURE 6-10).

Group Policy Management window with WIMI filter options is shown.

FIGURE 6-10
WMI filters.

Courtesy of Microsoft Corporation.

Deploying Group Policy

Windows ensures that new and changed GPOs get distributed and applied every 90–120 minutes. In some cases, you may want to force GPO distribution. In Windows Server 2012 and newer, you can force a GPO refresh from within the GPMC. For all versions of Windows, you can use the Group Policy Update tool to accomplish this task. The tool also provides the ability to force user logoff or system boot when setting changes require these actions. You can use the Group Policy Update tool whenever you want to ensure that settings are in place on target computers.

Follow these steps to run the Group Policy Update tool:

  1. Open a PowerShell window—Choose the Windows Start button > type powershell.exe.

  2. Enter the following command: gpupdate.exe.

The Group Policy Update tool supports several options that change the scope of targets or additional actions. TABLE 6-2 lists the most common options for gpupdate.exe.

TABLE 6-2 Gpupdate.exe Options

OPTION DESCRIPTION
/target:{Computer | User} Limits the target of the update to only user or computer policy settings.
/force Reapplies all settings. The default is to apply only new or changed settings.
/wait:value Sets wait time for the specified number of seconds for the processing to finish. A value of −1 means wait forever.
/logoff Forces a user logoff after the update processing completes.
/boot Forces a system reboot after the update processing completes.
/sync Synchronously applies the next logoff or boot policy setting.

© Jones & Bartlett Learning.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.142.171.253