Altering Group Policy Application

When you create Group Policy structure in your organization, you might need to alter the default processing of GPOs. Group Policy provides four options for doing this:

Block Inheritance
No Override
Group Policy Object Filtering
Loopback Mode Processing

Block Inheritance

You might have a situation in which a subcontainer such as an OU should not receive GPOs from parent objects. For example, suppose you have configured a GPO and linked it to the domain container, thus applying it to all computers. But what if you want to ensure that computers in a specific OU containing computers do not inherit the domain Group Policy settings? In this case, you can implement Block Inheritance on the OU container, which will prevent all GPOs from the parent container from being processed, and therefore, from being applied to the computer or user. Note that you cannot block the inheritance of individual GPOs with this setting. Blocking inheritance will block all GPOs from a higher level in the processing hierarchy.

No Override

You might be the administrator of GPOs linked to the domain and need to ensure that certain policies are applied, even if an OU has the Block Inheritance option configured or a GPO configured with an opposite or conflicting setting. In this case, you can mark the individual GPO as No Override . A GPO with the No Override option set on a parent object will be applied even if the Block Inheritance option is configured on the child object. Unlike Block Inheritance, No Override is specified on individual GPOs.

Group Policy Object Filtering

When a Group Policy object is applied to a container, it applies to all computer and user objects in the container and all subcontainers. You might need to have some computers or users exempted by the GPO. Rather than create a special container and use a series of No Override and Block Inheritance restrictions, you can filter Group Policy by using the DACLs on the GPO.

You can view and modify the security settings from the Security tab on the Properties page of the specific GPO. The Security tab for a GPO is accessible by right-clicking the root node in the Group Policy snap-in, clicking Properties, and then clicking Security. Alternately, from the Properties page of a given site, domain, or OU, you can select the Group Policy tab, right-click the appropriate GPO in the Group Policy Object list, select Properties, and then click Security.

For the GPO to be applied to a computer or user, the computer and user objects in Active Directory must have both Read and Apply Group Policy permissions on the GPO. By default, members of the Authenticated Users group are granted both Apply Group Policy and Read permissions. Computer and user accounts automatically receive membership in the Authenticated Users group after the successful validation of their credentials, which occurs before Group Policy is processed. Therefore, the default behavior is for every GPO to apply to Authenticated Users. By default, domain administrators, enterprise administrators, and the local system have Full Control permissions, without the Apply Group Policy access control entry (ACE). However, administrators are members of Authenticated Users, which means that they will receive the settings in the GPO by default.

Preventing Group Policy from applying to a specified group requires removal of the Apply Group Policy ACE from that group. If you remove the Apply Group Policy ACE (clear the Allow check box) for Authenticated Users, you can explicitly grant this permission to individual security groups that should receive the policy settings. Alternatively, you could set Apply Group Policy to Deny for certain security groups that should not have the policy applied. Because an explicit deny permission always overrides an allow permission, the computer or user accounts on the security group will not process the GPO.

Group Policy administrators also need the Read permission to manage the GPO. Use caution when altering the default assignment of Read for the Authenticated Users group.

Loopback Mode Processing

Another scenario in which you might need to alter the default processing of Group Policy is when you have computer and user object in different containers in Active Directory. The OU that holds the user object has restrictive GPO settings activated, such as preventing users from altering network settings, removing Control Panel applets, and preventing certain applications from running. When a user logs on to her workstation, the GPO policies act to protect the network and standardize the desktop configuration; however, the user can also manage a Windows 2000 file and print server. When the user logs on to the server, the Group Policy settings prevent her from completing the management task she is required to do. Rather than create a separate account for the user to use when managing the server, you can implement Group Policy loopback mode.

Group Policy loopback mode is itself a Group Policy setting that you can enable in the Computer Configuration section of Group Policy. Group Policy loopback mode has two settings:

Replace
When you enable Group Policy loopback mode using this setting, the GPO that applies to the user object will not be processed. Hence, the only settings that apply to the logon session are computer-related Group Policy settings. This setting is commonly used to resolve the scenario just described.
Merge
When you use this setting, user configuration settings from the computer object location will be applied after the user configuration settings from the location of the user object. This results in the computer location s user settings combining with the user location s user settings and overriding them in the event of conflicts.

You can set the Group Policy loopback mode by enabling User Group Policy Loopback Processing Mode policy in the Computer Configuration section of Group Policy\Administrative settings\System\Group Policy.