Sign In Sign-Up

Welcome!

Close

Would you like to make this site your homepage? It's fast and easy...

Yes, Please make this my home page!

No Thanks

  Don't show this to me again.

Close

UNDERSTANDING GROUP POLICIES

Since group policies are designed to apply to a great number of users, they have the potential to reduce system administration support. Once a Group Policy setting is established on a user account, it is automatically applied to the desired administrative unit. This facility is especially helpful when applying security policies, but it is also widely used to establish consistency in user environments. For example, through the use of group policies, an administrator can control the options available on users' desktops and the delivery of applications.

Group Policy also implements the bulk of the Microsoft IntelliMirror technology. This strategy capitalizes on the centralized management of client/server systems while maintaining the flexibility and convenience of the distributed computing model. For example, users can log on from anywhere in the network and preserve user profiles, application data, security requirements, application access, and backup offline files. Microsoft's IntelliMirror, as discussed in this chapter, provides more examples and details for this technology.

Group policies can be extended by third-party application vendors as well to manage desktop settings for their applications.

Group Policy Management and Active Directory

Group Policy management is accomplished by assigning Group Policy Objects (GPOs) to specific machines, sites, domains, and OUs from the Active Directory. Applying Group Policy involves determining which users and computers require policy settings so that selected Active Directory containers can group users and computers accordingly. GPOs are then applied to the desired Active Directory containers and are inherited by child containers. Windows Server 2003 follows the LSDOU model in which inheritance flows in this order: local computer (L) site (S) domain (D) organizational unit (OU).

The LSDOU inheritance model may seem unnatural at first (Figure 8.1). Local computer GPOs are the first applied to any user who logs on to that particular system. They can be overridden by the GPOs assigned to the user's site, which are overridden by domain GPOs, which are overridden by relevant OU GPOs. This order gives the local administrator the first chance to set the computer's policies.

When GPO policies are enforced, any child GPO settings applied to a system are disabled. The local computer GPOs may not enforce policies. They are the first to be set, but may be nullified by further policy inheritance.

The LSDOU model provides a reference point for determining the users and computers a GPO affects. A GPO can be applied to any of three container types: site, domain, and OU. In Figure 8.1, the Default Domain Policy GPO has been assigned to the Entcert2.com domain, so the users and computers in that domain as well as all OUs within it will receive these policy settings. The same GPO may also be applied to more than one Active Directory container. In the figure, the Public Docs Policies GPO is applied to both the Engineering OU and the Marketing OU. This is referred to as linking.

GROUP POLICY OBJECT STORAGE

Before introducing the Group Policy feature set, it is important to understand, on the local and domain levels, Group Policy storage. Local computer policies are stored on the local system in the %SystemRoot%System32\GroupPolicy directory. They are not replicated to other systems, nor do they cover the complete range of policies accessible to enterprise-wide GPOs applied to Active Directory containers.

Active Directory GPO storage is a little more complicated. These policies are stored in the Group Policy container (GPC) and the Group Policy template (GPT). The GPC includes version, status, and extensions for the GPO. As discussed earlier, it may be a site, domain, or OU Active Directory object, and is synchronized with other domain controllers on its own update schedule. Small amounts of information that are modified infrequently are stored in the GPC, which is assigned a globally unique identifier (GUID), such as {31B2F340-016D-11D2-945F-00C04FB984F9} , which corresponds to a GPT. Data stored in the GPC is used to determine whether the GPO is enabled and to ensure that the correct GPT version is applied to user and computer accounts in the container.

The GPT is stored on domain controllers in the %SystemRoot%\SYSVOL\sysvol\domainname\Policies\GUID folder for domain-wide replication and access. Standard folders in this directory are Adm, USER, and MACHINE. All user and computer policy settings for the GPO are stored in the GPT and synchronized on a different schedule from that of its sister GPC information. The GPT contains the raw policy settings, including security settings and software installation information. It can be thought of as the folder structure you can see when modifying a Group Policy object from an MMC snap-in, such as is shown later in Figure 8.6.

REFINING GROUP POLICY INHERITANCE

