oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Using the Security Configuration Wizard

by Mitch Tulloch

One of the enhancements found in Service Pack 1 for Windows Server 2003 is the new Security Configuration Wizard (SCW), a tool designed to help admins secure their servers against attack. Let's examine this tool and find out what it does, how it works, and how you can use it.

What SCW Does and How It Works

Before I describe what SCW does, let's briefly consider what it doesn't do:

  • It can't be used to lock down any earlier Windows Server platform such as Windows 2000 Server.
  • It can't be used to lock down Windows Server 2003 machines that are not running Service Pack 1.
  • It can't be used to lock down desktop computers running Windows XP or earlier.
  • It's not very good at locking down IIS web servers due to the special requirements for securing such machines.

So what can SCW do, then? Basically, SCW can be used to create security policies that can be applied in various ways to target machines running Windows Server 2003 SP1. Now the first thing you need to be aware of is that security policies are not the same as Group Policy. Specifically, the security policies SCW creates are XML files that are stored by default in the %windir%\security\msscw\policies folder on the local machine. Group Policy objects (GPOs), on the other hand, are complex critters that are stored partly within the Active Directory database itself and partly in the SYSVOL share on domain controllers.

Yet there are close similarities between SCW security policies and GPOs. For example, both types of policy can be used to:

  • Configure audit policies
  • Enable and configure Windows Firewall
  • Configure SMB and LDAP signing
  • Disable unneeded services

Group Policy can be used to do a lot of other things, too, including:

  • Configure domain account policies
  • Secure file system and Registry ACLs
  • Deploy and manage software packages
  • Restrict membership in security groups
  • Deploy Registry-based settings

and so on.

Related Reading

Windows Server Hacks
100 Industrial-Strength Tips & Tools
By Mitch Tulloch

On the other hand, SCW security policies can be used to do some things that GPOs can't do. In particular, SCWs can be used to create policies tailor-made to fit specific server roles such as domain controllers, DNS servers, file servers, and so on.

Now, in fact, Group Policy can be used to secure role-specific servers, and the way it's done is by tailoring Administrative Template (.adm) files to fit each server role and then importing these .adm files into each GPO as appropriate. To make this easier, Microsoft has developed a series of .adm templates designed to harden common server roles and includes these templates with its Windows Server 2003 Security Guide, the highlights of which I've discussed in my blog

What the SCW does, however, is make such role-hardening a snap, as the wizard can detect which roles are currently running on the machine and adjust its port, service, and Registry modification recommendations appropriately for such roles. This doesn't mean that you can forget about .adm files, though. I'll discuss the relationship between SCW and Group Policy more in a moment.

How to Use SCW

While SCW can be used to create and apply a security policy on the local Windows Server 2003 SP1 machine, this "manual approach" for using SCW doesn't unleash its real power. In fact, the best approach for using SCW in an enterprise that has, let's say, dozens of Windows servers running various roles is something like this:

  1. Make sure first that you've grouped servers with similar roles into separate organizational units (OUs); for example, all your file servers are in a File Servers OU, all your print servers in a Print Servers OU, and so on.
  2. Install and run SCW on a prototype server for each role type to create a security policy for that role. For example, run SCW on a file server so it can detect the server's role and can create a policy that can harden that role appropriately.
  3. Apply the security policy you created to a test machine; for example, a clone of a production print server. Test the hardened server thoroughly to make sure the policy doesn't break any functionality on that server.
  4. Use the scwcmd.exe command-line tool with its /transform switch to convert your security policy into a GPO. Then link this GPO to the OU where servers with that role reside, and test your production servers to make sure the hardening hasn't broken any functionality.
  5. If needed, you can further edit the GPO that the scwcmd.exe command created to tighten (or loosen) security for the servers as needed. Or you can leave the SCW GPO as is and create a second GPO linked to the OU, give it higher precedence than the SCW GPO, and configure incremental changes to its settings as needed.
  6. Repeat the whole process with the next server role you want to harden.

Of course, if you have only two or three servers, you may want to simply create and apply security policy to each machine using the SCW running locally on that machine. And if you're lazy, you might decide to skip the testing phase and just see what happens when you use SCW to harden each server. (Presumably, you'll do this Friday evening in case you have to spend all weekend getting things working again!)

You might think running SCW on a production machine without first doing it on a test machine is safe since SCW includes a provision to roll back a security policy you apply--but be aware that SCW may not roll back everything that's done when the policy as applied. In particular, if you've enabled auditing for object access, then SACLs on file system objects are configured by the policy, and there's no provision in Windows Server for rolling back changes to ACLs. And if you import an .adm file into SCW, the Registry changes made may not be completely undone when you roll back your policy, either. So don't skip this testing phase unless you like living dangerously and have enough savings in the bank that you can retire to Bermuda if something goes wrong and you get fired from your job.


I haven't had any problems with SCW since I used it to harden servers on my company network, but there are a number of known issues of different applications breaking when SP1 itself is installed on Windows Server 2003 machines. (See this KB article for info.) What that basically means is, test SP1 rigorously before you deploy it on your production servers, and then decide afterward whether you want to install and use SCW on these machines to harden them or instead manually harden them by following the instructions outlined in the Windows Server 2003 Security Guide.

In the end, it's up to you to decide this, since SCW is an optional component of SP1 that by default is not installed. If you do decide to use SCW though, be sure to read Microsoft's extensive documentation for it, which can be downloaded here from the Microsoft Download Center.

Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.

Return to the Windows DevCenter.