DC OU GPO always takes highest precedence. Create a separate hardening GPO – never modify the Default Domain Controllers Policy directly.
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.
Never modify the Default Domain Policy or Default Domain Controllers Policy directly. Create new GPOs for hardening settings and link them to the appropriate OUs. If you break something in a custom GPO, you can disable or delete that GPO. If you break something in the Default Domain Policy, recovery is significantly more complex and can affect authentication across the entire domain.
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 (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
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. The default Kerberos settings are not optimal for security:
# 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. A tighter tolerance (1-2 minutes) reduces the window for ticket replay attacks but requires reliable time synchronization across all systems – if any server drifts, authentication failures follow.
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):
"Network security: Restrict NTLM: Audit NTLM authentication in this domain"
= Enable auditing for domain accounts
Before restricting NTLM, enable NTLM auditing for a period (2-4 weeks) 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
# 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 (Success generates high volume)
Audit SAM: Failure
# Policy change:
Audit Audit Policy Change: Success
Audit Authentication Policy Change: Success
# Privilege use:
Audit Sensitive Privilege Use: Success, Failure
# System:
Audit Security State Change: Success
Audit System Integrity: Success, Failure
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)
"Configure behavior monitoring" = Enabled
# 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 it disabled again on the next GP refresh cycle (every 90 minutes by default), making it impossible to accidentally leave SMBv1 enabled long-term.
LAPS via Group Policy
Windows LAPS (available on Server 2022 and through Windows Update for earlier versions) 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.