
close
close
Chance to win $250 in Petri 2023 Audience Survey
The Security Configuration Wizard (SCW) first appeared in Windows Server 2003 Service Pack 1 and 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, except in 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 to hand.
Although I’ll remind you from time to time as part of the instructions included in this article, modifying security settings from the defaults risks creating application compatibility or network connection problems. In the worst case scenario, you could lose access to a remote server, which would be especially catastrophic if it is located in a remote datacenter with no Integrated Lights Out facility.
Therefore, any security policies created using SCW should be thoroughly tested in a pre-production environment, and when you get around to applying policies on production servers, there should be a back out plan that doesn’t rely on SCW’s rollback feature. If you can’t make a connection to the server, you might not be able to perform a rollback so easily!
In short, 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, alone 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 example, Microsoft may refuse to support your server if you are not using a default configuration as provided by them, regardless of whether that be Windows Server as configured out-of-the-box or using 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, then 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 in the case of a problem.
Now 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, and 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 your 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 (Image Credit: Russell Smith)
The next part of the wizard configures Windows Firewall rules.
Here you can add and edit rules as necessary, but the chances are you’ll 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 (Image Credit: Russell Smith)
The Windows Firewall rules allows 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 just fine.
Now let’s configure the server’s registry settings for LAN manager authentication. While Active Directory uses Kerberos authentication by default, sometimes it is necessary to use older authentication protocols for legacy applications.
This sets the LAN manager compatibility level in the registry and it’s 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 for authentication, even on servers joined to a domain.
LAN manager compatibility level (Image Credit: Russell Smith)
Both LM and NTLMv1 are considered insecure and should be disabled whenever possible. However, 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 (Image Credit: Russell Smith)
Note that 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 (Image Credit: Russell Smith)
The auditing section of the wizard allows you to increase the auditing level over what is configured as standard in Windows Server.
Audit configuration in the Security Configuration Wizard (Image Credit: Russell Smith)
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 show you 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.
More in Security
Atlassian Releases Patches for Critical Authentication Vulnerability in Jira Software
Feb 6, 2023 | Rabia Noureen
What is Microsoft Sentinel and How Does It Protect Cloud and On-Premises Resources?
Feb 2, 2023 | Mustafa Toroman
Microsoft Defender for Endpoint Adds Device Isolation Support for Linux Machines
Jan 31, 2023 | Rabia Noureen
Git Releases New Security Updates to Block Remote Code Execution Attacks
Jan 18, 2023 | Rabia Noureen
Most popular on petri