GPOs can be linked to sites, domains, and OUs in Active Directory. When you create and link a GPO to one of these containers in Active Directory, the GPO is applied to the user and computer objects in that container according to the inheritance and preference options used by Active Directory. Computer-related policies are processed during startup of the operating system. User-related policies are processed when a user logs on to a computer. Once applied, Group Policy settings are automatically refreshed at a specific interval to ensure they are current. Group Policy settings can also be refreshed manually.
Active Directory uses inheritance to determine how Group Policy is applied. By default, Group Policy settings are inherited from top-level containers by lower-level containers. The order of inheritance goes from the site level to the domain level to the OU level. This means the Group Policy settings for a site are passed down to the domains within the site, and the settings for a domain are passed down to the OUs within that domain.
When multiple group policies are in place, the policies are applied in the following order:
Local group policies Each computer running Windows 2000 or later has one local group policy. The local policy is the first one applied.
Site group policies Policies linked to sites are processed second. If there are multiple site policies, they are processed synchronously in the listed preference order.
Domain group policies Policies linked to domains are processed third. If there are multiple domain policies, they are processed synchronously in the listed preference order.
OU group policies Policies linked to top-level OUs are processed fourth. If there are multiple top-level OU policies, they are processed synchronously in the listed preference order.
Child OU group policies Policies linked to child OUs are processed fifth. If there are multiple child OU policies, they are processed synchronously in the listed preference order. When there are multiple levels of child OUs, policies for higher-level OUs are applied first and policies for the lower-level OUs are applied next.
The order in which policies are applied determines which policy settings take effect if multiple policies modify the same settings. Most policies have three configuration options: Not Configured, Enabled, and Disabled. The default state of most policies is Not Configured, meaning the policy setting is not configured and does not apply. If a policy is set to Enabled, the policy is enforced and does apply to users and computers that are subject to the GPO. If a policy is set to Disabled, the policy is not enforced and does not apply to users and computers that are subject to the GPO.
To override a policy that is enabled in a higher-level container, you can specifically disable it in a lower-level policy. For example, if the user policy Prohibit Access To The Control Panel is enabled for a site, users in the site should not be able to access Control Panel. However, if domain policy specifically disables the user policy Prohibit Access To The Control Panel, users in the domain would be able to access Control Panel. On the other hand, if the domain policy was set to Not Configured, the policy setting would not be modified and would be inherited as normal from the higher-level container.
To override a policy that is disabled in a higher-level container, you can specifically enable it in a lower-level policy. For example, if the user policy Force Classic Control Panel Style is disabled for a domain, users in the domain would be able to choose whether they wanted to use Classic or Simple Control Panel. However, if the Engineering OU policy specifically enables the user policy Force Classic Control Panel Style, users in the Engineering OU would be able to use only the Classic Control Panel style. Again, if the OU policy was set to Not Configured instead, the policy setting would not be modified and would be inherited as normal from the higher-level container.
Because of inheritance, every computer and user object in a domain, no matter which container it is stored in, is affected by Group Policy. Often you'll find that you must modify inheritance to either block inheritance or enforce inheritance.
You block inheritance so that no policy settings from higher-level containers are applied. For example, if you didn't want a domain to inherit the site policy, you could configure the domain to block inheritance from higher-level containers. The way you block inheritance depends on the tool you are using:
In Active Directory Users and Computers, you block inheritance by right-clicking the domain or OU that should not inherit settings from higher-level containers and selecting Properties. In the Group Policy tab of the Properties dialog box, select Block Policy Inheritance, and then click OK.
Using Group Policy Management Console, you block inheritance by right-clicking the domain or OU that should not inherit settings from higher-level containers and selecting Block Inheritance. If Block Inheritance is already selected, selecting it again removes the setting.
Note
When you block inheritance in the Group Policy Management console, a blue circle with an exclamation point is added to the container's node in the console tree. This way you can quickly tell whether any domain or OU has the Block Inheritance setting enabled.
You enforce inheritance to prevent administrators who have been delegated authority over a container from overriding the inherited Group Policy settings. For example, if you want to ensure the domain group policy settings are applied to all OUs, you can do this by enforcing inheritance. Because enforced inheritance cannot be blocked, top-level administrators in an organization can always ensure policy settings are applied as necessary.
The way you enforce inheritance depends on the tool you are using as follows:
In the Group Policy tab, accessed from either Active Directory Users and Computers or Active Directory Sites and Services, you enforce policy inheritance by selecting the policy and then clicking Options. In the Options dialog box, select No Override, and then click OK.
In the Group Policy Management console, you enforce policy inheritance by expanding the container to which the policy is linked, right-clicking the policy, and then selecting Enforced. If Enforced is already selected, selecting it again removes the enforcement.
In the Group Policy Management console, it is easy to tell which policies are inherited and which policies are enforced. This information is displayed automatically in a GPO's Scope tab for all locations to which the GPO is linked (see Figure 38-14). To display similar scope information for any GPO, expand any container to which the policy is linked or the Group Policy Objects node, and then select the policy.
By default, GPOs apply to all users and computers in the container to which the GPO is linked. The GPO applies to all users and computers in this way because of the security settings on the GPO, which specify that Authenticated Users have Read permission as well as Apply Group Policy permission. Thus, all users and computers with accounts in the domain are affected by the policy. Permissions are also assigned to administrators and the operating system. All members of the Enterprise Admins and Domain Admins groups as well as the LocalSystem account have permission to edit GPOs and manage their security.
You can modify which users and computers are affected by a particular group policy by changing the accounts for which the Apply Group Policy permission is set. In this way, you can selectively apply a GPO, which is known is filtering Group Policy. For example, say that you create an Engineering OU with a separate Group Policy for users and managers. You want the user GPO to apply to all users who are members of the EngUsers group and the manager GPO to apply to all users who are members of the EngMgr group. To do this, you must configure the user policy so that the Read and Apply Group Policy permissions apply to the EngUsers group only and configure the manager policy so that the Read and Apply Group Policy permissions apply to the EngMgr group only.
Before you selectively apply a GPO, you must carefully consider the types of policies it sets. If the GPO sets computer policies, you must ensure the computer accounts are included so that the computer reads the GPO and applies it at the startup of networking. If the GPO sets user policies, you must ensure the groups in which the users are members or the individual user accounts are included so that the Group Policy engine reads the GPO and applies it when users log on.
Use the following guidelines to help you determine how permissions should be configured:
Group Policy should be applied to all members of a group Add the group to the access control list (ACL) for the GPO. Set Read to Allow and set Apply Group Policy to Allow. The group policy will then be applied to all members of the group except those who are members of another group to which Read or Apply Group Policy is set to Deny.
Group Policy should not be applied to members of a group Add the group to the ACL for the GPO. Set Read to Deny and set Apply Group Policy to Deny. The group policy will not be applied to any members of the group regardless of which other groups members belong.
Membership in this group should not determine whether Group Policy is applied Remove the group from the ACL for the GPO. Or clear both Allow and Deny for the Read permission as well as the Apply Group Policy permission. Once you do this, membership in the group will determine whether the GPO is applied.
In the Group Policy Management console, you can selectively apply a GPO by completing the following steps:
Select the policy in a container to which it is linked or in the Group Policy Objects node.
In the Details pane, select the Delegation tab, and then click the Advanced button in the lower-right corner of the dialog box. This displays the policy's Security Settings dialog box, as shown in Figure 38-15.
You can then add or remove groups as necessary. Once a group is added, you can select Allow or Deny for the Read and Apply Group Policy permissions as necessary.
When you are finished configuring the ACL for the GPO, click OK until all open dialog boxes are closed.
In Active Directory Users and Computers, you can selectively apply a GPO by completing the following steps:
Right-click the domain or OU, and then select Properties. In the Group Policy tab of the Properties dialog box, click Properties.
In the Security tab, you have options identical to those shown previously in Figure 38-15. You can then add or remove groups as necessary. Once a group is added, you can select Allow or Deny for the Read and Apply Group Policy permissions as necessary.
When you are finished configuring the ACL for the GPO, click OK until all open dialog boxes are closed.
Group Policy settings are divided into two categories:
Computer Configuration settings Policies that apply to computer accounts only
User Configuration settings Policies that apply to user accounts only
Normally, Computer Configuration settings are applied during startup of the operating system and User Configuration settings are applied when a user logs on to a computer. The sequence of events is often important in troubleshooting system behavior. The events that take place during startup and logon are as follows:
When the client computer starts, networking is started as part of the normal system startup. The computer reads the Registry to determine the Active Directory site in which the computer is located. The computer then sends a query to its primary Domain Name System (DNS) server to determine the Internet Protocol (IP) addresses of domain controllers in the site.
When the DNS server replies to the query, the computer connects to a domain controller in the local site. The client computer and domain controller authenticate each other. The client computer then requests a list of all the GPOs that apply to the computer.
The domain controller sends a list of GPOs that apply to the computer. The computer processes and applies the GPOs, starting with the local policy and continuing as discussed in the section entitled "Group Policy Inheritance" earlier in this chapter. It is important to note that only the Computer Configuration settings are sent at this point.
After processing computer policies, the computer runs any startup scripts. Startup scripts are hidden from view by default, and if there are multiple startup scripts, the scripts run in sequential order by default. Each script must finish running before the next one can be started. The default timeout for scripts is 600 seconds. Both the synchronous processing of scripts and their timeout value can be modified using Group Policy.
When a user logs on to the computer and is validated, the computer loads the user profile, and then requests a list of all the GPOs that apply to the user.
The domain controller sends a list of GPOs that apply to the user. The computer processes and applies the GPOs, starting with the local policy and continuing as discussed in the section entitled "Group Policy Inheritance" earlier in this chapter. Although only the User Configuration settings are sent and applied at this point, it is important to note that any computer policy settings that overlap with user policy settings are overwritten by default. User policy settings have precedence by default.
After processing user policies, the computer runs any logon scripts. Logon scripts are hidden from view by default, and if there are multiple startup scripts, the scripts run asynchronously by default. Thus, unlike startup scripts for which each script must finish running before the next one can be started, logon scripts are all started and run simultaneously. The default timeout for scripts is 600 seconds.
The user interface as defined in the user's profile and governed by the policy settings that are in effect is displayed. If the user logs off the computer, any logoff scripts defined for the user are run. If the user shuts down the computer, logoff is part of the shutdown process, so the user is first logged off and any logoff scripts defined for the user are run. Then the computer runs any shutdown scripts defined for the computer.
Inside Out: All Group Policy processing is handled as a refresh
Technically, all Group Policy processing is handled as a Group Policy refresh. Thus, processing during startup and logon is technically a refresh, which is handled as discussed in the section entitled "Modifying Group Policy Refresh" later in this chapter. The most important note about refresh is that if the client computer detects that it is using a slow network connection, only the Security Settings and Administrative Templates are processed. Although there is no way to turn off processing of these extensions, you can configure other extensions so that they are processed even across a slow network connection. For more information, see the section entitled "Modifying Group Policy Refresh" later in this chapter.
You can modify Group Policy processing by disabling a policy in whole or in part. Disabling a policy is useful if you no longer need a policy but might need to use that policy again in the future. Disabling part of a policy is useful so that the policy applies only to either users or computers but not both.
In the Group Policy Management console, you can enable and disable policies partially or entirely by completing the following steps:
Select the policy in a container to which it is linked or in the Group Policy Objects node.
In the right pane, select the Details tab, and then use the GPO Status selection menu to choose a status as one of the following:
In Active Directory Users and Computers, you can enable and disable policies partially or entirely by completing the following steps:
Right-click the domain or OU, and select Properties. In the Group Policy tab of the Properties dialog box, click Properties.
To disable the policy entirely, select the policy, and then click Options. In the Options dialog box, select Disabled, and then click OK. If you later want to enable the policy, you would repeat this process and clear the Disabled option.
To disable the policy partially, select the policy, and then click Properties. In the Properties dialog box, select or clear Disable Computer Configuration Settings and Disable User Configuration Settings as necessary.
When a user logs on, the client computer applies User Configuration settings. Because user policy settings have precedence by default, any computer policy settings that overlap with user policy settings are overwritten. However, for some computers, particularly special-use computers in classrooms, labs, or public places, you might want to restrict the computer to a specific configuration. In this case, you might not want less-restrictive user policy settings to be applied.
To change the default behavior that gives preference to user policy, you can enable the loopback processing policy. By enabling the loopback processing policy, you ensure that the Computer Configuration settings always apply. Loopback processing can be set in one of two ways, either with Replace or Merge. When you use the Replace option, only Computer Configuration settings are processed and User Configuration settings are not processed. When you use the Merge option, Computer Configuration settings are processed first, then User Configuration settings are processed, and then Computer Configuration settings are processed again. This serves to combine the settings and if there are any conflicts in the settings, the Computer Configuration settings have preference and overwrite the User Configuration settings.
To configure loopback processing, follow these steps:
Start the Group Policy Object Editor. In Group Policy Management Console, rightclick the Group Policy you want to modify, and then select Edit.
Double-click the User Group Policy Loopback Processing Mode in the Computer ConfigurationAdministrative TemplatesSystemGroup Policy folder.
Define the policy by selecting Enabled, as shown in Figure 38-16, then use the Mode selection menu to set the processing mode as either Replace or Merge.
Click OK. This policy is supported by all computers running Windows 2000 or later.
