SCW for Exchange Server 2007 – Part II
In Part I of this series, we registered the XML files so that the Security Configuration Wizard could create an apply policies for Exchange 2007 servers. In this part, we’ll create and apply a policy to a server.
It’s very important that all applications and utilities be installed on the server before running the SCW wizard. This includes all antivirus and backup applications, monitoring tools, etc. This is because once the policy is applied, applications installed after that may not work as key services and ports may be disabled. It’s generally a good idea to make sure all other configuration on your Exchange servers is completed, and use the SCW as the last step before putting the server into production.
Before applying a policy, validate your installation by checking event logs and functionality to verify that everything is working as desired. The SCW doesn’t “fix” any broken functionality.
Also keep in mind is that while some of the dialog boxes are a little different when creating policies for Edge Transport servers, the process is the same, and not differentiated any further here. With that in mind, let’s create a policy for a server.
Passwords Haven’t Disappeared Yet
123456. Qwerty. Iloveyou. No, these are not exercises for people who are brand new to typing. Shockingly, they are among the most common passwords that end users choose in 2021. Research has found that the average business user must manually type out, or copy/paste, the credentials to 154 websites per month. We repeatedly got one question that surprised us: “Why would I ever trust a third party with control of my network?
Creating an Exchange server role policy for the Security Configuration Wizard
To run the wizard, you’ll need local administrator access to the server. From the server console, Click Start > All Programs>Administrative Tools > Security Configuration Wizard to start the wizard.
On the Welcome to the Security Configuration Wizard screen, click Next.
Choose Create a new security policy and click Next.
On the Select Server screen, enter or browse for the server you wish to create a policy for, then click Next, as seen in Figure 1. The server you pick will be the baseline server for which the policy is created. If you have multiple servers that are all configured identically, you only need to create the policy once, and then apply it to all related servers.
On the Process Security Configuration Database screen, the wizard will review the server, then click Next, as seen in Figure 2.
On the Role-Based Service Configuration screen, click Next.
On the Select Server Roles screen, verify that the selected roles are, indeed installed, and verify that the unselected roles are not. We’re especially interested in the Exchange roles, as seen in Figure 3 below in my demo server that has the Client Access, Hub Transport, and Mailbox roles installed. Then, click Next.
On the Select Client Features page, verify the installed features. The Wizard is pretty good at determining what’s running, but feel free to check boxes that you think are necessary. Click Next, as seen in Figure 4.
On the Select Administration and Other Options screen, verify the Installed options, then click Next, as seen in Figure 5.
On the Select Additional Services screen, verify any additional features that are installed. As we see in Figure 6 below, .Net 2.0 and Virtual Server features are installed on my demo server. Then click Next.
The wizard will then ask what you want to do with unknown or unspecified services that it finds. The options are Do not change the startup mode of the service (basically, ignore it), or to Disable the service. You can manually change these later, if you wish, and this has more to do with applying this policy on other servers that may have services not found on the baseline server. When finished, Click Next, as seen in Figure 7.
The wizard then presents a list of changes it will make when the policy is applied. The View pull down allows you to look at Changed Services and All Services. Take time to go through the list of Changed Services so that you understand what changes will be made when the policy is applied.
After you’ve reviewed all settings, click Next, as seen in Figure 8.
Next comes Network Security, where we can make port configuration changes to the Windows firewall. Click Next, as seen in Figure 9.
The wizard presents the currently used ports in the Open Ports and Approve Applications screen. Verify that you desire to have these ports open. I rarely need to make changes here, but it’s still a good idea to look over the list. Then click Next, as seen in Figure 10.
On the Confirm Port Configuration screen, we verify the changes presented from the previous screen, and click Next, as seen in Figure 11.
On the Registry Settings screen, click Next.
On the Require SMB Security Signatures, check both check boxes, All computers that connect to it satisfy the following minimum operating system requirements, and It has the surplus processor capacity that can be used to sign file and print traffic, and click Next, as seen in Figure 12.
Under Outbound Authentication Methods, verify that Domain Accounts is selected, and all other boxes are cleared, as seen in Figure 13. Then, click Next.
On the Outbound Authentication using Domain Accounts, select the Windows NT 4.0 Service Pack 6a or later operating systems box, and clear the other box unless this server is a domain controller holding the PDC emulator FSMO role (which isn’t recommended). Then click Next.
On the Registry Settings Summary screen, verify the proposed settings, and click Next, as seen in Figure 14.
The Audit Policy section of the SCW wizard will configure how the Exchange server will conduct auditing. On the Audit Policy screen, click Next.
On the System Audit Policy screen, choose the option that best matches your organization’s security requirements for auditing events. I don’t recommend choosing the top option, Do not audit. The choices are listed in increasing levels of auditing. Keep in mind that as the level of auditing increases, so does the work the server must perform to record those events. When you’ve chosen your desired setting, click Next, as seen in Figure 15.
In the Audit Policy Summary screen, verify the proposed changes, as seen in Figure 16. When finished, click Next.
On the Internet Information Services screen, click Next.
On the Select Web Service Extensions for Dynamic Content screen, verify that all required services are checked. For a typical Exchange server, this includes ASP.NET v2.0.50727, Microsoft Exchange Client Access Server, and Microsoft Exchange Server. When finished, click Next, as seen in Figure 17.
On the Select the Virtual Directories to Retain screen, choose which virtual directories need to be allowed as a part of any additional applications. For a typical Exchange 2007 server, none need to be checked as seen in Figure 18. When finished, click Next.
On the Prevent Anonymous Users from Accessing Content Files screen, make sure the one checkbox is NOT checked, as seen in Figure 19. If you check this box, you’ll block access to features such as Outlook Web Access. Then, click Next.
On the IIS Settings Summary screen, verify the proposed changes. If you need to change these, click Back. When finished, click Next, as seen in Figure 20.
Click Next on the Save Security Policy screen. Give the policy a name and description. If you plan to apply this policy to more than one server, you may wish to save the file to a network share. Click Next, as seen in Figure 21.
At this point, the wizard will ask if you want to apply the new policy now or later. As seen in Figure 22 below, applying the policy will generally require a server reboot. If you can’t reboot now, choose Apply Later.
If you choose Apply now, the wizard applies the changes from the policy to the server as seen in Figure 23 below. When it finishes, click Next.
When the wizard finishes, click Finish as shown in Figure 24. The wizard will not prompt you to reboot the server. You must manually reboot the server.
When the server has rebooted, take time to verify that all services and features are working as designed. Check the event logs for errors or warnings, and validate that email is flowing as desired. If all went well, you can rest assured that your Exchange 2007 server is now much more secure.
In this part, we’ve created a security policy and applied it to the local server. In the next part, we’ll apply the policy to other servers, as well as take a look at rolling back a policy.
About Pat Richard
Pat Richard is a Senior Consulting Engineer for Mimosa Systems. Pat has been working with messaging environments since the MS Mail days, and spends a majority of his time designing and implementing enterprise messaging solutions based around Microsoft Exchange. Complex migrations and implementations, as well as large scale upgrades, are his specialty. Several years ago, he was given the Microsoft MVP award for his contributions to the Exchange community. A published author, Pat continues to be active online, assisting others with Exchange-related issues.
Recent Exchange Forum threads
Got a question? Post it on our Exchange Server Forums!