In addition to inheritance order, several other rules control which users and computers are assigned group policies. These rules allow the administrator to refine policy application:

• Policy inheritance

• Blocking policy inheritance

• Enforcing policy inheritance

• Using security groups to filter group policies

Policy Inheritance

The LSDOU model discussed earlier generally describes how Group Policy inheritance is implemented in Windows Server 2003. A clear example may shed light on how it works. In Figure 8.1 the Engineering Policies GPO applied to the Engineering OU is also inherited by the Sustaining and Development OUs. This shows that whereas child Active Directory containers inherit group policies, Group Policy inheritance does not flow upward to parent containers.

Let's dissect the example in Figure 8.2 to illustrate this flow in greater detail. Policies inherited by the Marketing OU from its parents are applied to members of the Channel Marketing OU. Users and computers in the Channel Marketing OU also apply the Marketing Policies GPO and Public Docs GPO to their systems upon boot-up and logon. The Distribution Centers GPO is applied last and may override group policies previously applied to the Channel Marketing OU. Thus, the lowest-level Active Directory container has the last opportunity to override inherited policies.

Blocking Policy Inheritance and Enforcement

The inheritance hierarchy can be modified by use of the Override or Enforce function, which blocks inherited features associated with parent GPOs. The Engineering OU (Figure 8.4) has enforced the Design Access GPO policies and not the Engineering GPO policies. The Sustaining OU has elected to block inheritance, so it does not inherit the Engineering GPO policies since they are not enforced. However, the Design Access GPO policies are enforced at the Engineering OU level and thus override the Sustaining OU's desire to block inheritance. In other words, the enforcement of parent group policies takes precedence over policy blocking on child containers.

Security Group Filtering

As with files and other objects in Windows Server 2003, the discretionary access control list (DACL) determines permission levels for users and computers that access a GPO. Each GPO has its own security settings determined by a DACL and associated permissions. Access control entries (ACEs) usually take the form of security groups, rather than individual users, and assign sweeping privileges to many users at once. Each ACE can be assigned Allow and Deny permissions through the GPO security settings (Figure 8.5).

The Authenticated Users group is one of the default security groups assigned to a new GPO. Read and Apply Group Policy permissions are set to Allow, which means that all newly authenticated users mapped to this GPO will apply its policies. Consistent with other Windows Server permissions, Deny takes precedence over Allow. Members of a security group may "filter" group policies by denying the Apply Group Policy permission. A filtered security group will not accumulate logon delays due to the GPO. Group Policy access permissions can also be used to delegate administrative authority to security groups and users. A user must have Read and Write access to make GPO changes.

Group Policy Settings

Group policies are broken into five areas, each of which is discussed in the following sections. Example implementations are provided at the end of the chapter. Keep in mind that individual policies affect all aspects of a system's operation.

Following are the five policy categories defined in the Group Policy snap-in.

• Administrative templates (Registry-based) policies primarily affect the user interface and available tools and desktop settings.

• Security settings limit user access to systems and user account policies.

• Software installation policies allow the publishing and assignment of available software.

• Scripts configure scripts for logon, logoff, startup, and shutdown.

• Folder redirection settings permit the relocation of user profile folders (e.g., My Documents, Application Data, Start menu) to other system network shares.

USER AND COMPUTER POLICIES

A GPO divides policies into two major sections, Computer Configuration and User Configuration (Figure 8.6). Policies within Computer Configuration are applied during the boot sequence and affect all sessions that follow on that system. User Configuration policies are applied when the user first logs on. Computer policies apply to the system; user policies follow the user.

Either the Computer Configuration or the User Configuration portion of a GPO may be disabled to save time and processing. For instance, if a GPO does not enable any computer policy settings, the Computer Configuration portion of the GPO should be disabled. This is demonstrated in the following sections.

ADMINISTRATIVE TEMPLATES

