The Security Configuration Wizard (SCW) first appeared in Windows Server 2003 Service Pack 1. It helps organizations reduce the attack surface on production servers.
Much has changed since Microsoft first launched the Security Configuration Wizard. Back in the days of Windows 2000 and Windows XP, Windows wasn’t considered secure out-of-the-box. Today, with the exception of highly sensitive deployments, Windows client and server are pretty secure from the get go. Only ill-advised reconfigurations, such as disabling User Account Control (UAC), make the OS less secure than it could be.
Despite the vastly improved security of Windows Server since SCW was first included in the OS, it can still be used to improve security and ensure that servers are configured using an identical security policy. SCW isn’t the only free tool from Microsoft that can help organizations achieve this but SCW is best suited to small and medium sized organizations with limited IT support on hand.
Modifying security settings from the default settings presents risks of creating application compatibility or network connection problems. In the worst case scenario, you could lose access to a remote server. This would be especially catastrophic if it is located in a remote datacenter with no Integrated Lights Out facility.
Any security policies created using SCW should be thoroughly tested in a pre-production environment. When you begin to apply security policies on production servers, there should be a back out plan that doesn’t rely on SCW’s rollback feature. If you suddenly can’t make a connection to the server, you might not be able to perform a rollback so easily!
The short answer is, quite possibly not. Default configurations should always be modified with caution. Following simple industry best practices such as not using domain administrator accounts to perform everyday administration tasks on servers and desktops, can significantly reduce the risk of servers being compromised.
If you decide to create your own security policy, or apply a custom security template not provided by Microsoft, you also risk putting the server out of support. For instance, Microsoft may refuse to support your server if you are not using a default configuration as provided by them; whether that is Windows Server as configured out-of-the-box, or a template provided as part of the Security Compliance Manager (SCM) tool.
Evaluate the potential risk for each server in your production environment. How likely is it to be targeted and by what means? If a risk is identified that can be mitigated by using the Security Configuration Wizard, test a security policy in a pre-production environment to make sure it doesn’t affect line-of-business activity. Also don’t forget that extra configuration above the default settings potentially increases complexity, making troubleshooting harder if a problem arises.
Now that we understand the possible problems and risks of applying our own security policies to Windows Server, let’s start by creating a new security policy using SCW on a test server. All the instructions in this article apply to Windows Server 2012 R2. The options and results you see in earlier versions of Windows will differ slightly. The screens presented in the wizard vary slightly depending on whether the targeted server is a domain controller, member, or standalone server.
On the Select Server screen it’s possible to select a server other than the one that you are currently logged in to. If you select a different server, you must have local administrative privileges on that server if you intend to apply the policy at the end of the wizard.
In this section of the wizard, we will configure what Server Roles, Features and other options the security policy should include.
In this example, I want to check Remote Desktop in the list because I use it for remote administration of the server. If it’s not selected, SCW disables the service in the policy. Note that in the figure below I selected Remote Administration Options from the menu just to make it easier to find the Remote Desktop option.
Select Administration and Other Options in the Security Configuration Wizard
The next part of the wizard configures Windows Firewall rules.
Here you can add and edit rules as necessary, but you’ll likely want to accept the rules as determined by the wizard. Even though a rule exists for Remote Desktop (TCP-In), it’s not enough to make a Remote Desktop Connection to your server. You’ll need to add three rules to enable Remote Desktop.
Set Windows Firewall rules for Remote Desktop
The Windows Firewall rules allow any device to connect to Remote Desktop Services on TCP port 3389. Although Microsoft Azure uses random ports for Remote Desktop by default, no special rule to accommodate this is required on Azure VMs so the default firewall rules that use port 3389 will work properly.
Now let’s configure the server’s registry settings for LAN manager authentication. While Active Directory uses Kerberos authentication by default, it is sometimes necessary to use older authentication protocols for legacy applications.
This sets the LAN manager compatibility level in the registry. It is preferable to leave the other two options unchecked unless you have a requirement to authenticate using local accounts or file sharing passwords. Beware that local accounts are often used for authentication, even on servers joined to a domain.
LAN manager compatibility level
Both LM and NTLMv1 are considered insecure and should be disabled whenever possible. There are some legacy applications that rely on these protocols so you should test these settings thoroughly before configuring production servers.
Outbound Authentication using Domain Accounts
Note: If you have computers running Windows XP or earlier or their Windows Server equivalents, you need to make sure they are configured to work with NTLMv2 authentication before configuring servers to respond only to NTLMv2.
Inbound Authentication Methods
The auditing section of the wizard allows you to increase the auditing level over what is configured as standard in Windows Server.
System Audit Policy configuration
Now we can save the policy and apply it now or at a later time.
You also have the option to view the settings configured using the wizard by clicking View Security Policy, and to add a security template (.inf file) to the settings. If you decide to include a security template any settings it includes cannot be rolled back using the security wizard.
In the next part of this series, I’ll describe how to apply and roll back this policy using the GUI, how to convert a SCW policy into a Group Policy Object (GPO) and how to secure multiple servers using SCW.