Managing Policy Objects


Now that we have an idea of what policy is and what it can do for you, let's take a look at how to implement it in your network. Fortunately, Microsoft has supplied a multitude of management features for GPOs, such as inheritance, filtering, and blocking, which we cover in the next sections.

Linking GPOs

When we created the GPO in Step by Step 9.3, we actually performed two operations. We created the GPO and we linked it to the domain. As we saw earlier, all GPOs are stored in Active Directory in a central location. By keeping all the GPOs in a single location, they are easier to manage. When we want to apply a GPO to a domain site or OU, we link it to that object.

By default, only members of the Enterprise or Domain Admins groups can link GPOs to a domain or OU, and only Enterprise Admins can link GPOs to sites. Members of the Group Policy Creator Owners group can create GPOs; however, they cannot link them to an object.

Note: Disabling a Link

If a GPO no longer should be applied to an object, but is still being used for other objects, you can unlink it.


If you already have a GPO in place that you want to use for an additional OU, you can link it to that OU. In Step by Step 9.4, we will link our Rename Guest Account GPO to the Kansas City OU we created in a previous exercise.

Step by Step

9.4 Linking an existing GPO

1.

On your domain controller, select Start, All Programs, Administrative Tools, Active Directory Users and Computers.

2.

In the left pane, right-click the Kansas City OU and select Properties from the pop-up menu. This opens the Kansas City Properties dialog box.

3.

Click the Add button. This opens the Add a Group Policy Object Link dialog box, as shown in Figure 9.8. From the drop-down box, select the location to look in for the GPO.



Figure 9.8. Select a container to look in for the GPO.


4.

Select the domain; the Rename Guest Account GPO should be listed. Highlight the GPO entry and click the OK button. This returns you to the Kansas City Properties dialog box, with the selected GPO displayed.

5.

Click OK to save.

Note: Containers?

If you look closely in the left pane of the Active Directory Users and Computers MMC, you will notice that all the folder icons are not the same. Some icons are plainthese are containers. The other icons have an open folder label on themthese are OUs. Most of the containers are automatically created by the operating system, and some of them, such as the Users or Computers containers, cannot be linked to GPOs.


Linking GPOs is handy for a variety of reasons. For example, suppose that you have a test OU where you keep your test servers. Part of your testing is to create suitable GPOs to manage these servers. When testing is complete, you can move the servers to your production OU. Instead of manually copying the settings from your test GPOs, you can link them to the production GPO.

Default Group Policy Objects

Windows Server 2003 comes with two default GPOs:

  • Default Domain Policy This policy is linked to the domain and controls the default Account Policies for things such as Password Policy and Account Lockout.

  • Domain Controllers Policy This policy is linked to the Domain Controllers OU and contains settings strictly for the domain controllers.

It's best to not edit the default GPOs. Any changes should be implemented in new GPOs.

Group Policy Inheritance

Group Policy in Windows 2003 works according to the hierarchy of site domain OU, or SDOU for short. As we mentioned earlier, the effects of Group Policy as it is applied are cumulative. As more policies are applied, their settings are merged, with the last setting winning.

What this means is that if you apply a GPO for a site, it will apply to everything in that site. If you apply a GPO to a domain, both the site and the domain GPOs will be applied. This continues down the hierarchy of OUs. For example, take a look at the OU structure in Figure 9.9 that we created in Chapter 2.

Figure 9.9. The OU hierarchy.


When we get to the bottom of our hierarchy, at the Users OU, we could potentially have applied at least four GPOsone each at the site, domain, Kansas City OU, and the Users OU levels.

Note: Active Directory Sites

Sites are handled a little differently from other objects in AD, because they are a physical object and can contain resources from several domains. When an OU is linked to a site, the properties of the OU affect all resources in the site, regardless of their domain membership.


This process is called Inheritance. The Active Directory objects lower in the hierarchy inherit the settings from those higher in the hierarchy.

In addition to inheritance, an Active Directory container can have multiple GPOs linked to it. In addition to the SDOU order, the GPOs linked to the container can be assigned in order. This is configured from the Properties dialog box on the Group Policy tab of the OU, as shown in Figure 9.10.

Figure 9.10. Setting GPO priority.


As you can see in the figure, changing the priority of the GPOs is a simple as clicking a button.

Blocking Group Policy Inheritance

Although inheritance might sound like a good thing in theory, in practice it can get quite messy. For example, what if you want the users in the Users OU to have different settings from those at the domain level? Or what if you as the system administrator have delegated the management of the Kansas City OU to a junior administrator in that location, and she insists on changing the corporate settings?

In these situations, you have the option of modifying the standard inheritance rules for specific GPOs. The first option is to Block Policy Inheritance. This option is set on a per-container basis and will block the inheritance of all policies. It's strictly an all-or-nothing solution.

