Policy Analyzer

Policy Analyzer [11] displays in a table of security settings from a policy's gpttmpl.inf file and administrative templates from the registry.pol file (Figure 2). Gray fields show values that are not included in the guideline, and conflicts show up in yellow.

Figure 2: Policy Analyzer provides a GPO overview as an Excel sheet.

Policy Analyzer is a very good way of assessing that any template mentioned can be combined in any order because no critical contradictions exist. Whether the security event log is 192MB or 1GB is not critical for the time being. Depending on event forwarding, central logging, and monitoring, the size of the client log may or may not be relevant. Policy Analyzer also shows you how uniformly various manufacturers act in their evaluation of security-relevant settings, and it becomes clear that you need to combine them for the best possible approach, because each manufacturer defines slightly different specifications.

Templates Combined

Microsoft Security Baseline is a must on every network; it forms the basis for all further configurations. You might want to add BSI SiSyPHuS next to take German requirements into account. However, because of its age, you will definitely want to add another template. The structured template and good documentation of CIS is recommended, even if it means some manual work.

The DoD STIG and ACSC configurations are maybe just nice to have, and gp-pack PaT is somewhat isolated in this list because it focuses on a different aspect; however, in addition to hardening, data reduction should be a consideration in your operating system architecture and security strategy.

Handling ADMX Files

When a new variant of Windows Server arrives, updating the ADMX files is one of the first items on your to-do list. The use of a Central Store [12] for the ADMX files has become established: Copy the complete folder C:\Windows\Policydefinitions (or its contents) to \<name of domain>\SYSVOL\Policies\Policydefinitions.

The Group Policy Management Console (GPMC) is designed to search on this path and use the ADMX files stored there to display the administrative templates in the editor. The path is hard coded and cannot be changed. The only exception is a computer on which the administrator manually sets a registry entry to tell the GPMC on that system to use the local store in C:\Windows\Policydefinitions, despite the existence of a central store:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy
EnableLocalStoreOverride=1 (Reg_Dword)

Whether a central store or a local store, at some point you will face the challenge of extending or renewing the ADMX files. One thing I need to point out is that you only replace or extend the templates for configuring settings; don't make changes to existing policies at any point – nothing dire can happen, nothing will ever break. The complete \Policydefinitions folder can be deleted and rebuilt; nothing is lost. Any file contained in it can be copied from a running computer or downloaded off the web. ADMX files are swappable objects that create a file in the policy to store the settings that import the object. How this value makes its way into the configuration file (registry.pol) does not matter to the importing object. (See also the "Additional Registry Settings" box.)

In addition to being able to write entries to the registry.pol file via ADMX, Microsoft provides PowerShell cmdlets that act through the GPMC interface and can modify, delete, or add registry values. It is important to remember this technical possibility, because this is your lifeline if no suitable ADMX file is available. Two useful PowerShell commands are Set-GPRegistryValue and Remove-GPRegistryValue; the syntax is almost self-explanatory. For example, to set or add a value and delete a value, use:

Set-GPRegistryValue -name <NameOfGPO> -key HKLM\Software\<ThirdPartySoftware> -valuename <DBServer> -value <SRV-SQLDB-01> -type <STRING>
Remove -GPRegistryValue -name <NameOfGPO> -key <HKLM\Software\ThirdPartySoftware> -valuename <DBServer>

All in all, the structure of a \Policydefinitions folder only focuses on the configuration options and how they are displayed or documented. It can be updated and exchanged without any problems – or could be, if it weren't for Microsoft's development chaos.