Lesson 1: Planning Deployment of Group Policy

When designing Group Policy for an organization, consider the default inheritance model to ensure that you take full advantage of Group Policy inheritance. In certain circumstances you may want to deviate from the default behavior by implementing Block Policy Inheritance or the No Override attribute.


After this lesson, you will be able to

  • Plan the deployment of Group Policy objects in Active Directory

Estimated lesson time: 30 minutes


Group Policy Overview

Group Policy allows centralized control of user and computer configuration settings. Rather than applying security settings at each computer in an organization, Group Policy uses Active Directory to centralize management and standardize security settings.

NOTE


For more information on how Group Policy works within a Windows 2000 network, see the white papers "Introduction to Group Policy" and "Windows 2000 Group Policy" on the Supplemental Course Materials CD-ROM (\chapt07\Group Policy Introduction.doc and \chapt07\Group Policy White Paper.doc) that accompanies this book.

Planning Group Policy Inheritance

Inheritance simplifies Group Policy administration by allowing administrators to apply widespread policy settings only to higher-level OUs. You can apply Group Policy at different levels within Active Directory by defining Group Policy objects that are linked to sites, domains, or OUs. The Group Policy is applied to all computer or user objects within the container where you define the Group Policy object.

If you define Group Policy using the default inheritance model; Group Policies are applied in the order shown in Figure 7.4.

click to view at full size.

Figure 7.4 Group Policy application order

  1. Local Group Policies. If you apply local Group Policies first, centralized Group Policy settings always take precedence, since they are applied later.
  2. Site Group Policies. In general, don't define site Group Policies. The reason you shouldn't is because they're stored in the system volume of the DCs in the domain where the site Group Policy was defined. If you define a site Group Policy, the Windows 2000 client must connect to a DC where the site Group Policy was defined in order to download the Group Policy. If the DCs aren't located at the local site, logon times might be slow.
  3. Domain Group Policies. Domain Group Policies are often used to define standard settings that apply to all computers in the domain. For example, account policy settings are domain-level settings that must be defined at the domain.

    NOTE


    For more information on account policies and their effect on designing domain structures, see Chapter 2, "Designing Active Directory for Security."

  4. OU Group Policies. The effective range of OU Group Policies is greater when you apply them higher up the OU structure. Group Policy settings that affect a larger number of computers or users are applied at top-level OUs.
  5. Sub-OU Group Policies. You apply sub-OU Group Policies last. In general, the lower in the OU structure, the more specific the Group Policy settings will be, as the Group Policy settings will affect a smaller number of users or computer objects.

The effective permissions for a computer or user are based on the preceding inheritance model. If you apply different settings, the settings you apply to an OU where the user or computer object is located typically take precedence.

Assessing Group Policy Application

When you design Group Policy, make sure that your design meets security requirements without significantly affecting logon performance. Use the following design strategies to optimize the application of Group Policy:

  • Disable unused portions of Group Policy. If the Group Policy object defines only computer settings, disable the user portion of Group Policy to ensure that the user settings aren't processed, as shown in Figure 7.5. Disabling the unused portions of Group Policy results in faster processing of the Group Policy object.

    Figure 7.5 Preventing user Group Policy application

  • Minimize the levels at which you apply Group Policy. The more Group Policies that you apply to a user or computer, the slower the logon process will be. If you apply a Group Policy at each level of the OU structure, the logon time increases as each of the Group Policies is processed.

    NOTE


    A common misconception is that the number of OU levels affects logon performance. In fact, logon performance is affected by the number of levels at which Group Policy is applied.

  • Avoid cross-domain Group Policy object assignments. If you define the Group Policy in a different domain, the user or computer must contact a domain controller from the domain containing the Group Policy object. If the domain is accessible only over a slow WAN link, logon performance suffers.

Block Policy Inheritance

Sometimes you don't want to apply a Group Policy that was defined at a higher-level OU. For example, a policy that enables the auditing of directory service access at a parent OU may not be desired for computers located in an OU under the parent OU. In this situation you can use the Block Policy Inheritance attribute to prevent application of the higher-level Group Policies, as shown in Figure 7.6.

