Executive Summary: Use the Microsoft Exchange Server 2007 XML files Exchange2007.xml and Exchange2007Edge.xml with Windows Server 2003 SP1’s Security Configuration Wizard to secure your Exchange environment.

When Microsoft originally created the Security Configuration Wizard (SCW) as part of Windows Server 2003 SP1, it was intended primarily as a utility for helping network administrators to secure Windows. Even so, the wizard benefited Exchange Server administrators, because Exchange depends on Windows. After all, if Windows isn’t secure, then Exchange won’t be secure either.

When Microsoft created Exchange Server 2007, the company included a couple of XML files that can be used to extend the SCW. These files let Exchange administrators use the SCW to secure Exchange, not just Windows. In this article, I’ll show you how to install and configure the SCW, as well as how to use it to secure an Exchange server.

Installing the Security Configuration Wizard
Because the SCW was initially introduced in Windows 2003 SP1, you must install SP1 or a subsequent service pack in order to install the wizard. However, simply applying a service pack doesn’t install the SCW.

After the service pack is installed, start the Control Panel Add/Remove Programs applet. In the Add/Remove Programs dialog box, click Add/Remove Windows Components. You’ll see a list of various Windows components. Scroll through the list until you find the Security Configuration Wizard option. Select the corresponding check box, and click Next. Windows will then begin copying the necessary files. Depending on how your server is set up, you might be prompted to insert your Windows installation CD-ROM. When the file copy process is done, click Finish to complete the installation.

Adapting the Security Configuration Wizard for Exchange
After you install the SCW, you must adapt it for use with Exchange Server. To do so, insert your Exchange 2007 installation media and navigate to the Scripts folder.

Next, you need to locate the following two files: Exchange2007.xml and Exchange2007Edge.xml. You can use these two XML files to extend the SCW to support Exchange 2007. You must copy these files to the server’s \%windir%\security\msscw\kbs folder.

The two XML files are security template files that are designed to make the SCW Exchange 2007–aware. The Exchange2007. xml file can be used for securing any Exchange 2007 server so long as it isn’t hosting the Edge Transport server role. Microsoft created a completely separate XML file, Exchange 2007Edge.xml, to assist you in securing Edge Transport servers. As you probably know, an Edge Transport server operates at the network perimeter and therefore has very different security needs from that of Exchange 2007 servers hosting other roles—which is why Microsoft created two different XML files.

A benefit of the SCW is that it can be used to secure remote servers. I therefore suggest that you register both XML files with the SCW, so that you can use the wizard to secure any Exchange 2007 server. To use the SCW, you must be a member of the Exchange Server Administrators group and the local Administrators group for the target server.

You need to register the XML files before the SCW can use them. Registering the files is simple. To do so, open a command prompt window, and enter the following commands:

CD\Windows\SYSTEM32
SCWCMD Register /kbname:MSExchange /
  kbfile:%windir%\security\msscw\kbs  Exchange2007.xml
SCWCMD Register /kbname:MSExchangeEdge
  /kbfile:%windir%\security\msscw\kbs  Exchange2007Edge.xml

Figure 1 shows the result of running these commands.

Securing Exchange Server 2007
Now that you’ve installed the SCW and registered the necessary XML files, it’s time to use the wizard to secure an Exchange server. For the purposes of this article, I’ll show you how to use the SCW to secure a regular Exchange server (not an Edge Transport server). If you need to secure an Edge Transport server, the procedure for doing so is very similar, aside from some obvious differences (e.g., not belonging to the Active Directory—AD—that the rest of Exchange belongs to).

To launch the SCW, select it from the server’s Administrative Tools menu. The wizard’s Welcome screen will open and will present you with several warnings.

The first warning explains that you can use the SCW to create a security policy that can be applied to any server on the network, and that the various servers and security settings that are applied will be based on your server’s roles. However, you must keep in mind that the wizard doesn’t actually configure a server to perform a certain role. Configuring a server’s role is up to you. The SCW’s job is to create a security policy that is appropriate for the server based on its roles.

Another issue that you need to be aware of is that the SCW doesn’t automatically detect the server’s roles. Instead, the wizard will ask you which roles the server is performing. If you answer the wizard’s questions incorrectly, then the security policy might not be stringent enough, or it might be so strict that it prevents some necessary services or applications from running.

One thing that the wizard does detect automatically is which inbound ports are in use. Therefore, it’s important that any applications or services that listen for inbound traffic are running before you run the wizard.

To get started configuring the wizard, Click the Next button on the Welcome screen. You’ll see a screen that asks if you want to create a new security policy, edit an existing security policy, apply an existing security policy, or roll back to the last security policy that was applied.

The option of rolling back to the last applied security policy can be a real lifesaver. If you happen to make a mistake and apply a security policy that is too restrictive, you can rerun the wizard and use the rollback option to return your server to normal. Although rolling back the security policy is no substitute for having a good backup, it’s a nice option if you need it.

To configure the SCW initially, select the option to create a new security policy. After you click Next, you’ll see a screen asking you which server you want to use as a baseline. The wizard will create a security policy based on the server’s current settings, as well as on how you answer the wizard’s various questions. After you create a baseline policy, you can apply the policy to the server that you used to create it, or you can apply the policy to any other server.

A minor issue that I noticed while writing this article is that if the server you’re running the SCW on is running Windows 2003 SP1, then the wizard will insist that your target server also be running SP1—even if the target server is running SP2. Upgrading the server that the wizard is running on to SP2 seems to fix the problem.

