Windows Server 2003 : Creating and Enforcing Security Policies (part 1) - Using Security Policy Templates

12/21/2011 9:06:41 AM

If you haven't yet upgraded to Service Pack 1 and are still interested in distributing a comprehensive, consistent security policy to your machines, Windows Server 2003 comes with two basic tools that will help you do just that: security templates and the Security Configuration and Analysis tool. While they aren't as easy to use or as manageable as SCW-based policies , they are certainly as effective. Another bonus point: your investment of time and resources in creating these templates isn't wasted, as you can include them in any future SCW policies that you might create.

1. Using Security Policy Templates

Security templates list all possible security attributes and settings for a given system and their associated configurations. By using the Security Templates snap-in, you can easily provision a standard collection of security settings across multiple systems using either remote registry editing or Group Policy. For administrators that have a large number of systems to manage, and for those who provision quite a few systems on a regular basis, security templates can save a lot of time: they can assist with setting up a new machine or rolling out a new organizational security policy to many systems. They're also helpful because you can define multiple templates, since few large organizations have a single security standard for all computers. Security policy templates are a tool your organization can use to implement the three facets of the CIA triangle.

You can begin using security templates by loading the Security Templates snap-in:

Run mmc from the command line to load the MMC in author mode. Author mode allows you to construct new consoles from scratch and add snap-ins to them.
From the Console menu, select Add/Remove Snap-in. Then select Add. This opens a dialog box entitled Add Standalone Snap-in.
From the list, select Security Templates, click Add, and then click Close.
Click OK in the next box to confirm the addition of the snap-in.

You now have the Security Templates snap-in added to a console. From this snap-in, you can expand the Security Templates section in the console tree on the left, and then expand the C:\Windows\security\templates folder to view the predefined security templates.

The Security Templates snap-in contains seven configurable areas, which you can display by double-clicking the label in the righthand pane inside the snap-in after selecting a template from the list in the lefthand pane. The areas are shown and described in Table 1.

Table 1. Template policy areas
Framework area	Description
Account policies	This area applies security configuration to user accounts, including passwords, account lockouts, and Kerberos ticket policies. Password and account lockout policies apply to workstations and servers; Kerberos ticket policies apply only to domain controllers.
Local policies	This area allows you to set auditing and event logging policies, user rights assignments, and registry keys that directly affect system security. It also controls auditing of events, including application actions and security notifications. Note that settings in this area apply to all Windows 2000 or later systems, and not to only a specific kind of system.
Restricted groups	This particularly useful area allows you to define policies regarding a user's membership into security groups that allow elevated privileges. It's simple to define a policy where domain users can never be a member of the local Administrators group; other policies are equally easy.
System services	This area contains startup options for services and access controls on them.
Registry	In this area, you can configure access permissions on specific keys in the registry. In addition, you can audit access and modification of registry entries.
File System	This area allows you to preconfigure access permissions on selected file system directories.
Event Log	In this area, you can specify how the Application, Security, and System event logs fill and rotate and what their maximum size might be. You also can configure who has access to view the logs.

Each template is nothing more than an ASCII text file with a .INF extension that contains a list of all settings therein. Looking at the file itself is often a more useful and quicker way to determine applicable settings. For example, the following is a portion of the HISECWS.INF file:

    [Profile Description]
    %SCEHiSecWSProfileDescription%
    [version]
    signature="$CHICAGO$"
    revision=1
    DriverVer=10/01/2002,5.2.3790.0
    [System Access]
    ;----------------------------------------------------------------
    ;Account Policies - Password Policy
    ;----------------------------------------------------------------
    MinimumPasswordAge = 2
    MaximumPasswordAge = 42
    MinimumPasswordLength = 8
    PasswordComplexity = 1
    PasswordHistorySize = 24
    ClearTextPassword = 0
    LSAAnonymousNameLookup = 0
    EnableGuestAccount = 0
    ;----------------------------------------------------------------
    ;Account Policies - Lockout Policy
    ;----------------------------------------------------------------
    LockoutBadCount = 5
    ResetLockoutCount = 30
    LockoutDuration = -1
    ;----------------------------------------------------------------
    ;Local Policies - Security Options
    ;----------------------------------------------------------------
    ;DC Only
    ;ForceLogoffWhenHourExpire = 1
    ;NewAdministatorName =
    ;NewGuestName =
    ;SecureSystemPartition

