S 2.326 Planning the Windows XP, Vista and Windows 7 group policies

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: IT Security Officer, Administrator

Group policies represent a number of user and configuration settings, which are linked to computers, sites, domains or organisational units (OUs). When using one or several group policies, changes are basically made to the registry of the systems concerned.

Group policies offer an easy way to control the response of clients and, in addition to this, to define security setting as well as login and logout scripts. Using group policies, the response of operating systems can be determined and the access of users can be restricted to specific functionalities of the systems using group policy objects. The group policy objects (GPOs) used in this case contain a predefined set of configuration parameter settings. Each parameter can be set to a specific value that can only be selected from a limited range of possible values under some circumstances. In general, it is also possible to set a parameter to the value not defined. Then, the default settings automatically apply to this parameter.

The policies introduced in Windows 2000 were extended by adding Windows XP-specific contents so that more than 200 new policies were added (with a total number of over 900 policies). This total number of policies has increased to over 3000 policies with the introduction of Windows Vista and Windows 7.

The planning and introduction of client group policies should be carried out based on a standardised process such as the following process:

• Determination of the requirements of client applications and security settings and define the client configuration.
• Decision as to which settings should be administered centrally.
• Test installation.
• Documentation of the settings administered for each group policy (including checklist); adaption of client preparation concept.
• Export of the settings
  
  a. to clients using gpedit.msc, rsop.msc or gpresult
  
  b. or setting the event log filter for GPO events using the domain controller and checking at regular intervals that GPOs do not cause errors and are effective. For this purpose:
• Events can be redirected to an administration server and monitored (z. B. System Center-Server) if necessary or
• can be evaluated on clients using GPLogView.exe (separately available from Microsoft).

The group policies are the primary mechanism for implementing the security settings recommended in safeguard S 4.244 Secure configuration of Windows client operating systems. A local GPO can also be used to set the parameters for a specific IT system or a specific user. When operating in an Active Directory-based environment, GPOs can also be used on the site level, on the domain level, and on the organisational unit level.

The parameters in a group policy object are organised by subject in a tree structure or a structure similar to a file system. In the top level, the parameters are generally divided between settings for computers and settings for users. This allows you to define IT-system-based as well as user-based restrictions. The settings specified in the user part also define application-specific restrictions. If additional administrative templates are imported, other applications such as Microsoft Office can be centrally configured using the group policies. User-specific and application-specific group policies should be used.

The user and IT system parts of a group policy can be deactivated individually so that the part deactivated is not evaluated when the group policy is applied. In some operational scenarios, this can provide an advantage in terms of higher performance. Whether or not an unused part of a group policy should be deactivated should be decided on a case-by-case basis depending on the individual requirements.

When using Windows Vista and Windows 7, the User Account Control (UAC) simplifies the use of local administrator rights for normal users. The administrator rights are always bound to a specific purpose and limited to a period of time, but users could also change security-relevant system settings. Therefore, security-relevant settings should only be configured via group policies of the Active Directory. Thus, they can no longer be changed locally.

Planning local group policies

If group policies are specified, then it is necessary to note that there are differences between local group policies and the policies in the Active Directory. Not all settings available in an Active Directory-based GPO are also available in a local group policy. For example, a local group policy does not contain Kerberos or the system service policies. Individual policies such as Store password using reversible encryption for all users in the domain only have an effect when used in a domain. When specifying individual parameters, the scope of each policy also needs to be taken into account.

Windows versions up to and including Windows XP only support one local group policy per computer. The group policies are processed in the following order:

• local group policies
• site GPOs
• domain GPOs
• GPOs for organisational units (OUs)

Windows Vista and Windows 7 process the group policies in the same order, but offer three levels for processing the local group policies (referred to as Multiple Group Policy Objects or MLGPOs) in the following order:

• policies for local computers
• policies for administrators and non-administrators (user policies only)
• user-specific local group policies (user policies only)

It must be taken into account that the policies for administrators and non-administrators as well as the user-specific local group policies only contain the user policies. Computer policies can only be configured locally using the Local Computer Policy.

Group policy areas

The following areas are available in the computer area of a group policy: Software Settings, Windows Settings and Administrative Templates.

The software settings are especially relevant when used in a domain. With these settings, it is possible to install, update, or uninstall software via the group policies. Consideration should be given to the introduction of Software Deployment Tools for this function. Script policies can be used to specify scripts that will be executed when starting or shutting down the system. This method should be used, since the User Account Control blocks old netlogon scripts.

For the tool-controlled software distribution, Microsoft offers, for example, the Microsoft System Center Configuration Manager 2007 tool. The software distribution using a tool should be preferred due to a higher efficiency and effectiveness as compared to manual distribution.