In Step by Step 9.2 and 9.3, we implemented both a Local and a Group Policy to rename the Guest account. As we left things in Step by Step 9.3, there is a GPO at the domain level that is Renaming the Guest account. In Step by Step 9.5, we will put our member server or workstation in the workstations OU and block inheritance, so that the GPO is not in effect.

Step by Step

9.5 Blocking Group Policy Inheritance

1.

On your domain controller, select Start, All Programs, Administrative Tools, Active Directory Users and Computers.

2.

Locate the computer account for your test member server or workstation. Move the computer account into the Kansas City\Workstations OU.

3.

Right-click the Workstations OU and select Properties from the pop-up menu.

4.

Select the Group Policy tab. Select the Block Policy Inheritance check box, as shown in Figure 9.11. Click OK to save.

Figure 9.11. Enable Block Policy Inheritance.


5.

Go to your member server or workstation, open a command window, and enter the following command: gpupdate.

6.

Close the command window.

7.

Select Start, All Programs, Administrative Tools, Computer Management.

8.

In the Computer Management console, click System Tools, Local Users and Groups, Users.

9.

The account name will be displayed in the right pane. It should not have been set to the name you specified in the blocked GPO.

The Block Policy Inheritance option is useful for situations where the objects in a container require unique settings, and you want to ensure that those settings are not in conflict with inherited settings. In addition, this option can be used when a local administrator is responsible for managing an OU, and she prefers to control her own Group Policy configurations.

However, even when Block Policy Inheritance is turned on, it cannot block the inheritance of a GPO that has the No Override option turned on. We'll look at enforcing Group Policy in the next section.

Challenge

You are the lead system administrator for your company. Upper management has decided that the Phoenix office is going to be allowed to manage its own desktops. However, certain settings in the Default Domain Policy must remain in place. You currently have a single GPO linked to the Phoenix OU named Desktop Settings.

How can you implement this management directive using the least amount of effort?

Try to complete this exercise on your own, listing your conclusions on a sheet of paper. After you have completed the exercise, compare your results to those given here.

1.

On your domain controller, select Start, All Programs, Administrative Tools, Active Directory Users and Computers.

2.

In the left pane, right-click the Phoenix OU, and select Properties from the pop-up menu. This opens the Phoenix Proprieties dialog box.

3.

Select the Group Policy tab. Highlight the Desktop Settings entry, and then click the Delete button.

4.

This opens the Delete dialog box. Select the option to Remove the link from the list, and then click OK.

5.

On the Properties dialog box, click OK to save.

In this situation, we couldn't block the inheritance to the OU because we need to retain the Default Domain Policy settings. Also, deleting the Desktop Settings GPO wouldn't be a good idea, because it might be linked to other GPOs. Just deleting the link removes it from the Phoenix OU without affecting anything else.


Enforcing Group Policy

The second way to control Group Policy Inheritance is to select the No Override option. This option is used to prevent a child container from blocking the application of a GPO that is inherited from the parent. Unlike the all or nothing of the Block Policy Inheritance option, the No Override option is set on a per-GPO basis.

Note: Enforced

The No Override option is renamed to Enforced after the Group Policy Management Console (GPMC) is installed.


The No Override option allows the administrator to enforce specific settings, possibly companywide configuration settings that should take precedence over anything else. A GPO that has the No Override option turned on will take precedence over the settings in the child container, even though traditionally the child settings would take precedence.

On GPOs with the No Override setting enabled, the Block Inheritance setting is ignored.

In Step by Step 9.6, we continue our scenario using the Rename Guest Account GPO. This time we set the No Override option to force the setting in the Kansas City\Workstations OU.

Step by Step

9.6 Enforcing Group Policy inheritance

1.

On your domain controller, select Start, All Programs, Administrative Tools, Active Directory Users and Computers.

2.

In the left pane, right-click the Kansas City OU and select Properties from the pop-up menu. This opens the Kansas City Properties dialog box.

3.

Select the Group Policy tab. Highlight the desired GPO, then click the Options button. This opens the Rename Guest Account Options dialog box, as shown in Figure 9.12.

Figure 9.12. Enable the No Override option.


4.

Select the No Override check box. Click OK to save.

5.

Click Apply to close the Kansas City Properties dialog box.

6.

Go to your member server or workstation, open a command window, and enter the following command: gpupdate.

7.

Close the command window.

8.

Select Start, All Programs, Administrative Tools, Computer Management.

9.

In the Computer Management console, click System Tools, Local Users and Groups, Users.

10.

The account name will be displayed in the right pane. It now should be set to the name configured in the blocked GPO.

Group Policy Management Console

The Group Policy Management Console (GPMC) is a free add-on from Microsoft that can be downloaded from the website at http://www.microsoft.com/downloads/details.aspx?FamilyId=0A6D4C24-8CBD-4B35-9272-DD3CBFC81887&displaylang=en. The GPMC allows you to manage your GPOs via a GUI interface in a more intuitive manner with more functionality than the tools we have been using so far in this chapter.