The compatible security template, COMPATWS.INF, is meant to allow non-Microsoft certified applications to run on a system without being inhibited by security features. It discerns between ordinary users, who can run only certified Windows applications (those earning the compatibility seal that's usually displayed on the software packaging), and power users, who can run uncertified and potentially problematic software. It also allows a certain subset of registry keys, initialization files, and other folders to be modified by otherwise unprivileged users. However, it's really not the most secure template to use, and I'd advise using another, more secure template (as I describe in a bit) unless you're running into impassable compatibility problems.

The secure security templates--SECUREWS.INF for workstations and ordinary servers and SECUREDC.INF for domain controllers—are designed to provide a middle-of-the-road level of security. The secure templates offer more stringent password policies, restricted guest access, audit policies that cover most important security events, and increased account lockout policies. However, files, folders, and registry keys and their security settings are not configured with this template because, for the most part, they are configured securely out of the box. For your environment, you might want to modify this to include custom permissions for certain directories and registry keys. You might use this if you have a sensitive application (say, a mortgage loan origination program) that has credit-report data stored locally. You can customize the template to secure this program's data directory by default.

If you are just starting to focus on security within your business, and you have applications that are up-to-date and in their latest release, try using these secure templates. They really batten down the hatches as opposed to the compatibility template, and they're a good place to start when tightening configurations on your network. Be aware that older applications that use insecure methods to communicate over the network might fail, though.

The highly secure template—HISECWS.INF for workstations and ordinary servers and HISECDC.INF for domain controllers—focuses on securing transmissions between workstations and servers running Windows Server 2003. It also removes the Authenticated Users group (and any other groups for that matter) from the Power Users group on all machines that use this template. Use this template only if you know your applications won't break with the stringent restrictions on network communications.

Finally, the default security template, SETUP SECURITY.INF (note the space), restores the default security settings for an initial installation of Windows. You can use this to restore the initial settings for a client computer or regular server if you have misapplied a template or you want to start "from scratch." However, you cannot do this for domain controllers. For more information on this, see:

http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/windowsserv/2003/standard/proddocs/en-us/sag_SCEdefaultpols.asp

1.1. Creating a custom security template

You might want to make your own customized policy modifications that go above and beyond those made in the templates shipped with Windows Server 2003. Creating a custom security template affords you an easy way to package, deploy, and apply these modifications with a minimum of administrative headaches. Best of all, you can use these templates in conjunction with a utility called the Security Configuration and Analysis Tool (SCA) to assess the overall "hardness," or state of security, of your machines.

To create your own security template, follow these steps:

In the Security Templates console, expand Security Templates in the tree pane on the left, and right-click C:\WINDOWS\security\templates (this is the default templates folder in the system).
Select New Template from the context menu that appears.

Now you can make any policy modifications you want in any one of the policy areas supported by the tool: account policies, local policies, the event log, restricted groups, system services, the registry, and the file system. Your additions, deletions, and other changes are saved in the template immediately.

To take this one step further, you might decide to build on the basic policy settings provided by the templates shipped with Windows Server 2003. In that case, it's quite simple to open one of the default templates, resave it to a different name, and make further modifications to create your own custom template. To do so, just follow these steps:

Select an existing template inside the Security Templates console. In this example, I'll use the securews.inf file.
Right-click the existing template, and click Save as...from the context menu.
Give the new template a name, as shown in Figure 1.
Click OK. The new template is created with the settings from the old basic template.

Figure 1. Creating a new security template

1.2. Importing a template into a GPO

One of the most common ways to apply a security template to many machines is by importing the template into a GPO. The following steps describe how to do it:

Select the GPO you want to use inside Group Policy Object Editor.
Navigate through Computer Configuration → Windows Settings → Security Settings.
Right-click Security Settings and select Import Policy from the context menu.
Select the appropriate security template from the list of .INF files, and then click OK.