S 2.368 Handling of administrative templates under Windows Server 2003 and higher

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

The Windows group policies are an effective and versatile tool for configuring different Windows systems, including Windows Server 2003 or Windows Server 2008. The aspects to be considered before using group policies can be found in safeguards S 2.326 Planning the Windows XP, Vista and Windows 7 group policies and S 2.231 Planning the group policies under Windows.

Interaction between group policies and the registry

Most settings specified in the group policies lead to changes in the registry of a Windows system. The registry is one of the critical core components of a Windows server and needs special protection and special care. The "Testing", "Restoration" and "Documentation" aspects should always be taken into account. Suitable tools must be used for this purpose - the Registry Editor in Windows alone does not cover all of these aspects.

Group policies can be extended using templates from Microsoft or user-defined templates, for example from software manufacturers. These templates, referred to as administrative templates, provide a set of option settings that enter values for specific registry keys automatically in the registry. When used in connection with the Group Policy Management Console (GPMC) and extensive network-based group policy distribution mechanisms (Active Directory) supplied under Windows Server 2003 and higher, administrative templates become a suitable tool for securely handling the registry in Windows Server systems.

It is recommended to only make changes to keys in the registry database using administrative templates and to abstain completely from making manual changes. In terms of change management, manual changes to registry keys should at least be implemented in a user-defined administrative template shortly after the changes are made.

Compatibility of administrative templates

Every version of the Windows operating system released after (and including) Windows 2000 and almost every Service Pack since contains administrative templates from the manufacturer with additional, new option settings that still maintain all options available in the previous versions. This also applies to Windows Server 2003 and higher server versions. The downward compatibility of the new option settings is documented in the templates and is displayed in the GPMC console. The option settings added with the newly introduced operating system versions have no effect on an incompatible Windows version. When you open, for example, a template supplied with Windows Server 2003 on a Windows 2000 Server system, the incompatible option settings will remain invisible and ineffective.

A group policy should always be created based on the administrative template available in the most recent version of the Windows system on which the policy will be used. The respective templates are available on the Microsoft web sites as "administrative templates" in the form of adm or admx files. If a user-defined administrative template for Windows Server 2003 is created, then its compatibility and effects on previous Windows versions must be adequately tested and documented in the template.

New features under Windows Server 2008 and higher

The administrative templates of the adm type introduced with Windows 2000 offer you the ability to also configure Office products in addition to basic settings of the system such as the parameters of the network. In practice, however, the adm files also have disadvantages:

Due to these restrictions, the format of the template files was changed under Windows Server 2008 and Windows Vista and higher. The new, XML-based format admx reduces the disadvantages referred to above. The size of the individual templates was reduced significantly using the XML format. Thanks to the introduction of a central storage location, the template files can be stored and administered at a central location. The local path to the template files can be found in %systemroot%\PolicyDefinitions\.

At the same time, adapted voice packets in the form of adml files were introduced. In general, these files are stored under the folder PolicyDefinitions. On a Windows Server 2008 with a German locale, at least the two language-specific folders de-DE and en-US are available in addition to the language-independent admx files. The adml files referred to are stored in these folders.

New features under Windows Server 2008 R2 and higher

Within the group policy management editor, the administrative templates are displayed under the path Administrative Templates of the node Computer and the node User Configuration.

With Windows Server 2008 R2, the following new features were introduced:

Working with administrative templates under Windows Server 2008 and higher

In general, the templates are not processed or used locally within a domain environment. Usually, a central storage location and a central administration tool are used.

This "Central Store" is a folder to be created under the structure \SYSVOL\domain\Policies. After the folder has been created, the contents of the local PolicyDefinitions or new templates from msi packets are copied to this directory.

The templates can be processed by calling the group policy management editor. This editor displays all templates copied to the central storage location. Since the editor evaluates only this path, it is important to maintain the paths specified by Microsoft.

Migrating existing adm templates

In general, old adm templates are also supported by Windows Server 2008. However, migrating all old adm templates in full is often the more reasonable alternative for consistency reasons. In addition to different products offered by third-party manufacturers, Microsoft offers the ADMX Migrator, a free MMC-integrated tool for migrating the adm templates.

Updating or adding new templates

For the effective use of the templates in existing environments, newly created templates adapted for current systems or for new systems or Service Packs are provided by Microsoft. Updated templates are offered in the form of installable msi packets. Depending on the use of the templates, either locally or as domain template, the storage locations for the import differ.

If the configuration of the administrative templates (admx) of the Windows servers is carried out by a client system, this system must be at least a Windows Vista system with installed administration tools (Remote Server Administration Tools and/or current GPMC).

