Tutorial

Further understanding GPOs for Windows Vista

This chapter excerpt from Microsoft Windows Vista Management and Administration, by Andrew Abbate, James Walker, Scott Chimner and Rand Morimoto, is printed with permission from Pearson Education,

Requires Free Membership to View

Copyright 2007.

Click here for the chapter download or purchase the entire book here.


Further Understanding GPOs

Previously, when discussing the basics of Group Policy with Windows Vista, we touched on many of the rules and requirements around GPOs and their use in a domain environment. This chapter builds on the information presented there to give administrators a greater understanding of their uses and limitations.

Understanding the Order in Which Group Policies Are Applied

As mentioned previously, GPOs are applied in a specific order. Computers and users whose accounts are lower in the Directory tree can inherit Policies applied at different levels within the Active Directory tree. Group Policy is applied in the following order throughout the AD tree:

  • Local Security Policy is applied first.
  • Site GPOs are applied next.
  • Domain GPOs are applied next.
  • Organizational Unit (OU) GPOs are applied next.
  • Nested OU GPOs and on down are applied next, until the OU at which the computer or user is a member is reached.
  • If a setting in a GPO is set to Not Configured in a policy higher up, the existing setting remains. However, if conflicts exist in configuration, the last GPO to be applied prevails. For example, if a conflict exists in a Site GPO and in an OU GPO, the settings configured in the OU GPO will "win."

    If multiple GPOs are applied to a specific AD object, such as a site or OU, they are applied in reverse of the order they are listed. The last GPO is applied first, and therefore if conflicts exist, settings in higher GPOs override those in lower ones. For example, if a Contacts OU has the following three Group Policies applied to it and they appear in this order the policies will be applied from the bottom up:

  • Contacts Default Group Policy
  • Contacts Software Policy
  • Contacts Temporary Policy
  • The Contacts Temporary Policy will be applied first. The Contacts Software Policy will apply next, and finally the Contacts Default Group Policy will be applied. Any settings in the Contacts Default Group Policy will override the settings configured in the two policies below, and the settings in the Contacts Software Policy will override any settings in the Contacts Temporary Policy.

    Modifying Group Policy Inheritance

    The Block Inheritance, Enforcement, and Link Enabled features allow control over the default inheritance rules.

    GPOs can be configured to use the Enforcement feature. This setting does not allow the parent organizational unit to be overridden by the settings of the child OU if conflicts exist. Additionally, it nullifies the effects of Block Policy Inheritance if that functionality is applied on sub-GPOs.

    OUs can be set to Block Policy Inheritance. This feature prevents the AD object that has the GPO applied to it from inheriting GPOs from its parent organizational unit, site, or domain (unless the parent GPO had Enforcement enabled as described previously).

    To block Policy Inheritance on an OU, perform the following steps:

    1. Launch the Group Policy Management console (GPMC) (Start, Run, gpmc.msc).
    2. Expand the Forest container.
    3. Expand the Domains container.
    4. Browse to the OU to which you plan to Block Inheritance.
    5. Right-click the OU and choose Block Inheritance.

    The OU will now display a blue circle with a white exclamation mark to indicate that Policy Inheritance is blocked from this point down in the hierarchy (see Figure 23.1). This is to say, GPOs set above this point will not affect objects below the point of blocking. This behavior can be overwritten by setting a GPO to Enforced.

    Figure 23.1

    Finally, the option exists that allows for the disabling of a GPO, also known as the GPO's Link Enabled status. By right-clicking the Group Policy in the Group Policy Management console and unchecking Link Enabled, you can disable the policy and render it unused until the time it is reenabled.

    Configuring Group Policy Loopback

    Loopback allows Group Policy to be applied to the user logging in based on the location of the computer object, not the location of the user object in AD. Loopback applies a Group Policy based on the computer the user is using, not the user logging in to the computer. An example of a good use of the loopback option concerns Terminal Services. If you need to apply specific permissions to everyone who logs in to a particular Terminal Server, regardless of the user Group Policies, loopback in replace mode will accomplish this objective by ignoring all user GPOs. Loopback also provides a merge mode that merges the GPOs that apply to the user and computer but gives precedence to the computer GPOs, overriding any conflicting user GPOs.

    The GPO setting for Group Policy Loopback processing is located under
    Computer Configuration / Administrative Templates / System / Group Policy / User Group Policy loopback processing mode.

    Figure 23.2

    Leveraging Local Policy

    Local Policies can be used to enforce many of the same settings that GPOs can enforce. The advantage of the Local Policy is that it is enforced regardless of whether the computer can contact a domain controller. This means that settings can be placed into the initially deployed image and will be in effect from the moment the computer is powered on.

    One very useful way to use Local Policy is to essentially reverse the paradigm of GPOs when dealing with security-related settings. For example, suppose that you want to configure Vista workstations so that their users can't run the Registry Editor. In this example, we assume that we'd like the local help desk staff to be able to run the Registry editor. The two ways to do this are the following:

  • Option 1 -- Block the capability to run Registry Editor via GPO. Link the GPO to the container holding typical users. Place help desk personnel in another container in Active Directory. Do not link the Registry Editor blocking GPO to those users.

  • Option 2 -- Block the capability to run Registry Editor in Local Policy on the deployed Vista image. Create a GPO that enables running the Registry Editor. Link it to a container that holds help desk personnel.
  • Although at first glance the two options might seem equivalent, they are in fact somewhat different in their scopes. Imagine that Vista systems are being deployed to remote users. The system is built and shipped out to the end user. The user receives the computer and powers it on for the first time. If the user is on the network at this first boot, the GPO will be received and applied properly. If the system is not on the network, the domain GPOs cannot take effect. In Option 1, the remote user would be able to run the Registry Editor and make modifications to the system. In Option 2, the user would not be able to modify the system. In cases where the computer needs to be protected or modified prior to its first logon to the domain, Local Policy is a better option.

    Local Policy can be accessed by performing the following steps:

    1. Click Start.
    2. Click All Programs.
    3. Click Administrative Tools.
    4. Click Local Security Policy (see Figure 23.3).

    Figure 23.3


    GROUP POLICY BASICS FOR WINDOWS VISTA

     Home: Introduction
     Tip 1: A basic primer on Microsoft Group Policy
     Tip 2: How to configure GPOs
     Tip 3: What's new with Vista Group Policy?
     Tip 4: How to manage GPOs
     Tip 5: Troubleshooting GPOs for Vista
     Tip 6: Group Policy best practices
    ADVANCED GROUP POLICY FOR WINDOWS VISTA
     Home: Introduction
     Tip 1: Which GPOs are available
     Tip 2: Further understanding GPOs in Vista
     Tip 3: Examples of useful GPOs in Vista
     Tip 4: Moving policies between domains
     Tip 5: Recommended practices with Vista Group Policy

    This was first published in January 2008

    There are Comments. Add yours.

     
    TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

    REGISTER or login:

    Forgot Password?
    By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
    Sort by: OldestNewest

    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to: