Secure Active Directory With XML-Based Templates

Even if you’re not planning to upgrade to Windows Vista anytime soon, your IT department might use Vista for systems administration. If so, you can take advantage of the improvements Microsoft made to Vista’s Group Policy administrative templates. Vista’s .admx files (Microsoft’s new XML-based format for administrative templates) function differently than previous OSs’ administrative templates.

Group Policy administrative templates, or .adm files, define the registry-based settings that are displayed in the Group Policy Object Editor. The templates are divided into two sections that define computer settings and user settings. These settings appear under the Administrative Templates nodes in the Group Policy Object Editor. You can create your own administrative templates to control registry settings with Group Policy, and add them to a Group Policy Object (GPO) by right-clicking Administrative Templates in the Group Policy Object Editor and clicking Add/Remove Templates. In Windows Server 2008, Group Policy Preferences eliminate the need to create custom administrative templates or scripts to manipulate the registry.

A New XML Format for Vista and Server 2008
The .adm file format hails from the days of Windows NT Server system policies. Vista’s and Server 2008’s .admx files are based (as are other XML-formatted files) on a documented schema—which makes it easier to modify the files and develop applications that can work with the new format. Files in .adm format contain a section where strings are defined for use by the Group Policy Object Editor. The .admx format places that strings section into a separate .adml file, so you don’t need to create a new .admx file for systems that use a different language.

Centralize Storage for Improved Integrity
In Windows 2000 and Windows Server 2003 domains, .adm files are stored locally on domain-joined machines and in Group Policy Templates (GPTs), which are located in the Sysvol directory on domain controllers (DCs). Every GPO consists of a GPT; thus multiple copies of .adm files are replicated to every DC. Versioning of .adm files is controlled by comparing the time and date stamps of the local and GPT copies of the file. If the local .adm file is newer than the GPT version, the local copy is uploaded to the Sysvol directoryand replicated.

This behavior can lead to integrity problems if a local .adm file is corrupt, or to a security problem if someone maliciously modifies an .adm file. You can prevent local copies of .adm files from being uploaded to DCs—and force the use of local .adm files— by enabling the Always use local .adm files for Group Policy editor Group Policy setting under Computer ConfigurationAdministrative TemplatesSystemGroup Policy.

However, this means that .adm files across all administrative workstations need to be kept in sync. Although .adm files can’t be stored centrally, .admx files can be stored centrally in a Win2K or Server 2003 domain and replicated between DCs. Once the store is created, to avoid automatic uploading of .adm files to the Sysvol directory, you should only use Vista or Server 2008 to administer GPOs. The process is optional; however, it’s necessary in Server 2008 domains if you want to use a central store. You should perform the following steps in a test environment only—they enable a preference setting in a GPO that can’t be rolled back by unlinking the GPO.

1. Open Windows Explorer and enter the Universal Naming Convention (UNC) \DomainName.comsysvolDomain Name.compolicies in the address bar, then create a new folder called PolicyDefinitions, as Figure 1 shows.

2. Update Vista or Server 2008 with the latest service pack and patches.

3. Copy the contents of the PolicyDefinitions folder (located in the Windows directory), including the EN-US subfolder, to the new PolicyDefinitions folder on the server.

Vista and Server 2008’s Group Policy tools check for a PolicyDefinitions folder, so any new GPOs that are created and edited exclusively on Vista or Server 2008 and joined to a Win2K or Server 2003 domain where this folder is present will have a GPT without an ADM folder. Figure 2 shows the Administrative Templates node in the Group Policy Management Editor where a central store for .admx files has been detected. To add an .admx template to the central store, you must copy the file directly to the PolicyDefinitions folder on a DC. Once the store has been created, you can secure the administrative templates in the store and the GPOs separately. You can still right-click the Administrative Templates node in the Group Policy Management Editor and add an .adm template, which will appear under the Classic Administrative Templates (ADM) node, but you should avoid this by converting .adm files to .admx format.

Migrating to the .admx Format
If you want to take full advantage of the central store, you can convert your .adm files to the new format, delete the old .adm templates from each GPT on the server, and upload the converted .admx files to the central store. To convert .adm files to .admx, you’ll need to download the free ADMX Migrator tool from www.microsoft.com/downloads/details.aspx?familyid=0f1eec3d-10c4-4b5f-9625-97c2f731090c. Install the tool on an admin workstation and follow these instructions toconvert each .adm file to .admx:

1. Open ADMX Editor selecting All Programs, FullArmor, FullArmor ADMX Migrator from the Start menu.

2. In the left-hand pane, right-click ADMX Editor and select Generate ADMX from ADM on the menu.

3. Select the .adm file you want to convert and click Open.

4. The conversion process will take a few seconds and you’ll be presented with a summary of any errors that were encountered in the Conversion Results dialog box that Figure 3, shows. Click Close.

5. You’ll then be given the opportunity to load the new .admx file into the editor. Click Yes. The new template will now appear in the central pane in the Template box.