Security-related settings are administered as a subsection of the Windows settings by selecting Security Settings. The Security Settings are divided into additional areas such as Account Policies (Password Policy, Account Lockout Policy, and Kerberos Policy), Local Policies (Audit Policy, User Rights Assignment, and Security Options), Public Key Policies, Software Restriction Policies, IP Security Policies. The following must be taken into account when specifying policies for security settings:

• Account policies are only enforced in an Active Directory environment at the domain level.
• The use of policies for restricted groups does not prevent group memberships from being modified. However, unauthorised modifications are undone the next time the policies are applied.

New security settings available in Windows Vista and Windows 7 deserving mention include the configuration options provided for the Windows Vista and Windows 7 Firewall as well as those for the User Account Control (UAC).

The Administrative Templates section is used to configure the Windows components, the system, the network, and additional applications.

Application-specific policies

Application-specific policies are defined in the Computer Configuration | Administrative Templates and User Configuration | Administrative Templates sections. It is not only possible to configure Windows components such as NetMeeting, Internet Explorer, Windows Explorer, and Windows Messenger, but also applications that come with their own administrative templates (as in the case of Microsoft Office). Such additional administrative templates must be imported explicitly by the administrators into a group policy.

For most government agencies and companies, it is recommended to utilise all capabilities available for centralising the application-specific configuration. Specifying security-related settings at a central location eliminates a number of security risks. Which components and/or applications will be configured centrally using GPOs must be specified based on the individual requirements. In this case as well, the general rule stating that all unneeded applications and components should be deactivated (e.g. Windows Messenger) is implemented here. The applications and components needed must be configured as restrictively as possible. For example, if Microsoft NetMeeting is needed but Desktop Sharing is not used, then this feature should be deactivated by defining corresponding policies.

Windows Vista and Windows 7 offer significantly more configuration options in the Administrative Templates section than earlier versions, and these new options must be considered during the planning phase. In Windows Vista and Windows 7, the following new security-relevant features of the application-specific policies in particular deserve mention:

• Extended GPO configuration options for the Internet Explorer.
  
  The extensions include in particular the phishing filter, the central activation of the protected mode, and the handling of ActiveX control elements. These application-specific policies are configured in the Computer Configuration | Administrative Templates | Windows Components | Internet Explorer and User Configuration | Administrative Templates | Windows Components | Internet Explorer sections.
• GPO configuration options for BitLocker drive encryption
  
  These application-specific policies are configured in the Computer Configuration | Administrative Templates | Windows Components | BitLocker Drive Encryption section.
  
  TPM-specific policies can be configured in the Computer Configuration | Administrative Templates | System | Trusted Plattform Module Services section.
• GPO configuration options for Windows Defender.
  
  Since Windows Defender was developed primarily for private use and only offers a low level of security, use of the Windows Defender alone for the identification and handling of malware in professional environments should be avoided. The parallel use of Windows Defender with a security or malware solution provided by a third-party manufacturer must be tested in advance in a production environment. Potential problems can be avoided in this case by deactivating the Windows Defender using the application-specific policy Turn off Windows Defender in the Computer Configuration | Administrative Templates | Windows Components | Windows Defender section.

User-specific policies

Windows XP, Windows Vista and Windows 7 (like Windows 2000) also allow you to define user-specific group policies that can then be applied based on the user. This can provide security advantages, especially when used in an Active Directory environment, because restrictions can be defined based on the type of user and the restrictions can differentiate between normal users and administrative users, for example. The differentiation between the various types of users can then be implemented using a suitable OU structure and by defining corresponding group policies. Using the multiple group policy objects available in the extended local group policy available in Windows Vista and Windows 7 (see the section: Planning local group policies), a corresponding differentiation can also be implemented without Active Directory.

The functionality available in the working environment of a user can be restricted in Windows XP, Windows Vista and Windows 7 using group policies. In particular, the Microsoft Management Console (MMC), the Start menu, the task bar, the desktop, the Control Panel components displayed, and the Windows applications allowed at this point by defining suitable parameter values should be configured.

The following restrictions should be applied to the working environment of a normal user whenever possible:

• Only allowed Control Panel components should be displayed
• Most of the MMC snap-ins should be disabled (the Certificate snap-in should be left enabled if certificates are used)
• The use of the Task Scheduler should be restricted
• The Active Desktop should be deactivated or its use restricted
• The items displayed in the Start menu and task bar should be restricted
• The installation and use of removable storage devices (e.g. USB flash memory, USB hard drives, CDs, and DVDs) should be restricted in Windows Vista and Windows 7.

When defining the Run only allowed Windows applications and Do not execute specified Windows applications policies, it must be taken into account that these restrictions only apply to applications started with the Windows Explorer. The start of a "prohibited" application using the Task Manager, from the command line, or from another program cannot be prevented using these settings. However, there are other resources available for this purpose such as the software restriction policies or AppLocker in Windows 7 and higher versions.