The GPMC can be installed on either Windows Server 2003 or Windows XP SP1 and can be used to manage GPOs in either a Windows 2000 or a Windows Server 2003 domain. After the GPMC is installed, the Group Policy tab that we've been using in the Active Directory Users and Computers MMC is replaced with a message and a button that opens the GPMC, as shown in Figure 9.13.

Figure 9.13. Click to open the GPMC.


After the GPMC is installed, it can be opened directly by selecting the Group Policy Management icon in the Administrative Tools folder.

Exam Alert: To Study or Not to Study?

As this book was going to press, Windows Server 2003 SP2 is being released, and the GPMC was not included in it. It is still just an add-on downloadable from the web. However, it has been added to the exam. We will cover both methods of working with GPOs in this book.


As you can see in Figure 9.14, the GPMC allows you not only to see all of the OUs and GPOs in your domain, but it displays every domain in the forest. If you have the proper permissions, you can copy, back up, restore, import, and link GPOs between and across domains. Another point of interest is the display of the Group Policy Objects container. The GPO container holds all the GPOs in the domain. If you look at the icons for the other GPOs shown in the console, you will notice that they are linked to the other containers. Previously, we knew that the GPO container existed, but it was just a logical entity. We couldn't see itnow we can.

Figure 9.14. The GPMC, showing the forest view.


In effect, all the logical things we discussed about Group Policy are now visible.

To find out more about the Group Policy Management Console, consult the online help for the GPMC, and read the GPMC white papers available at http://www.microsoft.com/windowsserver2003/gpmc/default.mspx.

Group Policy Filtering

In Windows Server 2003, the default is for all objects in the container to be affected by all GPOs that are applied to that container. However, there will be situations where you will want some GPOs to apply only to certain users, computers, or groups. This process is called Group Policy Filtering.

Group Policy Filtering works by applying permissions on the GPO so that it can be used only by certain users, computers, or groups. For a Group Policy to be applied to an object, that object must have at least Read permissions for the GPO. The default permissions for a GPO are the following:

  • Authenticated Users Read, Apply Group Policy

  • Domain Admins, Enterprise Admins, SYSTEM Read, Write, Create All Child Objects, Delete All Child Objects

  • Creator Owner Special Permissions

As you can see, because the Authenticated Users group has Read and Apply permissions on all GPOs, they apply by default to everything on the network. There are two ways to filter GPOs:

  • Explicitly Deny In this method, a new security group is created and assigned the Deny Apply Group Policy permission. Objects that should not be affected by this GPO are added to the group.

  • Remove Authenticated Users In this method, the Authenticated Users group is removed from the DACL for the GPO. A new security group is created and given Read and Apply Group Policy permissions to the GPO. The desired objects are added to this group.

Either method works the same in practice; it's strictly a matter of preference.

In Step by Step 9.7, we will use the Group Policy Management Console to use the Explicitly Deny method to keep the Rename Guest Account GPO from being applied to our member server or workstation.

Step by Step

9.7 Filtering Group Policy

1.

On your domain controller, select Start, All Programs, Administrative Tools, Active Directory Users and Computers.

2.

Create a domain local security group and name it Deny Rename.

3.

Add the computer account of your workstation or member server to this security group.

4.

Select Start, All Programs, Administrative Tools, Group Policy Management.

5.

In the left pane, expand the domain, and then expand the Group Policy Objects container. Select the Rename Guest Account GPO.

6.

In the right pane, select the Scope tab. Click the Add button in the Security Filtering area, as shown in Figure 9.15. From the Select User, Computer, or Group dialog box, enter the Deny Rename group. Click OK to save.



Figure 9.15. By default, the settings in the GPO apply to all Authenticated users.


7.

In the right pane, select the Delegation tab.

8.

Highlight the entry for the Deny Rename group and select the Advanced button. This opens the Rename Guest Account Security settings dialog box shown in Figure 9.16.

Figure 9.16. Set the security on the Deny Rename group to deny Full Control.


9.

Highlight the entry for the Deny Rename group and select Deny Full Control.

10.

Click OK to save, and then click Yes in the Security Warning prompt.

11.

Go to your member server or workstation, open a command window, and enter the following command: gpupdate.

12.

Close the command window.

13.

Select Start, All Programs, Administrative Tools, Computer Management.

14.

In the Computer Management console, click System Tools, Local Users and Groups, Users.

15.

The account name will be displayed in the right pane. It should not be set to the name configured in the GPO.




MCSA. MCSE 70-290 Exam Prep. Managing and Maintaining a MicrosoftR Windows ServerT 2003 Environment
MCSA/MCSE 70-290 Exam Prep: Managing and Maintaining a Microsoft Windows Server 2003 Environment (2nd Edition)
ISBN: 0789736489
EAN: 2147483647
Year: 2006
Pages: 219
Authors: Lee Scales

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