More detailed information regarding the interaction of templates and group policies can be found in S 2.326 Planning the Windows XP, Vista and Windows 7 group policies.

Updating the operating system

All settings are kept when the operating system is updated and can be managed using the (possibly updated) administrative templates available in the operating system. User-defined templates, including the settings activated in them, remain unaffected and can be administered in the corresponding group policy objects (GPOs).

Using user-defined administrative templates

When a user-defined administrative template is applied, a value is written persistently in the corresponding registry key in the registry for every option setting activated - just like with Windows NT 4 system policies. The registry then needs to be edited manually to remove the key. The settings are referred to as "persistent policy settings" in Windows 2000 Server, Windows Server 2003 and higher, and the effect is referred to as "registry tattooing". After applying such a template, you will only be able to change the value of the key in the GPMC console, for example from 1 to 0 for changing from "Yes" to "No", but you cannot change the key itself any more.

The administrative templates supplied with some Microsoft products, for example Windows 2000/XP/2003 and Office XP/2003, do not have this tattooing effect. These templates are called "fully manageable templates" in Windows XP/Server 2003, and the resulting settings are referred to as true policies. These policy settings are also administered in the registry keys.

HKEY_LOCAL_MACHINE\Software\Policies,

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\ CurrentVersion\Policies,

HKEY_CURRENT_USER\Software\Policies, and

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies

and are stored as .pol files in the file system. It should be impossible to manipulate these policy keys with user-defined administrative templates.

Before applying a template, the system state should be saved (see S 6.99 Regular backup of important system components for Windows Server). Backing up a registry alone is not enough to restore the system to its original state if there are problems with a template. In addition, the functionality and effects of the settings absolutely must be tested beforehand on an isolated test system. The test should take all Windows versions in which the templates will be used into account.

If the settings are to be applied to several servers, then the rollout process must be initiated in a non-critical area of the production environment. The area is to be monitored constantly and checked for correct operation, and then the rollout is to be successively expanded to the critical layers of the production environment. In an Active Directory environment, the GPMC console or, on a stand-alone server, the Resultant Set of Policy console (RSOP console), can be used to check if the options were set correctly.

At a minimum, write accesses to every key created in this fashion are to be recorded in the security log. Enabling object monitoring using the security log is described in S 2.365 Planning of system monitoring under Windows Server 2003. Write privileges are to be disabled for normal user accounts. These settings can be specified manually using the Registry Editor, scripts (see S 2.367 Use of commands and scripts under Windows Server 2003 and higher) or a Windows security template (see S 2.366 Use of security templates under Windows Server 2003).

Deleting user-defined administrative templates

The removal of administrative templates requires just as much administrative time and effort as their installation. If some or all option settings are not used any more in a given administrative template, then the template is usually deleted from the GPMC console and replaced by a modified version, if necessary. However, this does not delete the registry keys, and their values are not even reset. For this reason, all active settings visible in the GPMC console must be documented and then reset to a non-critical value before removing the template from the GPMC console. Non-critical values are values that result in the registry key becoming ineffective. The template should only be removed after a corresponding test for correctness using the GPMC or RSOP console. Reintroducing a template that was accidentally removed will not cause the GPMC console to display the available registry settings even if the registry key or keys are still set and enabled.

To avoid the risk of possible misuse of such orphaned registry keys, all registry keys not in use any more must be protected against reuse. This is only possible in normal cases by deleting the keys. The deletion can be performed manually in the Registry Editor or using a script. Alternatively, access to the keys can be denied and the level of detail in the monitoring settings increased in a Windows security template, but this means more entries will be recorded in the security log, which in turn means it takes more time and effort to evaluate the security log.

Documentation

For minimal documentation of the administrative templates, it is sufficient to state in the system documentation which template files are used on each server (files with the ".adm" extension), their version numbers, and in the case of user-defined templates, their contents. Through appropriate version management and access control for the templates, it should be possible to determine who edited which templates at what times. Furthermore, every option setting enabled, its current value, and the template containing the option must be documented. If the templates are distributed by the Active Directory, then all additional factors determining the effectiveness of the settings for the server or servers must be documented, e.g. the Organizational Unit (OU), security filters, and WMI filters. It must be possible at all times to determine the source of each registry key.

On this basis, the documentation and any necessary concepts for tests, user-defined scripts, and distribution and rollback scenarios arising in conjunction with administrative templates should be created. The documentation should also be used as a basis for the planning of regular evaluations of system and security logs.

The GPMC console is well suited for documenting the active settings as long as Active Directory is being used. Reports can be exported to an HTML file in a printable format for the group policy objects, resultant sets of policy, and group policy models (mark the desired object | select the menu Action | Save Report...).

Review questions:

© Federal Office for Information Security. All rights reserved.