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
Estimated lesson time: 30 minutes
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.
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.
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.
Figure 7.4 Group Policy application order
For more information on account policies and their effect on designing domain structures, see Chapter 2, "Designing Active Directory for Security."
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.
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:
Figure 7.5 Preventing user Group Policy application
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.
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.
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.
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 Policies||Ensure 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 users||Apply the Group Policy object at the OU where the user or computer objects are located in Active Directory.|
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:
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.
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.
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.
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.
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.
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:
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.
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.