Regardless of which server you choose to apply the policy to, you must have administrative permissions on the server. If the account that you’re using doesn’t have administrative privileges, you can click Specify User Account to provide an alternative set of credentials.

After you click Next, the SCW will process the security configuration database. When this process completes, click View Configuration Database to see all the server roles that the SCW is aware of. Although you can’t make any selections on this screen, you should at least verify that the SCW is Exchange 2007– aware. If the various Exchange 2007 roles appear in the list, then you registered the two XML files correctly.

Close the list of supported server roles and click Next. The following screen will inform you that you’re about to begin configuring the security policy based on the server’s roles, and that specifying incorrect roles can cause the server to stop functioning. In light of this warning, I highly recommend that you create a full system backup of the server before you continue.

Click Next to see a list of the roles that are currently installed on the server. The wizard does its best to try to identify the Windows server roles that are currently installed. Still, you must work through the list and ensure that all the roles that are important for the server are selected. Take your time going through the list, because making a mistake might cause the server to not work correctly.

Click Next, and you’ll see a list of the installed features. The basic concept behind this screen is that every Windows server also acts as a workstation in some capacity. The items in this list are the workstation components (called client features) that are currently installed. Again, go through the list carefully and make sure that the features you intend to use are selected before clicking Next.

At this point, the wizard will display the Administration and Other Options screen. This screen lists services and components that are related to performing administrative tasks on the server. Again, the wizard does a fairly good job of anticipating which of these services and components you’ll need, but you need to go through the list yourself and make sure that all the necessary components and services are selected.

The next screen lists the additional services that were detected while processing the security configuration database. Typically all the additional services that were detected will be selected, as Figure 2 shows.

In some cases you might not want to select all the services that were detected. In such a case, you should quit the SCW, uninstall the unwanted software, and then work through the wizard again.

Because the SCW might occasionally not detect a service that’s on the server, the wizard asks you to decide what you want to do if an unspecified service is detected. The wizard gives you two choices: You can disable the service, or you can allow the service to run as originally intended (by using the Do not change the startup mode of the service option).

Click Next to see a summary of all the services that have been detected. The summary displays the service’s current startup mode and what the startup mode will be after the new policy takes effect. I recommend that you take some time to meticulously look through this list, to make sure there are no mistakes.

When you’re satisfied with the changes that will be made, click Next to go to the wizard’s Network Security screen. This screen informs you that the wizard is about to configure the Windows firewall based on the roles your server is hosting. The screen contains a check box that you can use to completely skip the network security configuration. Assuming that you want to secure the network, click Next.

You’ll see a screen similar to the one in Figure 3. As you can see in the figure, the screen lists various ports and asks you which of the ports you want to open. Initially, all the ports appear to be selected. However, if you scroll through the list you’ll see that some ports are not selected by default— especially ports related to Exchange Server. You’ll need to examine each port individually and decide whether you need to enable the port.

Click Next to see a summary of the ports that were detected, as well as what the port status will be after the new security policy is in place. Ensure that everything in the list is correct, and click Next again.

You’ve now reached the wizard’s Registry Settings section. This section lets you specify which protocols can be used to communicate with other computers.

Click Next to go to the SMB Security Signatures screen, which Figure 4 shows. As you can see in the figure, the registry is configured based on which check boxes you select. You must indicate whether the other computers on the network meet minimum OS requirements, as well as whether the server has sufficient processing power to digitally sign all file and print traffic. The first check box asks whether the other computers that the server communicates with meet certain OS requirements, which are listed below the check box. The second check box asks whether the machine has the necessary power to digitally sign file and print traffic. Selecting both check boxes enables Server Message Block (SMB) security signatures.

The next screen asks which methods the server uses to authenticate with remote computers. Typically, domain accounts are the sole authentication mechanism. However, you can specify that local accounts or file sharing passwords be used.

The screen that you see next will vary depending on the options you chose on the previous screen. Assuming that you selected the Domain Accounts option, you’ll be asked to verify that all the domain controllers (DCs) are running Windows NT 4.0 with SP6A or a more recent OS. The screen also asks you to confirm that clocks are synchronized with the selected server’s clock.

Click Next to go to the screen that displays a summary of the options you’ve chosen within the Registry Settings section. If all the settings seem to be correct, click Next to continue.

The wizard will now take you to the Audit Policy section. Clicking Next will display a screen that asks you to determine your audit policy. You have the option of not auditing anything, auditing successful activities, or auditing successful and unsuccessful activities. Make your selection and click Next to go to a summary screen that shows which events will be audited when the new policy takes place.

The wizard then takes you to the Save Security Policy section. Click Next again, and you’ll be asked to provide a name and an optional description for the policy you’re creating. The screen also contains a View Security Policy button that you can use to generate a report of all the security options you’ve selected. You can use this report to verify one last time that all the security settings are correct.

Click Next, and you’ll see a screen asking if you’d like to apply the policy now or later. If you choose to apply the policy now, you’ll need to reboot the server. After you make your selection, click Next followed by Finish to complete the wizard.

Harden Your Environment
Windows 2003 SP1’s SCW was originally designed to help secure the Windows OS. But two Exchange 2007 files, Exchange2007 .xml and Exchange2007Edge.xml, let you extend the SCW to secure Exchange in addition to Windows. Installing and configuring the SCW and registering these XML files make the SCW Exchange 2007–aware and thus make your entire environment more robust.