Both user-related and computer-related Administrative Template nodes are used to modify Registry settings. The related Registry database settings are located in the HKEY_CURRENT_USER (HKCU) and HKEY_LOCAL_MACHINE (HKLM) Registry keys. Whenever policy changes are made to the Administrative Template portion of the GPO, the Registry keys HKCU and HKLM are also updated. If there is a conflict between computer and user settings, the computer settings take priority. A Registry.pol file in the %systemroot%\SYSVOL\sysvol\domainname\Policies\GUID\MACHINE and USER directories maintains group policy changes to the Registry. Any changes made through administrative template policies are made in the Registry.pol file and then mapped onto the Registry.

The policies available under the Administrative Templates node take the form of the ASCII files such as system.adm and inetres.adm by default (Figure 8.7). The default Windows Server 2003 installation includes other administrative templates that may be loaded in order to modify policies for specific applications or network architectures (Table 8.1).

In addition to these templates, located physically in the %systemroot%\inf directory, custom .adm files may be created for specific application needs. Guidelines for doing this can be found in the Windows .NET Help tool under Creating Custom .adm Files. Application developers can also customize group policies by creating an MMC extension snap-in.

SECURITY SETTINGS

Group security policies apply to nine different areas in the Windows Server 2003 Group Policy Editor. The Security Configuration Editor can be used to compare the system's security policy settings with suggested settings. Security templates located in the %systemroot%\Security\Templates directory can be modified using the Security Templates snap-in tool. They can then be imported to the Security Settings portion of the Group Policy tree. The security group policy settings, illustrated in Figure 8.8, include those listed in Table 8.2.

Table 8.1. Administrative Template Options

Template	Purpose
common.adm	Windows NT 4.0, 98, and 95 policies
conf.adm	Microsoft NetMeeting policies
inetcorp.adm	Language, Dial-up, and Temporary Internet File policies
inetres.adm	Internet policies
inetset.adm	Internet restriction policies
system.adm	Default template with policies specific to Windows Server 2003
windows.adm	Windows 98 and 95 policies
winnt.adm	Windows NT 4.0 policies
wmplayer.adm	Windows Media Player policies

An understanding of security policies would not be complete without a review of Restricted Groups, Registry, and Files System settings.

Restricted Groups

When the Restricted Groups settings are applied to a system, the current group memberships are modified to match them. Only groups listed in the Details window of the Restricted Groups node are affected. Any group added to Restricted Groups has its own member and "Member of" lists. These lists are then enforced on the local system, overwriting group membership assigned by the Active Directory.

To add a restricted group:

If you were to add the Power Users group to the Restricted Groups setting and not include any users in the Members of this group list, the policy would remove current users from the Power Users group. Oddly enough, if the This group is a member of list is empty, no modifications are made to other group memberships. In other words, it is additive only. The restricted group will be added to the groups listed in the This group is a member of field. This policy setting is good for limiting membership to select groups, but it should be used sparingly.

Table 8.2. Group Policy Settings

Security Setting Node	Description
Account Policies	Password policies— uniqueness, maximum age, minimum length. Account lockout— invalid logon attempt. Kerberos policy— ticket lifetime, synchronization.
Local Policies	Audit policy— user rights, local machine security such as shutdown privileges and autodisconnect.
Event Log	Size and time limits for event logs.
Restricted Groups	Designates some security groups to allow only designated members to participate in the group for any length of time; if a nondesignated member is added to the group, the user will be removed.
System Services	System service startup mode (Automatic, Manual, Disabled) modification for the next system boot.
Registry	Security access permissions on portions of the Registry; permissions for the CLASSES_ROOT, MACHINE, and USERS Registry keys may be assigned using security groups or user IDs.
File System	Security permissions for files and folders set and applied when user logs on to the system.
Public Key Policies	Designate trusted root certificate authorities and recovery agents for file encryption.
Software Restriction Policies	Limit applications that can run on a system.
IP Security Policies on Active Directory	IP security level for the system; set software Authenticode, user authentication, and encrypted communication methods.

File System and Registry Policy

Group Policy can be used to set permissions on files and Registry keys. The File System and Registry settings allow the administrator to configure the ACLs on a per file/folder/Registry directory basis.

Right-click the GPO Computer Windows Settings Security Settings Registry node and select Add Key. This produces the Select Registry Key dialog box (Figure 8.11). Three Registry keys can be explored, and permissions may be selectively applied to the key structure.