In addition, the application-specific policies for restricting the applications/system components should be applied based on the user.

Use outside of Active Directory-based environments

When using Windows XP, Windows Vista and Windows Vista on stand-alone systems or in a Windows NT domain, the central configuration options available through the global group policies are not available. In this case, the local group policies of each IT system must be used to implement the security-related parameter settings defined. This process is based on the mechanism specified in the planning phase for maintaining local group policies on several IT systems.

Use in Active Directory-based environments

When using Windows XP, Windows Vista and Windows 7 systems in Active-Directory-based environments (Windows Server 2000/2003/2008 domains), it is also possible to use local group policies on individual systems. In this case, though, the advantages of the central administration cannot be utilised. Consequently, the Active Directory-based group policies at the site, domain, or organisational unit levels should be used to implement the security settings.

Local group policies should not be used on individual systems if possible because it is difficult to administer local group policies centrally. However, if it is necessary for some reason to use local and Active Directory-based group policies simultaneously, then the parameter settings of all group policies must be configured so they are compatible with each other.

The use of Active Directory-based group policies in the domain (Windows 2000/2003/2008) must be planned accordingly. Additional information on Windows 2000 Active Directory-based group policies is provided in safeguard S 2.231 Planning of group policy under Windows. In general, the following aspects need to be taken into account when using Active Directory-based group policies:

• the OU and group structure in the Active Directory
• the GPO hierarchy in the Active Directory and the GPO concept in general
• the inheritance of group policies
• blocking and forcing GPO overlapping
• specifying the priorities and the order when processing several GPOs
• calculation of the valid settings for a given group policy parameter and the GPO processing order
• controlling the processing of group policies
• links between the group policies
• GPO protection.

In the following, we only provide information and recommendations when they differ from or supplement the information and recommendations provided above.

Windows XP brings changes to the group policy functionality as well as new features. The new features are implemented in the updated client extensions, administrative templates (ADM files), and the updated GPO snap-in. In order to use the new Windows XP-specific features in a Windows 2000 domain as well, the existing Windows 2000 group policies must be updated. They are upgraded by applying new ADM files, and the upgrade is executed when the group policy to be updated is loaded on to a Windows XP domain member using the Group Policies snap-in.

It may be necessary to repeat the upgrade of the group policies under some circumstances when a new Service Pack (SP) is installed on a Windows 2000 domain controller. For example, it necessary to repeat the update of the group policies after installing Windows 2000 SP4.

The administration of the Windows XP-specific policies in the Active Directory should only be performed on a Windows XP domain member. When the standard group policy snap-in in Windows 2000 is used, you can expect compatibility problems which will not affect the function of the group policies, but which could make it more difficult to read and modify GPOs.

Analogous to this, the Windows Vista- and Windows 7-specific policies are administered: In Windows Vista and Windows 7, the standard group policy snap-ins Group Policy Management Console and Group Policy Object Editor, which are used to create and manage group policy objects, have been updated. Windows Vista-and Windows 7-specific policies can only be displayed using the new versions of these administrative tools available in Windows Vista and Windows 7. The administration of the Windows Vista and Windows 7-specific policies in the Active Directory should only be performed on a Windows Vista and Windows 7 domain member.

The computer-specific group policies are applied during the boot process, and the user-specific group policies are only applied when a user logs in. In this case, the user-specific group policy has priority and will override the settings specified in the computer policy, if necessary. The loopback processing mode can be used for Active Directory-based group policies. This mode ensures that it is impossible for user-specific group policies to override a computer policy. This processing mode should be activated especially in cases where the settings were specified specifically for this computer and should always apply regardless of which user is using it (for example when using a Windows XP system in the Kiosk mode). There are two types of loopback processing: Replace and Merge. In the Replace mode, no user-specific settings are taken into account and the computer-specific group policy is applied. The Merge mode merges the settings of the user GPO with the settings of the computer GPO. Whether or not a given group policy should be operated in the loopback processing mode and which type of processing should be used always depends on the corresponding operational scenario and the requirements of the environment present. Depending on the scenario, using this mode can provide security-related advantages, but a general recommendation for its use cannot be provided in this document.

If a GPO is applied to Windows 7, Windows Vista, Windows XP, and Windows 2000 systems simultaneously in a domain, then the applicability of each of the parameter settings to these different systems must be examined. As a rule, specific parameter settings of Windows XP, Windows Vista and Windows 7 will be ignored by Windows 2000 systems. The different responses of different operating systems to the same settings, for example EFS policies (see S 4.147 Secure use of EFS under Windows), also need to be taken into account. It is essential to know which operating system versions offer the settings to be defined in order to avoid potential problems.

