Active Directory Group Policy Security Hardening: A Complete Guide
Group Policy Objects (GPOs) are the primary mechanism for enforcing security configuration across Windows domains. A well-hardened GPO baseline closes the most common Active Directory attack paths -- Pass-the-Hash, Pass-the-Ticket, lateral movement via shared local admin passwords, NTLM relay, and SMB man-in-the-middle. This guide covers the specific GPO settings that provide the highest security return, organized by attack technique they defeat, with exact registry paths and policy locations for implementation.
GPO Architecture and Baseline Strategy
Before configuring individual settings, establish a GPO architecture that is maintainable and auditable.
Recommended GPO structure:
Domain
├── Default Domain Policy (password policy only -- keep minimal)
├── Security Baselines (OU-linked)
│ ├── GPO: CIS L1 Baseline - Workstations
│ ├── GPO: CIS L1 Baseline - Servers
│ ├── GPO: CIS L1 Baseline - Domain Controllers
│ └── GPO: LAPS Configuration
├── Security Hardening (OU-linked)
│ ├── GPO: Credential Guard
│ ├── GPO: AppLocker / WDAC
│ ├── GPO: Audit Policy
│ ├── GPO: Windows Firewall
│ └── GPO: NTLM Restrictions
└── Application Settings (separate from security)
Why separate GPOs per control area:
- Easier to troubleshoot -- disable one GPO without affecting others
- Clearer audit trail for compliance -- each GPO has a defined purpose
- Easier to update baselines -- refresh the CIS baseline GPO independently
Baseline tools:
- Microsoft Security Compliance Toolkit (SCT): Free Microsoft-provided GPO baselines aligned with Windows security benchmarks. Download at microsoft.com/en-us/download/details.aspx?id=55319
- CIS-CAT Pro / CIS Benchmark GPO: CIS provides downloadable GPO packages for Windows 10/11, Windows Server 2019/2022, and domain controllers
- LGPO.exe: Command-line tool to import/export local group policy; useful for non-domain machines
GPO precedence (LSDOU): Local > Site > Domain > OU -- OU-linked GPOs override domain-linked ones. Place security hardening GPOs at the OU level for specific device types rather than domain-wide to allow flexibility.
Password Policy, Account Lockout, and LAPS
Domain password policy:
Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy
| Setting | Recommended Value | Rationale |
|---|---|---|
| Minimum password length | 14 characters | NIST 800-63B / CIS L1 |
| Password complexity | Enabled | Requires uppercase, lowercase, digit, special |
| Maximum password age | 365 days | NIST: do not expire without compromise indicator |
| Minimum password age | 1 day | Prevents immediate cycling |
| Enforce password history | 24 passwords | Prevents cycling through 24 passwords to reuse old one |
| Store passwords using reversible encryption | Disabled | Required for LAN Manager hash protection |
Fine-Grained Password Policies (PSOs) allow different password requirements for privileged accounts (admin accounts) without changing domain-wide policy. Create a PSO for admin accounts with 20+ character minimum length and apply via security group.
Account lockout policy:
Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy
| Setting | Value |
|---|---|
| Account lockout threshold | 5 invalid attempts |
| Account lockout duration | 15 minutes (or 0 for admin unlock required) |
| Reset account lockout counter after | 15 minutes |
Local Administrator Password Solution (LAPS):
LAPS (now Windows LAPS, built into Windows Server 2019+ and Windows 10/11) randomizes local administrator passwords on every machine and stores them in Active Directory / Azure AD -- retrievable only by authorized admins.
Without LAPS: every workstation has the same local admin password. One compromised credential = lateral movement to all workstations.
Deploying Windows LAPS (built-in):
# Enable Windows LAPS in Active Directory
Update-LapsADSchema
# Grant permissions for computer objects to update their own password
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=com"
# Configure via GPO:
# Computer Configuration > Administrative Templates > System > LAPS
# - Enable local admin password management: Enabled
# - Password settings: complexity = Large letters, small letters, numbers, special; length = 20; age = 30 days
# - Directory Services backup directory: Active Directory
# Retrieve a specific machine's local admin password
Get-LapsADPassword -Identity WORKSTATION01 -AsPlainText
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Credential Guard and Protected Users
Windows Credential Guard:
Credential Guard uses hardware virtualization (VBS -- Virtualization Based Security) to isolate NTLM password hashes and Kerberos ticket-granting tickets in a protected memory enclave called LSA Isolated (LSAIso). Pass-the-Hash and Pass-the-Ticket attacks fail because the credential material cannot be read from LSASS memory.
Requirements: Windows 10/11 Enterprise or Education, 64-bit CPU with SLAT (Second Level Address Translation), UEFI Secure Boot, TPM 2.0 recommended.
Enabling via GPO:
Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security
Settings:
- Select Platform Security Level: Secure Boot and DMA Protection (requires TPM + UEFI)
- Virtualization Based Protection of Code Integrity: Enabled with UEFI lock (prevents disabling via registry)
- Credential Guard Configuration: Enabled with UEFI lock
Verify Credential Guard is running:
Get-ComputerInfo | Select-Object -Property DeviceGuardSecurityServicesConfigured, DeviceGuardSecurityServicesRunning
# Should show: CredentialGuard in both fields
Protected Users security group:
The Protected Users group applies hardened Kerberos settings to its members without GPO configuration. Members of Protected Users:
- Cannot authenticate using NTLM, Digest, or CredSSP -- Kerberos only
- Cannot use DES or RC4 for Kerberos -- AES only
- Cannot use Kerberos unconstrained delegation
- Kerberos TGT lifetime limited to 4 hours (non-renewable)
Add all privileged accounts (domain admins, enterprise admins, service account holders with admin rights) to Protected Users. Test first -- some applications break when users cannot use NTLM.
# Add a user to Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members "AdminUser1","AdminUser2"
# Verify
Get-ADGroupMember -Identity "Protected Users"
NTLM Restriction and SMB Hardening
NTLM is the primary protocol exploited in relay attacks (LLMNR/NBT-NS poisoning, NTLM relay via Responder). Restricting NTLM forces clients to use Kerberos, which is not relay-able in the same way.
Restrict NTLM authentication:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
| Setting | Value |
|---|---|
| Network security: Restrict NTLM: NTLM authentication in this domain | Deny all |
| Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers | Deny all (start with Audit All, then progress to Deny) |
| Network security: Restrict NTLM: Incoming NTLM traffic | Deny all domain accounts |
Implementation approach: Do not jump to Deny all immediately. Start with Audit:
- Set to Audit all -- log NTLM usage for 2-4 weeks
- Review logs: Event ID 8001-8004 in Microsoft-Windows-NTLM/Operational log
- Identify applications still using NTLM (likely: old print servers, legacy apps, NAS devices)
- Fix or exempt those applications
- Progress to Deny all once NTLM usage is near zero
Disable NTLM v1 (mandatory, non-negotiable):
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LAN Manager authentication level
Set to: Send NTLMv2 response only. Refuse LM and NTLM
NTLMv1 hashes are trivially crackable and enable Pass-the-Hash against any server that accepts them.
Disable LLMNR and NetBIOS (blocks Responder attacks):
LLMNR (Link-Local Multicast Name Resolution) and NetBIOS name resolution are exploited by Responder to capture NTLM hashes via poisoning.
Disable LLMNR: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution: Enabled
Disable NetBIOS over TCP/IP via DHCP option 001, or via GPO registry setting:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_*
NodeType = 2 (P-node -- no NetBIOS broadcasts)
SMB signing (mandatory):
Without SMB signing, NTLM relay attacks (via Responder + ntlmrelayx) can authenticate to SMB shares as captured users. SMB signing prevents relay by requiring cryptographic signatures on all SMB packets.
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
| Setting | Value |
|---|---|
| Microsoft network server: Digitally sign communications (always) | Enabled |
| Microsoft network client: Digitally sign communications (always) | Enabled |
| Microsoft network server: Digitally sign communications (if client agrees) | Enabled |
| Microsoft network client: Digitally sign communications (if server agrees) | Enabled |
SMB signing is required by default on domain controllers in modern Windows -- but workstation-to-workstation SMB is often unsigned.
Audit Policy and Windows Event Logging
Without comprehensive audit logging, you cannot detect attack techniques even when they succeed. Configure Advanced Audit Policy via GPO rather than the basic audit policy (advanced audit is more granular and does not conflict with basic).
Configure Advanced Audit Policy:
Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration
| Subcategory | Success | Failure | Detects |
|---|---|---|---|
| Logon | Yes | Yes | Authentication events |
| Account Logon | Yes | Yes | Kerberos/NTLM authentication |
| Logon/Logoff: Special Logon | Yes | No | Admin-equivalent logon |
| Account Management: User Account Management | Yes | Yes | Account creation/modification |
| Account Management: Security Group Management | Yes | No | Group membership changes |
| DS Access: Directory Service Changes | Yes | No | AD object modification |
| Privilege Use: Sensitive Privilege Use | Yes | Yes | SeDebugPrivilege (Mimikatz indicator) |
| Object Access: Kernel Object | Yes | Yes | LSASS access attempts |
| Detailed Tracking: Process Creation | Yes | No | All process launches |
| Policy Change: Audit Policy Change | Yes | No | Audit policy tampering |
Command line auditing (critical for detecting malware):
Computer Configuration > Administrative Templates > System > Audit Process Creation > Include command line in process creation events: Enabled
This captures the full command line in Event ID 4688, enabling detection of:
- PowerShell encoded commands (
-EncodedCommand) - Mimikatz invocation (
sekurlsa::logonpasswords) - Scheduled task creation with malicious payloads
- Living-off-the-land binaries (LOLBins) being misused
PowerShell logging:
Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell
- Turn on PowerShell Script Block Logging: Enabled
- Turn on PowerShell Transcription: Enabled (with output directory to a write-once network share)
Script block logging captures deobfuscated PowerShell commands -- Amsi bypass attempts, Empire/Cobalt Strike stager scripts, and encoded payloads all appear in plaintext in Event ID 4104.
AppLocker and Windows Defender Application Control (WDAC)
Application control prevents unauthorized executables, scripts, and DLLs from running -- a critical defense against ransomware and lateral movement tooling.
AppLocker vs. WDAC:
| Feature | AppLocker | WDAC (Windows Defender Application Control) |
|---|---|---|
| OS Requirement | Windows Enterprise/Education | Windows 10/11 (all editions for basic, Enterprise for full) |
| Enforcement | User-mode only | Kernel-mode (cannot be bypassed by admin processes) |
| Policy location | GPO | GPO or MDM (Intune) |
| LOLBin protection | Limited | Strong (can block msbuild.exe, wmic.exe, etc.) |
| UEFI lock | No | Yes |
WDAC in kernel mode cannot be bypassed even by a process running as SYSTEM -- preferred for high-security environments.
AppLocker quick-start (default rules + block known-bad):
Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker
-
Right-click each rule collection (Executable, Script, Windows Installer) > Create Default Rules
-
Default rules allow: %PROGRAMFILES%, %WINDIR%, and signed binaries for Everyone
-
Add deny rules for paths commonly abused:
%TEMP%\*.exe-- block execution from temp directories%APPDATA%\*.exe-- block execution from AppData%USERPROFILE%\Downloads\*.exe-- block direct execution of downloads
-
Set Application Identity service to Automatic and start it (required for AppLocker enforcement)
WDAC policy creation:
# Create a base policy (allow Microsoft + WHQL signed binaries)
New-CIPolicy -Level Publisher -FilePath C:\Policies\BasePolicy.xml -UserPEs
# Add supplemental policy for your organization's software
New-CIPolicy -Level Publisher -FilePath C:\Policies\OrgPolicy.xml -ScanPath "C:\Program Files\YourApp"
# Merge policies
Merge-CIPolicy -PolicyPaths C:\Policies\BasePolicy.xml,C:\Policies\OrgPolicy.xml -OutputFilePath C:\Policies\MergedPolicy.xml
# Convert to binary and deploy via GPO
ConvertFrom-CIPolicy C:\Policies\MergedPolicy.xml C:\Windows\System32\CodeIntegrity\SIPolicy.p7b
The bottom line
Group Policy is the control plane for Windows domain security. The settings with the highest attack-prevention return are: LAPS (eliminates shared local admin password lateral movement), Credential Guard (blocks Pass-the-Hash and Pass-the-Ticket), SMB signing (blocks NTLM relay), LLMNR/NetBIOS disable (blocks Responder poisoning), and PowerShell script block logging (full visibility into PowerShell-based attacks). Deploy the Microsoft Security Compliance Toolkit baseline first, then layer these specific hardening settings on top. Test in a pilot OU before domain-wide rollout.
Frequently asked questions
What is the difference between AppLocker and Windows Defender Application Control (WDAC)?
AppLocker operates in user mode and enforces application control at the process level for the logged-in user. An attacker running as SYSTEM or who can disable the Application Identity service can bypass it. WDAC (formerly Device Guard Code Integrity) operates in kernel mode -- even a SYSTEM-level process cannot execute unsigned or policy-violating code because the enforcement happens before the kernel loads any code. WDAC is harder to deploy (requires careful policy authoring and testing) but provides significantly stronger protection against advanced attackers who have already achieved admin access. For high-security environments, target WDAC; use AppLocker as a stepping stone.
How does LAPS prevent lateral movement in Active Directory?
Without LAPS, organizations typically use the same local administrator password across all workstations -- often set during imaging and never changed. When an attacker compromises one machine and extracts the local admin hash (via Mimikatz), they can use that same hash (Pass-the-Hash) to authenticate as local admin on every other workstation in the environment. LAPS generates a unique random password for each machine's local administrator account and stores it in Active Directory, rotated on a schedule (typically 30 days). Even if an attacker extracts the local admin hash from one machine, it only works on that machine -- lateral movement via shared local admin credentials is eliminated.
Is it safe to disable NTLM entirely in an enterprise environment?
Disabling NTLM entirely (Deny All) breaks some legacy applications, printing to some printer models, and NAS/file server access for devices that cannot use Kerberos. The safe approach is a phased rollout: enable NTLM auditing for 4-8 weeks (Event IDs 8001-8004 in the NTLM/Operational log), identify and address each remaining NTLM consumer, then progress to restricting and finally denying. Most modern Windows environments can reach near-zero NTLM usage within 3-6 months with this approach. The immediate, no-risk step is to disable NTLMv1 (LM authentication) -- this breaks nothing in any environment running Windows Vista or newer clients.
What GPO settings most directly block Mimikatz and credential dumping?
The most effective GPO controls against Mimikatz and LSASS credential dumping are: (1) Credential Guard -- isolates credential material in a hardware-protected enclave that LSASS cannot access even with SeDebugPrivilege; (2) LSA Protection (RunAsPPL) -- sets LSASS as a Protected Process Light, blocking non-protected processes from reading its memory (Computer Config > Windows Settings > Security Settings > Local Policies > Security Options > Local Security Authority (LSA) Protection: Enabled); (3) Protected Users group -- prevents cacheable credentials from being stored for group members; (4) Audit Object Access for Kernel Object -- detects LSASS access attempts (Event ID 4656 with object LSASS.exe). Layer all four for defense-in-depth.
How do I prioritize GPO hardening if I have limited time?
Priority order by attack-prevention impact: (1) Deploy LAPS immediately -- 30 minutes to deploy, eliminates shared local admin lateral movement; (2) Enable SMB signing -- 5 minutes in GPO, blocks NTLM relay attacks; (3) Disable LLMNR and NetBIOS -- 10 minutes in GPO, blocks Responder poisoning; (4) Enable PowerShell script block logging -- 5 minutes, provides visibility into PowerShell attacks; (5) Set LAN Manager authentication to NTLMv2 only -- 5 minutes, disables NTLMv1; (6) Enable Credential Guard -- requires testing but blocks Pass-the-Hash; (7) Deploy CIS baseline -- comprehensive hardening requiring more testing. Steps 1-5 take under an hour and stop the most common Active Directory attack chains.
What is the CIS Benchmark for Windows and how do I apply it via GPO?
The CIS Benchmarks for Windows 10, Windows 11, Windows Server 2019, and Windows Server 2022 provide 200-400 controls each, organized into Level 1 (broad applicability, significant security improvement) and Level 2 (defense-in-depth, may impact functionality). Microsoft also publishes the Security Compliance Toolkit (SCT) with similar GPO baselines. Both provide downloadable GPO backup files that can be imported via the Group Policy Management Console (GPMC): right-click a GPO > Import Settings > select the backup folder. Apply to a test OU first -- some settings (particularly L2 settings) disable features that some organizations need. Run a Group Policy Results report (gpresult /h report.html) on test machines to verify settings applied correctly.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.