Right-click the GPO Computer Windows Settings Security Settings File System node and select Add File. This produces the Add a file or folder dialog box (Figure 8.12). The entire directory structure can be explored and selectively assigned permissions.

After an item is selected, security permission (Figure 8.13) can be assigned, as covered in Chapter 10, "Kerberos and the Public Key Infrastructure."

Once permissions have been assigned, inheritance properties are requested. Selecting the Configure option applies the permissions according to these subchoices, shown in Figure 8.14:

• Propagate inheritable permissions to all subfolders and files. This option applies the permissions set to the current object and all child folders and files. Any specific or explicit user or group that has been added to a child file or subfolder is not overwritten. In other words, all permissions that were inherited are replaced with the new permissions, but Joe Engineer, who was given Read privileges on a specific subfolder, still maintains his user right.

• Replace existing permissions on all subfolders and files with inheritable permissions. This option applies the new policy settings to all child folders and files, overwriting all existing permissions.

If Do not allow permissions on this file or folder to be replaced is selected, the current file or folder and its child file and folders are immune to permissions assigned in this GPO. This policy is needed only if a parent to this file or folder has been assigned new permissions within this GPO and you want this branch to keep its permissions and ignore the new settings.

SOFTWARE INSTALLATION: ASSIGNING AND PUBLISHING

The Software Installation and Management feature provides two strategies for distributing software applications throughout the network to the groups in Group Policy. The assign method places a shortcut to the application on the Start menu and loads the application advertisement into the Registry. Applications may be assigned with user or computer settings. Applications assigned via user settings are installed on the local system the first time the application is executed. In this way they maintain consistent application availability for a set of users, who benefit from enhanced desktop usability since their Start menu will always appear the same regardless of where they log on. If the needed application is not already installed on the system the user is using, application installation can be invoked by selecting the application from the Start menu or by opening a file of the application's type. Applications assigned with computer settings will be installed on those systems when booted. Application availability is based on the computer system, not the user.

The second method for distributing software is to publish the application. A published application leaves the software installation up to the user without the aid of shortcuts and local Registry modifications. The user may install a published application by clicking the Add/Remove Programs icon from Control Panel or by opening a file that matches the published application type. An application must be published with user settings so that its availability will follow the user, regardless of which system is used. Software cannot be published using computer settings. Published software does not have the resilient quality of assigned software. If a library or file associated with the application is deleted, the software will not be repaired.

The ability to assign or publish software for group policies relies on the Windows Installer to manage application installation. A software package with an .msi file name contains information necessary to install the application on different platforms, and to deal with previous versions and different configurations. The resiliency of the Windows Installer is a key new feature that rolls back application versions or repairs missing libraries when necessary. Assigned applications modify the Registry and persist on the system even when the user deletes an application or associated libraries. They will be reinstalled or repaired the next time the program is invoked.

Packaging Applications

For a software application to be assigned or published, a package for the software must be obtained in a couple of ways:

• Use a Microsoft Installer (MSI) package from the software vendor or repackaging software to generate an .msi file.

• Use a .zap file to guide software installation.

The MSI package and associated files are fairly straightforward. However, when an MSI package is not available, a .zap text file can be used to add applications using the Software Installer, rather than the Windows Installer, to publish (not assign) them. This of course means that the application will not be resilient or repair itself when damaged. The user instigating the Software Installer must also have access permissions to write to the required installation directories, because, unlike the Windows Installer, the Software Installer is not granted sweeping privileges to make system modifications. The installation procedure will also probably involve user intervention and therefore lead to more handholding and user guidance.

A .zap file requires an application section, designated by line 1, and two required tags on lines 2 and 3. The Friendly Name tag indicates the application name that will appear in the Control Panel Add/Remove Programs utility, and the Setup command is the executable to instigate the application's installation. The following tags are optional and relate to parameters that are displayed in the Add/Remove Programs utility. The Ext marker on line 8 indicates the optional extension section. File extensions specified here will be stored in the Active Directory and linked to the newly installed application. The extension is listed without the period.

