If you’ve already learned that Windows Server’s security templates are beyond mortal ken, you may not have held off inflicting them on your enterprise.
Their difficulty is a result of their flexibility, so if you can manage their flexibility, they cease to be the sole domain of gurus.
Behind templates lies a simple concept: wrap multiple security settings in a single file and apply the file to many computers on an enterprise network. To simplify mixing and matching company-wide, department-wide, location-wide and job-function-based, security settings across a company, Microsoft made security templates cumulative. That cut the number of templates you might ever have to create but introduced the problem of working out which template is applying which setting.
Knowing what effect each setting actually has on a computer is another hard-to-learn pearl of guru-dom.
Microsoft Windows includes two tools to make these tasks easier. The Security Configuration and Analysis (SCA) snap-in shows the effect that each setting in a template will have. It also allows you to apply new templates to an existing set of templates - collectively called a security database - and to see, more or less, visually what their cumulative effect will be.
The secedit.exe tool does the same thing from the command line, with the added spice of helping you deploy templates. While not so hot at SCA-style “show and tell” visuals, secedit can be driven by scripts - so it can apply templates to multiple computers without inflicting a devastating case of mouse-finger.
It’s not easy to find these tools. The only visible security template management tools on an Active Directory-installed server install are Domain Controller Security Policy and Domain Security Policy.
Find the SCA tool by creating a Microsoft Management Console (MMC) by entering MMC at the command line and using the Console, then the Add menus to find the SCA in the default list of MMC snap-ins; when you’ve added the SCA snap-in, save the MMC as a “security tools.msc”. It will now be available in Windows Servers’ Administrative Tools menu.
To get to the meat of analysing security settings we’re going to skip over the "how to" details that are visible in the SCA tool’s inline instructions. They are very visible and speak for themselves.
From the SCA, create a new database and name it. Note that it will be saved with an .sdb file extension. Once you save it, follow the “Import template” wizard that will automatically start up. When asked, import the security template called hisecws.inf, which tightens password restrictions on workstations.
Importing hisecws.inf will not apply hisecws to your computer; it will merely allow you to analyse what settings it would impose and how those settings differ from the computer’s current settings.
Analysing the security database you added hisecws to is easy - the inline instructions tell you how. But comprehending the analysis is harder. Try drilling down in the left hand SCA pane from “Account Policies” through to “Password Policy”. On most Windows Server 2003 default installs, you should see two out of six icons showing red warning signs in the right hand pane. These settings - minimum password age and minimum password length - are the settings that would be made stricter if you applied the imported template to the machine.
Call it play or call it study - this exercise is among the most valuable tests you can do on Windows machines. Once you see it, you will realise that you now know how to predict the impact of applying any security template files in C:\WINNT\security\templates. You now have the skills to take the scary-looking “hisecdc.inf” and “DC security.inf” templates, that look as though they could damage vital domain controllers, and test them against any DC’s current settings.
Getting to this point leaves you with only two things to learn: how to apply the security database to a machine and how to apply, efficiently, the database to many machines.
To apply the database to the machine you are working on, right-click the SCA icon in SCA’s left-hand pane and simply choose the “Configure Computer now…” option - easy.
To apply the database to many machines, you should first export the security database as its own security template (by right-clicking the SCA icon again and choose the “Export Template…” option). By default it will save the database you have created as a template file with an .inf extension in the C:\WINNT\security\templates directory - just like the default templates.
The easiest way to deploy the template to a range of machines is to create a Group Policy Object (GPO) in Active Directory, import the newly-created security template file into the GPO, then link the GPO to a site, a domain, or an organisational unit. How to manipulate GPOs is too big a subject to detail here, but it is very well documented on the Web.
Less well documented but just as efficient is to use the server’s built-in secedit.exe tool to apply security databases on an enterprise-scale via scripts. Note that secedit takes a security database as its input file, not a template file.

If you were deploying the database you created at the start of our example above, you would use the .sdb file that you created prior to importing the template file.
Include the command:

secedit /configure /db 

in unattended install scripts or in logon scripts after making sure the .sdb file is available to the machine running the script from a network share.
The /areas switch limits the security changes to each machine’s file system, registry and system services settings, which prevents errors blocking the script. The /quiet switch prevents commands from being output to users’ screens when the script runs.
Managing security template configuration and rollouts in enterprises is a huge task and one that many sysadmins put off out of fear of mistakes, or pay consultants to manage.
But getting to know the SCA and secedit are the start of a journey into truly owning your network’s machines.

Key rules:

  • Where there is a conflict in security settings applied by two different security templates, the latest applied setting will dominate.
  • Document the function of each template you deploy.
  • Analyse each server’s security settings against your baseline templates every three months.
  • After business changes, ask if your security templates continue to meet your objectives.