When using Windows XP, the way in which the parameter settings of a GPO affect operation differs in different service packs. On systems running Windows XP Service Pack 2, there are additional security settings available that will be ignored by systems on which Service Pack 2 was not installed. The following applies in this case as well: The Windows versions to which the settings to be defined can be applied absolutely must be taken into account when specifying the group policies.

The Security Filtering and WMI Filtering mechanisms both allow you to apply group policies specifically. The Security Filtering mechanism defines the security groups to which a particular group policy applies. By default, a group policy applies to Authenticated Users. WMI Filtering controls the application of a group policy depending on the properties of the IT system (e.g. the operating system, Service Pack version, hard drive space, etc.). It should be noted that Windows 2000-based IT systems do not evaluate the WMI Filtering value specified and that the group policy always applies in this case. In principle, both mechanisms allow flexible control of the application of a group policy to a user or computer object in the Active Directory. However, the use of these mechanisms requires precise planning and adequate testing in advance.

Security templates

The parameter settings in group policies cannot only be specified directly using the corresponding MMC snap-in, but also by importing a security template. Security templates are used to configure the security settings. They are stored as text in policy files (INF files) and can be edited using the Security Templates MMC snap-in or using a normal text editor. Numerous predefined security templates are available for free from Microsoft as well as from third-party providers. Here, Microsoft offers, among other things, the Client (EC) and Specialized Security Limited Functionality (SSLF) security policies.

It is suggested to take the following basic approach:

• An existing security template is selected (e.g. from Microsoft). It is recommended in this case to select a template with a higher security level such as hisecws since it is more advantageous from a security perspective to make "secure" settings less secure when necessary than vice-versa.
• The template must be adapted to the local requirements, and the changes made for this purpose must be documented and reasons provided for the changes.
• The template created is imported into the corresponding group policy. To ensure that all settings are overwritten when importing a security template into a group policy, the Clear this database before importing option should be used.

The security templates can also be used to analyse the security of the settings specified. The settings currently valid on a computer can be compared to the settings specified in an INF file. This comparison can be made using the Security Configuration and Analysis MMC snap-in or the secedit command line tool.

It is possible to reset the Windows XP settings to the default settings using the secsetup.inf security template located in the %SystemRoot%\repair directory.

Defining your own administrative templates

The security-related settings in group policies are not only found in the Windows Settings section, but also in the Administrative Templates section. Administrative templates consist of individual parameters that configure the settings of the associated registry keys. The corresponding ADM files determine the individual parameters that can be configured in the administrative templates. By default, Windows XP comes with several ADM files containing configuration options for the Internet Explorer, for example. It must be noted that the administrative templates only define the setup parameters but no actual settings and therefore should not be used to store and deploy the settings.

In Windows Vista and Windows 7, the ADM files have been replaced by ADMX template files. These files use a new syntax based on XML for the registry-based policies. ADMX files offer the advantage that, in contrast to ADM files, they are language-independent and can be used with any language version in connection with language-specific ADML files.

In contrast to ADM files, ADMX files are no longer loaded individually into each group policy object but are administered in a central store instead. Since the Group Policy Management Console and Group Policy Object Editor group policy snap-ins connect to the PDC Emulator by default, it is recommended in an Active Directory-based environment to place the central store for the ADMX/ADML files in the SYSVOL directory of this operations master.

It is also possible to define your own administrative templates. This approach is particularly recommended when direct registry settings are commonly used in a company or organisation. Since it is only necessary to define an administrative template once in this case, the corresponding registry settings can be comfortably distributed via the Group Policy mechanism. Among other things, this ensures that the registry settings are actually implemented on all target systems.

Testing the group policies defined

The group policies defined must be tested before they are used in a production environment. The tests must guarantee, on the one hand, that the functionality required by the employees is not limited and, on the other hand, that all security-related restrictions are implemented correctly.

Administration of group policies using Microsoft PowerShell

In Windows 7 and higher, it is possible to administer group policies using the PowerShell command line. During login and start, PowerShell scripts can be executed. To secure the PowerShell runtime environment, s04xx2 Securing Windows PowerShell must be taken into account.

Review questions:

• Are the security settings distributed properly to the various group policy objects (GPOs)?
• Is it ensured that the correct group policy objects for Windows XP, Vista and Windows 7 are used on all computers?
• Are the group policies (groups, application-specific, user-specific) of Windows XP, Vista and Windows 7 configured based on need?
• Were all security-related settings in the group policies of Windows XP, Vista and Windows 7 configured?
• Have all unneeded applications and components using group policies been disabled?
• Has a working environment been set up for each user in Windows XP, Vista and Windows 7 that meets the user's needs?
• Are the group policies tested before they are used in a production environment?