Hardening Windows Server 2016, 2019, and 2022: Hardening with Group Policy

Group Policy is one of the most effective tools for hardening Active Directory environments at scale. A single GPO applied to an OU consistently enforces security settings across hundreds of servers simultaneously, without needing to touch each server individually. And when a new server joins the domain and is placed in the correct OU, the policy applies automatically on next Group Policy refresh.

The settings below address weaknesses that exist in default Active Directory configurations and have existed across all three server versions. This is not the full Group Policy hardening guide. It is the practical settings that make the most difference in the environments I work in.

Domain Controller GPO Structure

Create a dedicated GPO for domain controller hardening, for example, DC-Hardening-Baseline, and link it to the Domain Controllers OU with a precedence higher than the Default Domain Controllers Policy (lower link order number = higher precedence in GPO processing). This GPO contains the security settings that should apply to all domain controllers.

GPO processing order: Local Policy is applied first, then site GPOs, then domain GPOs, then OU GPOs, with later GPOs winning on conflict. The Domain Controllers OU GPO processes after the domain-level Default Domain Policy, which means your DC-specific hardening GPO can safely override domain-level settings without affecting workstations and member servers.

Password and Account Policies

Password policy applies at the domain level, not the OU level, for domain user accounts. Fine-Grained Password Policies can override this for specific users or groups, but the baseline applies domain-wide through the Default Domain Policy.