line 1: [Application]
line 2: FriendlyName = ECC W2K Starter
line 3: SetupCommand = setup.exe
line 4: DisplayVersion = 1.0
line 5: Publisher = Enterprise Certified
line 6: URL = http://www.EntCert.com/Software
line 7:
line 8: [Ext]
line 9: CUR=

Software Installation Example

The software installation component of the IntelliMirror technology allows the publishing or assigning of software applications to users and computers. As previously discussed, assigning software applications puts the software's icon on the Start menu. The application is then installed when invoked by the user and will "follow" the user wherever he goes within the network. Obviously, software application installation takes time and network resources. If the application is assigned to a computer, the software is installed at the system's leisure, which usually means that installation will occur when the system is booted. Publishing software requires the user to invoke the Add/Remove Programs tool from Control Panel. Software components, published to the user or computer, are listed under the Add New Programs menu. They are then installed at the user's request.

In order to publish or assign software, an MSI package must be obtained for the application from the software vendor. In this example, the Microsoft Office 2000 package is used to assign software to domain users. For more information on the MSI/MST formats, see the Help pages.

Once the user logs on again, on any machine, the software will be installed once activated from the Start menu or accessed by double-clicking a file of the application type from My Computer.

Modifying the Deployment Method

Once the package has been installed on a network share and added to a GPO, its deployment configuration may be further modified. Right-clicking the Software installation node for the GPO that contains the new software package and selecting Properties presents several configuration tabs. The General tab (Figure 8.17) presents product and support information for the application.

The Deployment tab (Figure 8.18) allows configuration of the deployment type, the deployment options, and the user interaction. Under Deployment type, you can change the deployment method, Published or Assigned. The Deployment options include the following configurations:

• Auto-install this application by file extension activation. This option applies only to published applications. It allows you to prevent or allow installation of an application when a user double-clicks a file name with an extension that matches the published application.

• Uninstall this application when it falls out of the scope of management. This option determines whether the application is uninstalled from a user or computer when leaving the scope of the current GPO. If a user no longer falls under the jurisdiction (scope) of this GPO, the application will be removed if this option is checked.

• Do not display this package in the Add/Remove Programs control panel. If this option is checked, the user will not be able to browse for the application and install it from Control Panel. If the user invokes or double-clicks a file name with the application's extension, the application will be installed.

The user interface options determine that the application will be installed using default values (Basic), or they prompt the user for installation configuration information (Maximum).

The Advanced button allows removal of previous installations not governed by group policies. An option also exists to disregard language configuration during the installation.

Upgrades

There are two ways to distribute software upgrades. A mandatory upgrade involves a check mark in the box next to Required upgrade for existing packages (Figure 8.19). This option requires the user to upgrade her current version of the application with the new package. The optional upgrade (clearing check box) allows the user to install the new application version or to continue using the current one. It also permits her to install the new version in addition to her current version and access both through old and new shortcuts.

To add an upgrade package, go to the Upgrades tab (Figure 8.19), click Add, and find the upgrade package in the current GPO (Figure 8.20) or browse the directory by selecting the A specific GPO and clicking Browse. Once the correct GPO is located, select the application package to upgrade from among those associated with that GPO. Then you can Uninstall the existing package, then Install the upgrade package, or select Package can upgrade over the existing package. The Uninstall option is used to replace an existing application with a new one; the Upgrade option is used to upgrade a package with the same product.

Redeploying Software Patches

Once you obtain the new MSI package containing a software fix, replace the old MSI package and associated files with the new package and files on the network share. Select the Software Installation node from the GPO that originally deployed the software and right-click the software package in the Details window. Select All Tasks Redeploy application and click Yes to redeploy the software fix. Regardless of whether the application was published or assigned, the patch will be installed the first time it is started.

Software Removal

Software may undergo either a forced or an optional removal. A forced removal will delete software installed through computer settings the next time the system is booted. The optional removal permits the current application installations to persist but will not allow new installations for the package.

To remove software, select the Software installation node from the corresponding GPO. In the Details window, right-click the desired software package and select All Tasks Remove. The Remove software dialog appears and presents two software removal methods (Figure 8.21). These options correspond to the forced and optional removal strategies, respectively. After you have selected the method, click OK.