6. Double-click ADMX Templates under ADMX Editor in the left-hand pane, right-click the template, and select Save As from the menu to save a copy of the new template in a convenienttemporary location.

Continue to page 2

As Figure 3 shows, the most common error reported during conversion is the absence of a SupportedOn value. This value refers to the OS on which the policy setting is supported. You can safely ignore the errors, or edit the original .adm file and add a value under the Policy entry for the appropriate setting as follows:

POLICY !!L_MRU4Policy
SUPPORTED !!L_MRU4PolicySupport

You also need to add the necessary text at the end of the [Strings] section:

L_MRU4PolicySupport=”Office 2007 or later”

Once you’ve gone through this process for all .adm files that are used to define settings in your GPOs, you should back up the Sysvol directory, then delete the ADM folder in each GPT.

If you still use Win2K or Windows XP on the network to administer Active Directory (AD), you can prevent classic ADM templates from being automatically uploaded to DCs by configuring the Turn off Automatic Updates of .adm files setting. To find that setting, select User Configuration, Administrative Templates, System, Group Policy. You can apply the policy to all users, or target the policy for users who have privileges to create or edit GPOs.

Creating Custom ADMX Files
Despite being slow and not particularly intuitive, the ADMX Editor lets you create and edit .admx files. You might want to create your own template to configure registrybased controls that have no outof- the-box GPO setting. In the following example, we’ll create a custom .admx file that lets us enable or disable TCP/IP SYN attack protection in GPOE. The registry value SynAttackProtect, which can be set to 0 or 1 (disabled or enabled), is located in the HKEY_LOCAL_ MACHINESYSTEMCurrentControlSet ServicesTcpipParameters registry subkey. For information about hardening the TCP/IP stack, visit msdn2.microsoft.com/en-us/library/aa302363.aspx.

1. Right-click ADMX Templates in the left-hand ADMX Editor pane and select New Template from the menu. Name it Securityharden, and click OK.

2. Expand the ADMX Templates node, right-click the Securityharden template, and select New Category from the menu.

3. In the New Category dialog box, double-click the empty box opposite Display Name in the table and enter Security Hardening, as shown in Figure 4, and click OK.

4. The Security Hardening category will now appear under the template node in the left-hand pane. Right-click Security Hardening and select New Policy Setting from the menu.

5. Complete the table by entering the values shown in Figure 5 for Display Name, Registry Key, and Registry Value Name, and click OK.

6. Select Security Hardening in the lefthand pane, then select SynAttackProtect under Setting in the center pane. Select the Value Lists tab.

7. Right-click anywhere in the Enabled Items table and select New Value Item from the menu. In the Value Item dialog box, complete the table as shown in Figure 6 and click OK.

8. Do the same for the Disabled Items table, but change the Value field to 0. Figure 7, shows the completed Value Lists tab.

9. Right-click the Securityharden node in the left-hand pane and select Save As from the menu. In the Save Template As dialog box, enter a suitable path and name (e.g., securityharden.admx) for the new .admx file, as Figure 8 shows, and click Save. This will save the .admx file and .adml file, but place the .adml file in a separate folder called en-GB.

Continue to page 3

For the new settings to appear in GPOE, you need to copy the securityharden .admx file to the PolicyDefinitions folder in SYSVOL, and the corresponding .adml file to the en-US subfolder. Then you need to create a new GPO, enable SYN attack protection, and link the policy in AD:

1. Open the Group Policy Management Console (GPMC) from Administrative Tools on the Start menu.

2. Expand the forest node, and drill down to the Group Policy Objects node for your domain. Right-click Group Policy Objects and select New from the menu. Give the policy a name and click OK.

3. Expand Computer Configuration, then click Administrative Templates, and you’ll see a new category called Security Hardening.

4. Double-click SynAttackProtect under Setting in the right-hand pane of GPOE and you’ll be able to enable or disable the setting, as Figure 9 shows.

5. The red no-entry sign you see in Figure 9 identifies this setting as a Preference; therefore you can’t roll it back by simply unlinking the policy in GPMC. Select Enabled and click OK. Close GPOE.

6. In GPMC, link the new GPO to an Organizational Unit (OU) that contains the machines to which you want to apply the policy, and run gpupdate /force on one of the computers targeted by the GPO.

7. Use regedit to check that the SynAttackProtect value has been added to the registry with the correct parameter, as Figure 10 shows.

Pros and Cons
The real security advantage of the .admx format is its ability to use a central store, but there are other gains, such as reducing the size of SYSVOL and reducing the amount of data that needs to be replicated between DCs. ADMX Migrator is a little slow and buggy, so if you’re familiar with XML, you might prefer to “raw” edit the files, using an XML editor. Before creating or editing an .admx file, you should consider whether you need to allow the registry-based setting to be enabled or disabled from within GPOE, or whether you can import the setting preconfigured into a GPO using a Security Configuration Editor (SCE) template (i.e., .inf file). If you have Server 2008 DCs, a GPP is likely to be the preferred method for manipulating the registry. Think ahead about what you’re trying to achieve, and which method will attain the goal with the lowest administrative cost.