# Group Policy path:
# Computer Configuration > Windows Settings > Security Settings > Account Policies
# Recommended minimum settings:
Minimum password length: 14 characters
Password history: 24 passwords
Maximum password age: 90 days (site choice) (or use NIST's approach - no expiry + MFA + breach detection)
Complexity requirements: Enabled (but length matters more than complexity rules)
# Account lockout policy:
Account lockout threshold: 10 invalid attempts
Account lockout duration: 30 minutes (site choice)
# Lockout duration must be at least the reset counter.
Reset account lockout counter after: 10 minutes

The NIST SP 800-63B guidance has moved away from mandatory periodic password changes for accounts without evidence of compromise, preferring longer passwords combined with MFA and breach credential monitoring. Many regulated environments still require periodic changes. Apply the policy that your compliance framework requires, but ensure the minimum length requirement is at least 14 characters regardless.

Kerberos Policy

Kerberos is the primary authentication protocol for Active Directory environments. These are the Windows default Kerberos policy values. Microsoft says most environments should not change them, so keep them and keep time in sync:

# Computer Configuration > Windows Settings > Security Settings
# > Account Policies > Kerberos Policy
Maximum tolerance for computer clock synchronization: 5 minutes
Maximum lifetime for service ticket: 600 minutes (10 hours)
Maximum lifetime for user ticket: 10 hours
Maximum lifetime for user ticket renewal: 7 days

The clock synchronization tolerance (5 minutes) is the Kerberos ticket validity window. Keep this at 5 minutes and ensure all servers synchronize time correctly.

Restrict NTLM Authentication

NTLM is the legacy authentication protocol that Kerberos replaced in Active Directory environments. In a properly configured AD environment, most authentication should use Kerberos. NTLM is still used in specific scenarios (systems accessing resources by IP address instead of hostname, some legacy applications), but it should be restricted rather than allowed by default everywhere.

# GPO: Computer Configuration > Windows Settings > Security Settings
# > Local Policies > Security Options
# Restrict NTLM on domain controllers:
"Network security: Restrict NTLM: NTLM authentication in this domain"
= Deny for domain accounts to domain servers
# Audit NTLM usage before restricting (identify what uses NTLM):
# On domain controllers:
"Network security: Restrict NTLM: Audit NTLM authentication in this domain" = Enable all
# On member servers:
"Network security: Restrict NTLM: Audit Incoming NTLM Traffic" = Enable auditing for all accounts
# Events: Applications and Services Logs > Microsoft > Windows > NTLM > Operational

Before restricting NTLM, run NTLM auditing through at least one month-end (a quarter-end if payroll or finance is in scope; this is a field rule, not a Microsoft figure) and review the event log to identify what is still using NTLM authentication. Systems accessing servers by IP address, NAS devices, some applications, and printers are common sources. Address those dependencies before implementing restrictions, or you will break things unexpectedly.

At minimum, disable NTLMv1 and LM authentication entirely. These are the weakest variants of NTLM and should not be in use anywhere:

# Security Options:
"Network security: LAN Manager authentication level"
= Send NTLMv2 response only. Refuse LM and NTLM

Audit Policy via Group Policy

Advanced Audit Policy Configuration provides significantly more granularity than basic audit policies and should be used in all Windows Server 2016 and later environments. Basic audit policies have coarse settings. Advanced Audit Policy lets you specify exactly which events are logged within each category.

# GPO: Computer Configuration > Windows Settings > Security Settings
# > Advanced Audit Policy Configuration > Audit Policies
# Account logon:
Audit Credential Validation: Success, Failure
Audit Kerberos Authentication Service: Success, Failure
Audit Kerberos Service Ticket Operations: Success, Failure (Microsoft's stronger recommendation; its baseline sets none)
# Account management:
Audit Computer Account Management: Success, Failure
Audit Security Group Management: Success, Failure
Audit User Account Management: Success, Failure
# Logon/Logoff:
Audit Logon: Success, Failure
Audit Logoff: Success
Audit Special Logon: Success
# Object access (apply where needed):
Audit File System: Failure (site choice; Microsoft sets no baseline. Success generates high volume)
Audit SAM: Failure (site choice; Microsoft sets no baseline)
# Policy change:
Audit Audit Policy Change: Success
Audit Authentication Policy Change: Success
# Privilege use:
Audit Sensitive Privilege Use: Success, Failure (site choice; Microsoft sets no baseline)
# System:
Audit Security State Change: Success
Audit System Integrity: Success, Failure
# Detailed tracking:
Audit Process Creation: Success (Microsoft baseline)

On domain controllers specifically, enable these through the DC-specific GPO to ensure DC audit settings take precedence over domain-level settings. Domain controller audit events are particularly important because DCs are the authentication and authorization hub for the entire domain.

Windows Defender via Group Policy

Manage Windows Defender centrally through Group Policy rather than configuring it manually on each server. GPO-managed Defender settings survive Windows Updates and cannot be accidentally disabled by local administrators.

# GPO: Computer Configuration > Administrative Templates
# > Windows Components > Microsoft Defender Antivirus
Key settings:
"Turn off Microsoft Defender Antivirus" = Disabled (ensures Defender stays enabled)
"Turn on behavior monitoring" = Enabled (Real-time Protection)
# Tamper protection is set in the Microsoft Defender portal or Intune, not in Group Policy.
# Exclusions for Genetec environments:
Computer Configuration > Admin Templates > Windows Components
> Microsoft Defender Antivirus > Exclusions
"Path Exclusions", add Genetec installation and archive directories
"Process Exclusions", add Genetec service processes

SMBv1 Disable via Group Policy

Disabling SMBv1 through Group Policy ensures it cannot be re-enabled manually and applies to all servers in the OU consistently:

# GPO: Computer Configuration > Preferences > Windows Settings > Registry
# Create a new Registry item:
Key path: SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value name: SMB1
Value type: REG_DWORD
Value data: 0

This is more reliable than applying it through PowerShell per-server because it reapplies with every Group Policy refresh. A server that has SMBv1 re-enabled for a legacy application will have the policy applied again at the next Group Policy refresh; restart the server to finish the change.

LAPS via Group Policy

Windows LAPS is in Server 2019 and 2022 from the April 2023 update and built into 2025. Server 2016 can run only legacy Microsoft LAPS, which Microsoft still supports on that OS until its end of support. Plan to replace the server. It is configured entirely through Group Policy. Once the LAPS policy is enabled, the Windows LAPS agent handles password generation and storage in Active Directory automatically.

# GPO: Computer Configuration > Administrative Templates > System > LAPS
"Configure password backup directory" = Active Directory
"Password Settings":
  - Password complexity: Large letters, small letters, numbers, specials
  - Password length: 20 characters minimum
  - Password age: 30 days
"Do not allow password expiration time longer than required by policy" = Enabled

After deploying the LAPS policy, the local administrator password on each server is unique, randomly generated, and stored in AD. Retrieve it using the LAPS PowerShell module or the LAPS UI tool. The password is automatically rotated on the configured schedule.