File Extensions and Installation

Invoking application installation when a user selects a file of the application's file type is convenient. However, some organizations may have several applications associated with a given file extension. Suppose both Microsoft Office 2000 Premium and Microsoft Office 2000 Standard are deployed using group policies. Right-click the Software installation node for a given GPO and select Properties. From the Extensions tab, access the list by pressing the arrow next to the drop-down box, select an extension, and then assign application priority (Figure 8.22). The application at the top of the list for a selected extension will be installed first. In Figure 8.22, only one office product package has been added to group policies, so no priority decision need be made.

Categories

When the user accesses the Control Panel to Add/Remove Programs, available applications will be listed. Categories can be used to create a hierarchy of application folders to order the software more effectively. Three new categories, Draw Tools, Email Clients, and Word Processors, can classify available applications (see Figure 8.23).

To add categories, right-click the Software installation node for a given GPO and select Properties. On the Categories tab, click Add and type in a new category name. Click Apply and then press OK. The new category will be added to the Active Directory and become available from any GPO in it.

Once the new category name has been made available, software applications may be added to the new category. Add a package by right-clicking a software package in the Details window of the GPO Software installation node and selecting Properties. On the Categories tab, choose a category from the Available categories pane and click Select to add the current package to it (Figure 8.24). In this example, the Microsoft Office 2000 Premium package would be available under the Word Processors category via Control Panel Add/Remove Programs.

Application Modifications

Modifications may be made to customize a software application installation. Different GPOs may apply their own modifications to suit users who require additional features. A transform file or an .mst file is created to indicate application customizations. On the Modifications tab (Figure 8.25), click Add and browse for the desired .mst file.

In order for modifications to be added, the application must be installed using the Advanced published or assigned option from the Deploy Software dialog (Figure 8.16 on page 313). Once an application has been deployed, modifications cannot be added or removed.

Scripts

Group Policy enables assigning scripts to entire domains or OUs rather than modifying each user account and tediously mapping logon scripts to it. The Group Policy scripts execute as follows:

• User Configuration

  • Logon scripts, executed when the user logs on to a system.

  • Logoff scripts, executed when the user logs off the system.

• Computer Configuration

  • Startup scripts, executed when the system boots.

  • Shutdown scripts, executed when the system is shut down.

Scripting group policies for Windows Server 2003 can be found by highlighting the GPO and then selecting Computer Configuration Windows Settings Scripts (Startup\Shutdown) and gponame User Configuration Windows Settings Scripts (Startup\Shutdown) (Figure 8.26).

Windows Server 2003 comes equipped with the Windows Scripting Host (WSH) 1.0, which currently supports Javascript (.js) and Visual Basic Scripting Edition (.vbs) in addition to the MS-DOS command scripts (.bat, .com, .exe). The WSH may also be installed on Windows NT 4.0, 95, and 98 to support modern scripting languages on older systems. Scripts are accessed throughout the network by storing them in the server replication directory %systemroot%\SYSVOL\sysvol\ domainname\scripts. (WSH 2.0 is discussed in Chapter 17.)

Additional policies that affect script performance can be found under Administrative Templates (Figures 8.27 and 8.28). If the WSH is not installed on the legacy systems, scripts may need to run in the DOS prompt window. Selecting User Configuration Administrative Templates System Logon Run legacy logon scripts hidden will minimize the script window or hide scripts from view.

The Maximum wait time for Group Policy scripts (Figure 8.28) and asynchronous/synchronous settings are also helpful for centrally managing script behavior.

FOLDER REDIRECTION

The Folder Redirection policies allow the administrator to relocate several directories in the user's profile (Figure 8.29). Even with roaming user profiles, the profile directories are copied to the local system (%SystemRoot%\Documents and Settings\username) when the user logs on. This can be time consuming and can impact the network, especially for large My Documents folders.

Redirection policies can relocate four user profile directories to a centrally managed network share so that they are not copied to the local system.

The Offline Folder or Cache settings may be set on the network share to allow local system access to these network profile folders when the user's system cannot access the network. The profile information is cached locally and then updated on the network share when the user has access to the share at a later date.