Applying Group Policy

Applying Group Policy

GPOs can be linked to any of the three levels in the Active Directory hierarchy, and the level at which the GPO is linked determines its scope. In other words, where in the hierarchy the GPO is linked determines the number of users and computers that are affected. For example, applying a GPO to a domain affects more users and computers than if it were applied to an OU in the domain. This section examines the effect a GPO has when linked to the three levels in the Active Directory hierarchy. A thorough understanding of this is crucial in determining where to link GPOs.

Where Can Group Policies Be Applied?

To effectively apply Group Policies, you must understand the effect a GPO has when it is applied at a certain level in the Active Directory hierarchy. Linking a Group Policy at the site level has a different effect from applying a Group Policy at the OU level. The needs of the business will determine where in the hierarchy Group Policies should be linked. As already mentioned, GPOs can be linked at three levels: site level, domain level, and OU level (SDOU).

Site Level

The first level at which a GPO can be linked is the site level. If you recall from Chapter 2, "Overview of Active Directory Design Elements," a site is basically a collection of IP subnets. This means that one GPO can be applied to a group of subnets.

A GPO linked at the site level affects all users and computers in those particular IP subnets. You might be asking yourself why you would ever want to link a GPO at this level instead of applying it at the domain or OU level. Linking a GPO at this level allows a business to take advantage of the physical connections (remember the reason these subnets are grouped into a site; refer to Chapter 2 for a review).

To take advantage of the high-speed connections in a site, administrators might choose to create a GPO for publishing applications and apply it at this level. For example, a GPO can be applied to Site A so that users do not have to install applications over a relatively slow WAN link and so that the high-speed connections in the site can be used (see Figure 6.4).

Figure 6.4. A GPO can be linked to the site level to take advantage of the physical links connecting subnets in a site.

Keep in mind that you must be a member of the Enterprise Admins group to link a GPO at the site level.

Performance and security considerations are involved with deploying GPOs linked at the site level. When more than one domain exists in a site, the GPO is created in only one of the domains. When users from one of the other domains in the site log on, the GPO must be retrieved from the domain where the GPO was created. This can cause a performance issue because a cross-domain fetch of the GPO is less efficient than obtaining the GPO in the home domain. Also, administrators in the domain in which the GPO was created usually have the ability to change the GPO, even though they cannot link the GPO to the site. Administrators in the other domain, however, have no control over the GPO and might be concerned that the domain users are affected by GPOs the administrators cannot control. This security- related issue can dissuade you from using site-linked GPOs.

Domain Level

The next level in the Active Directory hierarchy to which a GPO can be linked is the domain level. When a GPO is applied at this level, it affects all the users and computers belonging to that particular domain. If an organization requires all computers in a domain to have the same account policy or lockout policy, a GPO could be linked to the domain level. For example, if the XYZ Corporation applies a GPO to the training.xyz.corp domain, all users and computers belonging to this domain would be affected (see Figure 6.5). However, users and computers in the Consulting domain would not be affected by the policy.

Figure 6.5. Group Policies can be linked at the domain level. A policy can be linked to the Training domain that would not impact any other domains in the organization.

When applying a GPO at this level in the Active Directory hierarchy, you need to be aware of a couple of issues. If you recall from Chapter 5, "Designing Active Directory for Delegation," one of the reasons OUs are created is to delegate control over their contents to another user or group. When a GPO is applied at the domain level, all the OUs in the domain inherit the policy settings. The policy has to be administered at the domain level, and authority over the policy cannot be delegated to administrators responsible for administering the OUs. In other words, to delegate authority, it has to be done at the domain level. The administrators for the various OUs have no administrative control over the policy.

Also keep in mind that, when a policy is linked to a domain that is a parent domain, the child domains are not affected by the policy because the policy is not passed down from parent domain to child domain. If the Training domain is the parent domain to NY and Paris, any policy linked to the Training domain does not affect the users and computers in the two child domains (see Figure 6.6)

Figure 6.6. Policies applied to a parent domain are not applied to child domains.

Domains are security boundaries, so no Group Policy settings are inherited by child domains. Therefore, if you want to create a Group Policy at the domain level, you must link a GPO to each domain in a forest. Likewise, settings from a GPO linked to an OU in a parent domain are not inherited by OUs in a child domain.

If the child domains require the same Group Policy settings, there are two options. The first is to link the GPO to the child domains. The only problem with linking GPOs across domain boundaries is that it increases traffic because the policy has to be retrieved from another domain. This becomes a major concern if the link between the domains is slow. The preferred method, therefore, is to create another GPO with the same settings and apply it to the child domain.

OU Level

The third level at which a GPO can be linked in the Active Directory structure is the OU level. Applying GPOs at this level provides administrators with the most control. Users and computers can be grouped together into an OU, and a GPO can be created and applied to that container.

For example, in the training.xyz.corp domain, mobile computers might require a different security policy than all other computers in the domain. To support this, two separate OUs could be created in the domain and a Group Policy with the required security settings could be applied to each one.

One advantage of linking a GPO at this level is that delegation of authority over the GPO is still possible without giving the user or group privileges throughout the domain. In other words, a user or group can be given the responsibility of administering the Group Policy at the OU level (unlike applying a GPO at the domain level). This enables an organization to maintain its decentralized administrative model.

If you recall from the previous chapter, OUs can be nested; therefore, when linking a GPO at the OU level, careful planning is required. At this level, GPOs are inherited from parent to child (unlike GPOs applied at the domain level). In the Training domain, the Clients and Employees OUs also inherit a GPO that is applied to the TrainUsers OU (see Figure 6.7).

Figure 6.7. Policies applied at the OU level are passed down from parent (TrainUsers) to child (Clients and Employees).

Keep in mind that GPOs do not have to be applied at a single level only; they can be applied at all three levels in the Active Directory hierarchy. It is important to understand how GPOs are processed when multiple policies are applied throughout the hierarchy. The GPO that is processed last overwrites settings applied by the other GPOs. Here are some key points to keep in mind:

• Each computer running Windows 2000 has a GPO that is stored on the local computer (Local Group Policy Object). This is the policy that is processed first.

• Any policies that have been linked to the site level are processed after the local policy.

• GPOs linked to the domain level are processed next.

• The last GPOs to be processed are those linked to the OU level.

If multiple policies are linked at each level, the administrator must specify the order in which they should be processed.

Now that we've covered the various levels at which Group Policies can be applied, let's take a look at some of the issues that need to be considered when planning for Group Policies.