Designing a Strategy for Group Policy Implementation

When designing a strategy for Group Policy, you need to consider several issues. The planning issues that require consideration are the delegation of administration, the application of GPOs (or at what levels of the Active Directory hierarchy), the use of security for filtering, and the modification of inheritance.

Designing the Administration of Group Policy Objects

One of the most important factors to consider when designing a group policy implementation is the delegation of administration. In other words, who will be responsible for administering the various GPOs and what that person's scope of authority will be.

It's important to design the GPOs in a way that enables the current IT organization to manage them easily. Some sort of standard should be set in place so that the creation and organization of GPOs can remain consistent throughout the network. When you design group policies, you need to consider how administration is distributed throughout the network (centralized versus decentralized). You also need to determine who will be responsible for administering the GPOs and the scope of that person's administrative permission.

When organizing GPOs, you have basically three options: single policy, multiple policy, and dedicated policy. Keep in mind that the implementation you choose will affect a number of things, including the maintainability of the GPO, the logon times as Group Policy is processed, and the ability to delegate GPO maintenance tasks.

  • In a single-policy implementation, a separate policy is created for each of the different policy options. Separate group policies could be created for applications settings, security settings, and desktop settings. With this type of implementation, different users or groups can be given authority over different areas of Group Policy. If this type of option were implemented within an organization, several GPOs would be applied to a single organizational unit, and each GPO could have different settings. This implementation would best meet the needs of a business that distributes the administrative tasks among different users or groups (that is, one that has a decentralized administrative model).

  • A second option is to implement a multiple-policy structure. In this type of implementation, one GPO contains all the settings that must be applied to a container. One GPO contains all the application, security, Windows, and administrative settings. This option is best suited to a business that implements a centralized administrative model.

  • A dedicated policy structure contains settings that are divided into two general categories. One GPO would be created to hold the computer settings, and another GPO would contain the user settings.

When designing group policy, also take into consideration which users or groups will be assigned delegation of control over the GPOs and the type of permissions they will require. Will the users or groups be given the right to create new GPOs, modify existing policies, and link policies between sites and domains, or will they be given full control? The type of permissions assigned to users will again be determined by how the business currently distributes administrative tasks.

Administrative tasks for GPOs can be grouped into three different general categories: creating, modifying, and linking. Here are some questions to keep in mind when planning the administration of GPOs:

  • Should the user or group have the ability to create new GPOs (specifying his or her own policy settings) for an organizational unit?

  • Should the user or group have the ability to modify an existing GPO?

  • Should the user or group have the ability to link a GPO to an organizational unit?

Obviously, the permissions that a user is assigned over a GPO determine the scope of that user's administrative control. Remember to follow the principle of least privileges and assign only the necessary permissions for a user or group to carry out a job.

Designing the Deployment Strategy of GPOs

Group policy objects can be linked to any of the three levels within the Active Directory hierarchy. The level at which a 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 by the policy settings. For example, linking a GPO to a domain affects more users and computers than linking it to an OU within the domain.

To deploy group policies effectively, it's important to understand the effect that a GPO has when it is linked to a certain level in the Active Directory hierarchy. Linking a group policy at the site level would have a different effect than linking a group policy at the OU level. The needs of the business will determine where group policies should be linked in the hierarchy.

Site Level

The first level at which a GPO can be linked is the site level. A GPO linked at the site level affects all users and computers within 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 within and between groups of subnets.

To take advantage of the high-speed connections within a site, administrators can choose to create a GPO for publishing applications and link it at this level. For example, a GPO can be linked to specific sites so that users do not have to install applications over a relatively slow WAN link and the high-speed connections within the site can be utilized.

graphics/tip_icon.gif

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


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 linked at this level, it affects all the users and computers that belong to that particular domain. For example, if an organization requires that all computers within a domain have the same specific type of background on their workstations that included the company logo, a GPO could be linked at the domain level.

When applying a GPO at this level in the Active Directory hierarchy, you need to be aware of a couple of issues. One of the reasons that OUs are created is to delegate control over their contents to another user or group. When a GPO is linked at the domain level, all the OUs within 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, the delegation of authority has to be done at the domain level. The administrators of the different OUs will have no administrative control over the policy.

Also keep in mind that when a policy is linked to a parent domain, the child domains are not affected by the policy. Policy settings are not inherited from parent domain to child domain.

graphics/tip_icon.gif

Domains are security boundaries, so no Group Policy settings are inherited by child domains. That means 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 organizational unit in a parent domain are not inherited by the OUs in a child domain.


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

graphics/alert_icon.gif

You can use the Group Policy Management Console to copy or import Group Policy settings.