Figure 7.6 Configuring the Block Policy Inheritance attribute

Use the Block Policy Inheritance attribute sparingly because it complicates the troubleshooting of Group Policy application problems. In most cases adding new OUs or redesigning your OU structure removes the need to apply Block Policy Inheritance.

Configuring No Override

Sometimes an administrator doesn't want administrators of lower-level OUs to be able to block critical Group Policy settings. For example, if a standard has been developed that all computers in the domain must enable success and failure auditing for account logon events, an administrator could enable the No Override attribute on the Group Policy object so that lower-level OUs can't block inheritance, as shown in Figure 7.7.

Figure 7.7 Configuring the No Override attribute

When you apply the No Override attribute, lower-level Group Policy objects can't override higher-level Group Policy settings. When you configure No Override Group Policies, include only those settings that you specifically wish to prevent Block Policy Inheritance from affecting. Don't include other settings that can be overridden in the Group Policy. A recommended best practice is to create a separate Group Policy object containing only those settings that you wish to apply to all objects within the container structure.

Making the Decision

Use the decision matrix shown in Table 7.1 to assist in designing Group Policy application for your organization.

Table 7.1 Designing Group Policy Application

To Do the Following
Simplify the troubleshooting of Group Policy Allow only default inheritance to take place, rather than implementing Block Policy Inheritance or No Override settings. This action might require extensive reworking of your OU design.
Minimize the time spent processing Group Policy Policy during logon

Minimize the number of levels where Group is applied in the OU structure.

Avoid cross-linking Group Policy objects between domains.

Prevent blocking of key Group Policy settings Break the key settings into a separate Group Policy object and apply the No Override attribute to the Group Policy object.
Prevent users from changing configuration by applying Local Group PoliciesEnsure that important settings are defined in Group Policy. Group Policy settings always take precedence over local Group Policy settings.
Apply central Group Policy that will affect all users Apply the Group Policy object higher in the Active Directory hierarchy. These Group Policy objects are commonly applied at the domain or at a top-level OU.
Apply specific Group Policy to a limited number of computers or usersApply the Group Policy object at the OU where the user or computer objects are located in Active Directory.

Applying the Decision

In the Wide World Importers case study, you've been asked to design a targeted deployment of Office and an accounting software application. Making the following decisions will help you deploy these applications:

  • Create separate Group Policy objects for the engineering.wideworldimporters.tld and wideworldimporters.tld domains. If you define the Group Policy object to install Office in the wideworldimporters.tld domain and then cross-link it to the engineering.wideworldimporters.tld domain, the Engineering department will have slower logons. You will achieve better performance by defining two Group Policy objects, one in the wideworldimporters.tld domain and one in the engineering.wideworldimporters.tld domain.
  • Apply the Group Policy that assigns Office to all employees at the wideworldimporters.tld domain and the engineering.wideworldimporters.tld domain. This ensures that the application is available to all users in each domain.
  • Remove the computer component of the Office installation Group Policy object. You don't need to enable the computer component of the Group Policy object because the application will be user-assigned.
  • Apply the Group Policy object to assign the accounting software at the OU=Computers, OU=Account, OU=cityname, DC=Wideworldimporters, DC=tld containers (where cityname is the name of the city represented by the OU). The Group Policy will be linked to six separate OUs (one for each of the six regional offices).
  • Remove the user component of the accounting software installation Group Policy object. You don't need to enable the user component of the Group Policy object because the application will be computer-assigned.

This Group Policy design ensures that all required computers or users have the necessary software that Group Policy applies. This design also ensures that you don't have to implement the No Override or Block Policy Inheritance settings.

Filtering Group Policy by Using Security Groups

Group Policy isn't applied to security groups. Instead, Group Policy is based on the location of objects within the Active Directory hierarchy. By default, Group Policies apply to all users and computers within a site, domain, or OU.

NOTE


If you want to apply a Group Policy to a user or computer, that user or computer must belong to a security group that has both the Read permission and the Apply Group Policy permission.

