|
|
This section provides a number of examples of implementing group policies. These examples are representative of the type of Group Policy management available to the system administrator.
The example that follows shows how to implement the Local Computer Policy snap-in and employ it to manage local GPOs. This is the easiest way to access this GPO; other GPOs can be reached through the Active Directory containers. Local computer policies are centrally managed on remote systems by adding the remote computer policies to the administrator's console. This example loads the local policies for the system the administrator is logged on to.
Log on as Administrator.
Go to Start 
Programs Accessories command prompt or Start Run, type MMC, and then Enter.
A Console window appears. Click the File pull-down menu.
Select Add/Remove snap-in.
The Add/Remove Snap-in dialog should appear (Figure 8.32).
Click Add. The Add Standalone Snap-in dialog should appear.
Select Active Directory Users and Computers.
Click Add.
From the list of Available Standalone snap-ins, select Group Policy (Figure 8.33).
Click Add. The Group Policy Object should be LocalComputer (Figure 8.34).
Click Browse. The Browse for a Group Policy Object dialog appears (Figure 8.35).
There are four tabs associated with this dialog:
The Domains/OUs tab displays GPOs for the domain and OU containers.
The Sites tab displays current sites and their associated GPOs (Figure 8.36).
The Computers tab allows you to select the local GPO assigned to the current computer or to select another computer from Active Directory. This provides remote administration of local computer policies (Figure 8.37).
The All tab displays all GPOs for the domain except the local computer policy object (Figure 8.38).
For this example, click Cancel, and select Local Computer as the Group Policy Object.
Click Finish, then Close, then OK.
The Local Computer Policy snap-in has now been added to your newly created console. Opening the Policy node reveals available local policy settings. When you are finished, select the Save As option from the Console pull-down menu and save the console on the desktop or in a specific folder.
This example illustrates how to create a GPO and apply it to an Active Directory container. In particular, a new organizational unit is created and then an Administrative Template group policy is enabled. Methods for blocking inheritances are also explored. As mentioned in the discussions about implementation, the following examples should be implemented on a domain controller. Doing so will mean that you will have to wait approximately 5 minutes for policies to be refreshed on your test system.
Start the Custom console created earlier by double-clicking the console file from My Computer or the desktop.
Click the plus sign in front of Active Directory Users and Computers. Right-click Your domain.com (Entcert2.com) and select New Organizational Unit. Create a new OU called Engineering and add a user.
Create an OU within Engineering called Sustaining and add a user (Figure 8.39).
Right-click the Engineering OU and select Properties. The Engineering Properties dialog box appears (Figure 8.40). Select the Group Policy tab and click New. Name the new object Engineering GPO (Table 8.3).
Click Edit and select the plus sign in front of User Configuration Administrative Templates System CTRL + ALT + DEL Options. In the Policy window, double-click Remove Lock Computer.
The Remove Lock Computer Properties dialog window appears. Select Enabled. Notice that the Previous Setting and Next Setting buttons allow you to browse up and down the Policy window. Click OK. The Remove Lock Computer policy has been enabled at the Engineering OU level (Figure 8.41).
Allow Group Policy to refresh and log on as an Engineering user. Press CTRL + ALT + DEL and notice that Lock Computer appears dimmed. Log on again as the Administrator.
As discussed earlier, it is helpful to disable the portions of a GPO that are not being used to save processing time when applying group policies. User and computer settings can be disabled if no policies are enabled below the node in the policy hierarchy. In this example, we have set a user policy and can therefore disable the computer portion of the GPO.
|
Button |
Function |
|---|---|
|
New |
Creates a new GPO and adds it to the Active Directory container. |
|
Add |
Selects from a list of existing GPOs or creates a new GPO to add to the current container. |
|
Edit |
Displays the Group Policy tree for the selected GPO and allows policy modification. |
|
Options |
Allows user to enforce this GPO on this container and child containers below it or to prevent this policy from acting on the container. |
|
Delete |
Removes the selected GPO from the container Group Policy list. |
|
Properties |
Allows the administrator to disable the user or computer portion of the GPO to enhance boot-up or user logon speed. Permits this GPO to be linked by other domains and allows access to security settings for the selected GPO. |
|
Up |
Promotes the selected GPO in the current GPO list. GPOs are applied from the top of the list to the bottom. |
|
Down |
Demotes the selected GPO in the current GPO list. GPOs are applied from the top of the list to the bottom. |
|
Block inheritance |
Blocks policy inheritance from a parent container. |
Right-click the Engineering OU and select Properties. Select the Group Policy tab. Click Edit.
Right-click the Engineering GPO root node and select Properties. On the General tab, select Disable Computer Configuration settings (Figure 8.42).
Users in the Engineering OU and its child OUs will also inherit this policy. For a child OU to disable a policy inherited from its parents, it must counteract the policy setting using another GPO. Let's create a GPO at a lower level to override the Remove Lock Computer policy setting.
Click the plus sign in front of the Active Directory Users and Computers selection in the Custom console. Open your domain name node, the Engineering OU node, and then the Sustaining OU node.
Right-click the Sustaining OU and select Properties. The Sustaining Properties dialog appears. Click the Group Policy tab.
Click New. Name the new object Sustaining GPO.
Highlight the new GPO and click Edit.
Click the plus sign in front of User Configuration, then select Administrative Templates System CTRL + ALT + DEL Options. In the Policy window, double-click the Remove Lock Computer policy. Select Disabled. Click OK.
The Remove Lock Computer policy should be disabled at the Sustaining OU level.
Log off the system and log on again as a Sustaining user. Notice that the Lock Workstation button no longer appears dimmed.
By disabling the Remove Lock Computer policy in the Sustaining GPO, users in the Sustaining OU will be able to lock their systems. Rather than directly override an inherited policy, try using the Block Policy Inheritance feature as follows:
From the Custom console, open the Sustaining OU and right-click Properties. Select the Group Policy tab and select the Sustaining GPO. Click Edit. Proceed to Remove Lock Computer policy User Configuration Administrative Templates System CTRL + ALT + DEL Options. In the Policy window, double-click Remove Lock Computer. Select Not Configured. Click OK.
Now the Remove Lock Computer policy will again be inherited by the Sustaining OU.
Block policy inheritance from the Engineering OU as follows:
Close the Group Policy window. In the Sustaining Properties dialog box, check the Block Policy inheritance box (Figure 8.43). Close the Custom console, log off, and log on as a Sustaining user. Notice that the Lock Workstation box is still accessible. Blocking policy inheritance prevents the Engineering GPO from being applied to the Sustaining OU.
Enforcing a GPO from the Engineering OU takes precedence over both the block policy inheritance and the policy override settings.
Open the Custom console, right-click the Engineering OU, and select Properties.
Select the Group Policy tab and click New. Name the new GPO Design Access GPO. Press Options and check the No Override check box (Figure 8.44). Click OK. Notice that the No Override column is now checked. This feature can also be enabled/disabled by going to the Engineering Properties dialog box and double-clicking in the No Override column.
The Design Access GPO is now enforced at the Engineering OU level.
Exit Custom console, log off, and log on as a Sustaining user. Notice that the Lock Workstation button appears dimmed once again.
The Sustaining group cannot override an enforced policy from a parent. The Block Inheritance feature is also unable to prevent enforced policy inheritance.
NOTE
One of the tasks an administrator should undertake is preventing users from "tattooing" the Registry. From the Administrative Templates node, the user can view user preferences in addition to policy settings. The user can view and modify user preferences that are not stored in maintained portions of the Registry. If the group policy is removed or changed, the user preference will persist in the Registry. This is known as "tattooing," a prominent problem in earlier group policy implementations. Avoid letting users modify user preferences by going to User Configuration Administrative Templates System Group Policy enable Enforce Show Policies Only (Figure 8.45).
GPOs that are linked to a given Active Directory container (site, domain, or OU) apply to all authenticated users in the container by default. However, Security permissions associated with a GPO also govern which users the GPO will apply to. A security group may deny the GPO policy, thereby making all users who are members of that group immune to it. Let's look at an example.
Create a domain local security group called Software Config and add an Engineering OU user to it.
Go to the Engineering OU, right-click Properties, and view the Group Policy tab. Select the Engineering GPO and click Properties.
Click the Securities tab (Figure 8.46) and click Add. Add the Software Config security group to the Engineering GPO's access control list.
Select the Software Config group and check the Deny box on the Apply Group Policy permissions line.
Click OK and answer Yes to the Warning dialog box.
Log off and log on as the Engineering OU user previously added to the Software Config security group. The Lock Workstation button should be accessible.
This new member of the Software Config group has filtered out the Engineering GPO by denying the Apply Group Policy permission. Even though the user is also a member of the Engineering OU, the Deny permission from the Software Config group takes priority over all other security groups that may allow Apply Group Policy. In the following steps, the Engineering GPO will be rendered useless if neither the Allow box nor the Deny box is marked for the Apply Group Policy permission for all security groups associated with it.
Go to the Engineering GPO Properties dialog box. Remove all security groups except Enterprise Admins and Software Config. Select the Software Config group and ensure that the Apply Group Policy box is not checked under Allow or Deny for either group (Figure 8.47). You may have to press the Advanced button and clear the Inherit from parent the permission entries that apply to child objects option.
The Enterprise Admins group should allow Read/Write/Create All Child Objects/Delete All Child Objects so that administrative functions can still be performed on the GPO.
Log off and log on as the Engineering user. The Lock Workstation button should be accessible. The GPO is not applied to the Software Config group of which the user is a member.
If the Domain Users group allowed Apply Group Policy, then the user would have the group policy applied. A user must be a member of a security group that applies the group policy in order to use the GPO. The default security settings for GPOs apply policies to the Authenticated Users group. This covers most users with interactive logon capability.
In a previous section, we discussed the conceptual basis of scripts. For system administration, scripts can be used for numerous activities. A script can be executed in one of four time periods: startup, shutdown, logon, or logoff.
This example runs a test script when the user logs on to a system:
Create a very simple test Java script to run on logon. Open Notepad and enter the following line:
Wscript.echo("You have run the logon script!");
Save the file as testscript.js on the local hard drive.
Open the Custom console and find the Engineering OU. Open the group policies linked to this OU and edit the Engineering GPO.
Follow the User Configuration Windows Settings Scripts path and double-click the Logon Properties (Figure 8.48).
Click Add to expose the Add a Script dialog box (Figure 8.49). Click Browse and find the file named testscript.js. Click OK.
The script should be available to the user at logon.
Scripts execute from top to bottom and may be rearranged by clicking the Up and Down buttons. The Edit button allows script path modification, name changing, and parameter editing. Scripts are removed by clicking the Remove button.
The Show Files button displays the scripts stored in the default directory for this GPO. The startup and shutdown script policies may found in Computer Configuration Windows Settings Scripts.
This example will illustrate how to implement folder redirection. To redirect all My Document folders for the Engineering OU to one common server, follow these steps:
Edit the Engineering GPO applied to the Engineering OU. Go to User Configuration Windows Settings Folder Redirection My Documents. Right-click My Documents and select Properties. The My Document Properties window appears. From the Setting pull-down menu, select Basic—Redirect everyone's folder to the same location.
Click Browse and find a shared server folder for all Engineering users.
Click OK.
See the later section "IntelliMirror" for examples of folder redirection.
 |
|
|
| Top |