OU Level

The third level at which a GPO can be linked within the Active Directory structure is the OU level. Linking 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 linked to that OU.

graphics/alert_icon.gif

GPOs cannot be linked to the Users and Computers containers that are created by default when Active Directory is installed. Neither can GPOs be applied at the forest level.


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. This allows an organization to maintain a decentralized administrative model.

Keep in mind that GPOs don't have to be linked at a single level only. They can be linked at all three levels within the Active Directory hierarchy. It's important to understand how GPOs are processed when multiple policies are linked throughout the hierarchy: The GPO that is processed last overwrites settings applied by the other GPOs. Here are some key points to remember:

  • Each computer running Windows Server 2003 (as well as Windows 2000 and Windows XP) has a GPO 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.

graphics/note_icon.gif

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


Other Group Policy Design Issues

By using filtering and inheritance modification, you can change the way in which a GPO is applied. By default, all objects within a container are affected by a group policy that has been applied. However, there might be instances in which not all objects should be affected by the group policy settings. In such cases, filtering can be used. Filtering enables an administrator to exclude certain groups from being affected by a group policy by limiting the scope of the policy. When you filter a GPO, you exempt a group from the settings within the policy.

graphics/tip_icon.gif

GPOs are linked to the site, domain, and OU objects within Active Directory. Filters, on the other hand, are applied to users or groups through discretionary access control lists (DACLs).


The group policies that are linked to an Active Directory object affect all users who have the Apply Group Policy permission for the GPO. This is the default permission given to all users for a GPO. That means all users are, by default, affected by the policy. To change the scope of the GPO and exclude certain users from being affected, simply create a security group that contains the users who need to be excluded and remove the Apply Group Policy permission to the GPO.

If the policy applies restrictions to the users' computing environment, some of the restrictions might not be required for administrative purposes. In that case, a filter could be applied to exempt those users responsible for administration of the OU from the policy. To filter by using security groups, do the following:

  1. Click Start, point to Administrative Tools, and select Active Directory User and Computers (or Active Directory Sites and Services, if GPOs are configured at the site level).

  2. Right-click the appropriate object and click Properties.

  3. Select the Group Policy tab. From the list of GPOs, select the appropriate one and click the Properties button.

  4. Click the Security tab. To exempt a group or user from the policy settings, highlight the appropriate account and clear the Apply Group Policy permission (see Figure 4.1).

    Figure 4.1. Filtering using security groups.

    graphics/04fig01.gif

In some instances, a GPO linked to a parent object should not be linked to its child objects (remember that a GPO linked at the OU level is inherited from parent object to child object). In such a case, blocking inheritance can prevent the GPO settings applied to a parent OU from being applied to a child OU.

Using a feature called block policy inheritance, the inheritance of a GPO can be modified so that it is not passed on from parent container to child container. Any policy applied at the domain or OU level can be blocked.

The Block Policy Inheritance setting is not applied to the GPO itself but rather to the domain or OU that should be exempt from the policy settings. All policy settings are blocked, not just those from a single GPO. Use the following steps to block the inheritance of a GPO:

  1. Open the Active Directory Users and Computers MMC snap-in.

  2. Right-click the domain or OU that should be exempt from the policy and choose Properties.

  3. Select the Group Policy tab and select the Block Policy Inheritance check box (see Figure 4.2).

    Figure 4.2. Using the Block Policy Inheritance option.

    graphics/04fig02.gif

The only time that the Block Policy Inheritance option will be ignored and the policy will still be applied is when the No Override option is set. No Override means exactly that. If the No Override option is set, any group policies linked to a parent object will be applied to the child objects regardless of whether the Block Policy Inheritance option is set. This option prevents any other GPO from overwriting the settings contained within it. Any GPO link that has the No Override option set will not be overwritten by another policy.

Use the following steps to specify the No Override option:

  1. Open the Active Directory Users and Computers MMC snap-in or the Active Directory Sites and Services MMC snap-in. If you're setting the No Override option at the site level, use the Sites and Services snap-in. Use the Users and Computers snap-in to set No Override at the domain and OU level.

  2. Right-click the site, domain, or OU that the GPO is linked to and choose Properties.

  3. Choose the Group Policy tab, select the GPO you want to set the No Override option to apply to, and choose Options.

  4. From the dialog box that appears, check the No Override check box (see Figure 4.3).

    Figure 4.3. Using the No Override option.

    graphics/04fig03.gif



MCSE Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure Exam Cram 2
MCSE Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure Exam Cram 2 (Exam Cram 70-297)
ISBN: 0789730154
EAN: 2147483647
Year: 2003
Pages: 152

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