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.
Before I describe what SCW does, let's briefly consider what it doesn't do:
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:
Group Policy can be used to do a lot of other things, too, including:
and so on.
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 ITreader.net.
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.
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:
/transformswitch 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.
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.
Copyright © 2009 O'Reilly Media, Inc.