Use IISCrypto (free tool) to configure TLS settings safely with rollback capability.
This post covers the additional hardening considerations for Windows Server 2016, 2019, and 2022 environments that fall outside the baseline configuration covered in the getting started post. If you have not read that post, start there. The steps here build on the foundation it establishes.
TLS 1.2 as the Minimum Standard
TLS 1.0 and TLS 1.1 should be disabled on all production Windows Server environments. Both are deprecated protocols with known vulnerabilities – BEAST, POODLE, and related attacks have been well-documented for years. Current guidance from NIST, the Canadian Centre for Cyber Security, and most enterprise security frameworks requires TLS 1.2 as the minimum, with TLS 1.3 preferred where all communicating systems support it.
On Windows Server 2016 and 2019, TLS 1.0 and 1.1 are still enabled by default. On Windows Server 2022, TLS 1.0 and 1.1 are disabled by default, but verify this in your specific deployment – server builds can vary.
The safest way to configure TLS on Windows Server is using IISCrypto, a free tool from Nartac Software. It provides a GUI for managing Schannel settings with a template-based approach and the ability to back out changes if something breaks. The equivalent can be done directly via registry, but IISCrypto reduces the risk of errors:
# Registry locations for TLS protocol control (manual approach):
# HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
# To disable TLS 1.0 (Server side):
[HKLM\...\Protocols\TLS 1.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
# To disable TLS 1.0 (Client side):
[HKLM\...\Protocols\TLS 1.0\Client]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
# Repeat for TLS 1.1 at the same paths
After changing TLS settings, restart the server. Changes to Schannel settings do not take effect without a restart.
Legacy Application Exceptions
Some legacy applications, particularly older security system management platforms, still require TLS 1.0 for their own components or for communication with supported hardware. The existence of a legacy dependency is not justification for leaving the protocol enabled on the entire server. It is justification for a specific, documented exception with a plan to address it.
The approach to legacy TLS dependencies:
Identify and document the specific systems. Which application requires TLS 1.0 or 1.1? What does it communicate with? What hardware or platforms on the other end impose the limitation? Document this explicitly.
Isolate where possible. If the legacy platform can be moved to a dedicated server that runs only that application and its dependencies, the TLS exception can be scoped to that server rather than applied to the entire environment. The primary domain controllers and critical servers can be hardened to TLS 1.2 minimum while the legacy system runs in isolation with compensating controls.
Plan a path forward. Legacy TLS dependencies usually exist because hardware has not been updated or software has not been upgraded. Document the reason and a timeline for remediation. “We still need TLS 1.0 because the X system is on version Y which does not support TLS 1.2” is an acceptable interim position with a plan. “We always leave TLS 1.0 enabled because it might break something” is not.
Apply compensating controls. If a server must run TLS 1.0 for a specific legacy system, apply additional controls: restrict the server’s inbound connections to known IP addresses, ensure TLS 1.2 is still enabled and preferred, monitor the server more closely for anomalies, and increase the logging verbosity on Schannel events.
Remote Desktop Service Hardening
Remote Desktop is a common administrative access method for Windows servers. Default RDP settings leave several hardening items unaddressed.
Network Level Authentication (NLA). NLA requires the connecting user to authenticate before the Remote Desktop session is established. Without NLA, the login screen is rendered before authentication, which allows unauthenticated users to reach the RDP session login and is the attack surface for credential stuffing and brute force against the RDP login screen. NLA should be enabled on all servers and enforced through Group Policy.
# GPO Setting: Computer Configuration > Administrative Templates
# > Windows Components > Remote Desktop Services > Remote Desktop Session Host
# > Security > Require user authentication for remote connections by using NLA
# Set to: Enabled
RDP port and access restriction. The default RDP port (3389) should not be accessible from the internet. Remote administrative access should go through a VPN first. If RDP is accessible from the internal network, restrict access to specific management IP addresses using the Windows Firewall or the host-based firewall policy.
RDP encryption level. Set the RDP encryption level to High through Group Policy. This ensures all data transmitted over the RDP session is encrypted with 128-bit encryption.
# GPO: Computer Configuration > Admin Templates > Windows Components
# > Remote Desktop Services > RDS Session Host > Security
# "Set client connection encryption level" = High Level
Idle session timeout. Configure timeouts for disconnected and idle RDP sessions. An authenticated session that is left idle indefinitely is an open door if the client machine is compromised.
SMB Hardening
SMBv1 is a 30-year-old protocol with critical vulnerabilities including EternalBlue, which was used in the WannaCry and NotPetya ransomware attacks. SMBv1 should be disabled on all modern Windows Server deployments without exception. There is no valid business reason to have it enabled on any server running Windows Server 2016 or later.
# Disable SMBv1:
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
# Verify:
Get-SmbServerConfiguration | Select EnableSMB1Protocol
SMB signing should be required on all servers, not just domain controllers. SMB signing prevents man-in-the-middle attacks on SMB traffic. Require SMB signing through Group Policy on all servers in the environment, not just those that are likely targets.
LAPS for Local Administrator Accounts
Local Administrator Password Solution (LAPS) manages unique, randomly generated passwords for the local administrator account on each server. Without LAPS, organizations typically either use the same local administrator password across all servers (which means one compromised server exposes all servers) or disable the local administrator account (which removes a recovery option if the domain is unavailable).
LAPS stores the password in a confidential Active Directory attribute that is readable only by authorized accounts and computers. Passwords rotate automatically on a configurable schedule. For Windows Server 2022 and Windows 11 systems, Windows LAPS is built into the OS and replaces the legacy LAPS MSI.
# Deploy Windows LAPS via Group Policy (Server 2022 / Win11):
# Computer Configuration > Administrative Templates > System > LAPS
# Enable the policy and configure password settings
# For legacy LAPS on Server 2016/2019:
# Deploy LAPS.msi via Group Policy Software Installation
# Configure via LAPS GPO ADMX templates after installation
Certificate Management
Servers using TLS for services need valid certificates. Self-signed certificates generate warnings for users and administrators and cannot be easily validated through a trust chain. For internal services, an internal Certificate Authority is preferable to self-signed certificates because it allows the organization to maintain a trusted root without purchasing commercial certificates for every service.
Windows Server includes Active Directory Certificate Services (ADCS) for deploying an internal CA. For smaller environments without a dedicated PKI infrastructure, a standalone CA on a dedicated server is a reasonable approach. Configure auto-enrollment through Group Policy for certificate distribution to domain-joined servers.
Monitor certificate expiration dates. An expired certificate on a critical service causes immediate, visible failures and generates unnecessary urgency. A certificate inventory with expiration dates and a renewal schedule eliminates this class of avoidable incidents.