You can use security groups to filter Group Policy application so that it applies only to specific users and groups within a given object. When defining a Group Policy object, you can define which security groups will be able to Read and Apply Group Policy. You do this in the Group Policy object's Security tab.

NOTE


A common misconception is that the security group must be located in the OU where the Group Policy is applied. In fact, the security group can exist anywhere in the Active Directory structure.

Another Use for Group Policy Filtering

How can you prevent OU administrators from implementing the Block Policy Inheritance attribute? The following example walks you through an alternate design that you can use.

Figure 7.8 shows a typical Group Policy deployment strategy.

Figure 7.8 A typical strategy for Group Policy deployment

In this case GPO1 is applied at the Dept OU and by default affects both the Sales and Human Resources OUs through Group Policy Inheritance. GPO2 affects only objects in the Sales OU, and GPO3 affects only objects in the Human Resources OU. It's possible that at the Sales OU or at the Human Resources OU an OU Administrator could implement the Block Policy Inheritance attribute. If this happened, the Group Policy settings in the Dept OU wouldn't be applied.

As an alternative, rather than deploying separate OUs for the Sales and Human Resources departments, you could use Group Policy filtering at the Dept OU and remove the need for the separate Sales and Human Resources OUs, as shown in Figure 7.9.

Figure 7.9 An alternate strategy for Group Policy deployment

Rather than creating sub-OUs, you define three separate Group Policy objects at the Dept OU. You then use Group Policy filtering to determine which security groups apply the Group Policy objects. In this example, you apply GPO1 to the Users group. You apply GPO2 only to members of the Sales group and you apply GPO3 only to members of the Human Resources group. This design keeps users who can modify GPO2 and GPO3 from blocking inheritance, since GPO1 is applied at the same OU level.

Making the Decision

Use the design matrix shown in Table 7.2 to design filtering strategies for Group Policy application.

Table 7.2 Designing Group Policy Filtering

To Incorporate the Following into Your Design Plan
Ensure that a Group Policy is applied to a security group Assign both the Read and Apply Group Policy permissions to the security group.
Prevent an OU administrator from blocking inheritance

Don't assign the OU administrator the Write permission for the Group Policy object.

Apply the Group Policy object at the parent OU and filter the Group Policy object so that it's applied to only the computers or users in the child OU.

Prevent application of a Group Policy object to a specific group of users or computers

Create a security group with those users or computers as members.

Assign the security group the Deny permission for Apply Group Policy. This security assignment prevents the Group Policy object from being applied to the security group.

Applying the Decision

You can meet the requirement to install Office software only on the desktop computers of full-time employees by using Group Policy filtering. Include the following procedures in your Group Policy deployment plan:

  • Create two custom domain local groups named FullTimeGP and ContingentGP. Assign Read and Apply Group Policy permissions to these domain local groups. You do this in the Office Group Policy object's Security tab.
  • Create two custom global groups named FullTimeEmployees and ContingentStaff that contain all full-time staff and all contingent staff. You will make these global groups members of the FullTimeGP and ContingentGP domain local groups.
  • Configure the security for the Office Group Policy so that only the FullTimeGP domain local group has Read and Apply Group Policy permissions. This ensures that only the full-time staff has the Office software assigned by using Group Policy.

The network administrators could also configure the Office Group Policy to have the No Override attribute. This would prevent regional office administrators from blocking the installation of Office. Since this isn't a security setting, this option wouldn't be required for the Office Group Policy.

Lesson Summary

Your Group Policy design allows for the default Group Policy object inheritance model. The inheritance model ensures that settings applied higher in the Active Directory hierarchy will be applied to all computers or users lower in the Active Directory hierarchy. The default behavior changes only when you apply the Block Policy Inheritance or No Override attributes.



Microsoft Corporation - MCSE Training Kit (Exam 70-220. Designing Microsoft Windows 2000 Network Security)
MCSE Training Kit (Exam 70-220): Designing Microsoft Windows 2000 Network Security: Designing Microsoft(r) Windows(r) 2000 Network Security (IT-Training Kits)
ISBN: 0735611343
EAN: 2147483647
Year: 2001
Pages: 172

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net