Introduction to Active Directory Hardening
Active Directory is the identity backbone of most Windows enterprise environments, and it is the primary target in modern cyberattacks. Adversaries who compromise AD gain the ability to impersonate any user, access any resource, persist indefinitely, and move laterally throughout the organization. The attack techniques used against AD — Pass-the-Hash, Pass-the-Ticket, Golden Ticket, Kerberoasting, DCSync, and more — are well-documented, mature, and actively exploited in ransomware campaigns, APT operations, and insider threat scenarios. Hardening Active Directory on Windows Server 2022 requires a layered defensive approach that addresses credential theft, privilege abuse, lateral movement, persistence mechanisms, and monitoring gaps. This article covers the most impactful hardening controls with specific implementation guidance.
Defending Against Pass-the-Hash
Pass-the-Hash (PtH) exploits the fact that Windows caches NTLM credential hashes in memory (specifically in the LSASS process). An attacker who has obtained local or domain admin rights can dump these hashes using tools like Mimikatz and then use them to authenticate as that user without knowing the plaintext password. Defending against PtH requires a multi-layer approach.
Enable Credential Guard: Windows Defender Credential Guard uses virtualization-based security (VBS) to isolate the LSASS process in a protected environment that hypervisor-level exploits cannot access. It prevents NTLM hash extraction from LSASS memory. Enable it via Group Policy:
Computer Configuration > Administrative Templates > System > Device Guard
Setting: Turn On Virtualization Based Security
Value: Enabled
Select Platform Security Level: Secure Boot and DMA Protection
Credential Guard Configuration: Enabled with UEFI lockOr via registry:
reg add "HKLMSYSTEMCurrentControlSetControlDeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
reg add "HKLMSYSTEMCurrentControlSetControlDeviceGuard" /v RequirePlatformSecurityFeatures /t REG_DWORD /d 3 /f
reg add "HKLMSYSTEMCurrentControlSetControlLsa" /v LsaCfgFlags /t REG_DWORD /d 1 /fCredential Guard requires UEFI with Secure Boot, a 64-bit CPU with virtualization extensions (Intel VT-x or AMD-V), IOMMU (VT-d/AMD-Vi), and TPM 1.2 or 2.0. It is not available on domain controllers.
Add privileged accounts to the Protected Users security group: Members of the Protected Users group receive additional protections enforced by the KDC and LSASS:
# Add a privileged account to Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members "domainadmin01", "serviceaccount_priv"
# Protected Users group enforces:
# - No NTLM authentication (Kerberos only)
# - No DES or RC4 Kerberos encryption (AES only)
# - No Kerberos unconstrained delegation
# - No caching of credentials (no DPAPI domain backup key usage)
# - TGT lifetime reduced to 4 hours (default 10 hours)
# - No credential caching on the local deviceDisable NTLM or restrict it: NTLM is the authentication protocol used in PtH attacks. Where possible, disable NTLM entirely or restrict it to specific servers.
# Via Group Policy:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
# Restrict NTLM: Incoming NTLM traffic
# Value: Deny all accounts (for DCs) or Deny all domain accounts
# Restrict NTLM: NTLM authentication in this domain
# Value: Deny all
# If you cannot fully disable NTLM, audit it first:
# Restrict NTLM: Audit NTLM authentication in this domain
# Value: Enable all
# Then review Event ID 8004 in the Security log to identify NTLM usage
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=8004]]" |
Select-Object TimeCreated, Message |
Format-List |
Out-File C:Reportsntlm_usage.txtPreventing Pass-the-Ticket with Kerberos Armoring
Pass-the-Ticket (PtT) attacks involve stealing Kerberos tickets from memory and replaying them from a different machine. Kerberos armoring (also called FAST — Flexible Authentication Secure Tunneling) protects Kerberos authentication exchanges by encapsulating them in an armor ticket, preventing offline cracking of authentication traffic and making ticket theft harder to exploit.
# Enable Kerberos Armoring via Group Policy
Computer Configuration > Administrative Templates > System > KDC
Setting: KDC support for claims, compound authentication, and Kerberos armoring
Value: Always provide claims
# Also enable on client side:
Computer Configuration > Administrative Templates > System > Kerberos
Setting: Kerberos client support for claims, compound authentication, and Kerberos armoring
Value: EnabledPrivileged Access Workstations (PAWs) are dedicated devices used exclusively for administrative tasks. A PAW has no internet access, no email client, and no productivity software — it exists solely for AD administration, server management, and privileged operations. PAWs break the credential theft chain because administrative credentials are never exposed on devices that process untrusted content.
# Example: Authentication Policy to restrict where a privileged account can authenticate from
# Requires Windows Server 2012 R2+ DFL
# Create an Authentication Policy restricting admin login to PAW computers
New-ADAuthenticationPolicy -Name "AdminPAWPolicy" `
-UserAllowedToAuthenticateFrom "O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == `"AdminSilo`"))" `
-Enforce $true
# Create an Authentication Policy Silo
New-ADAuthenticationPolicySilo -Name "AdminSilo" -Enforce $true
Grant-ADAuthenticationPolicySiloAccess -Identity "AdminSilo" -Account "domainadmin01"
Set-ADUser -Identity "domainadmin01" -AuthenticationPolicySilo "AdminSilo"Preventing Golden Ticket Attacks
A Golden Ticket is a forged Kerberos TGT created with the krbtgt account’s password hash. The krbtgt account’s hash is obtained via a DCSync attack (replicating the domain database remotely) or by compromising a domain controller directly. With a valid Golden Ticket, an attacker has unlimited access to any resource in the domain for the lifetime of the ticket — which can be set to years.
Reset the krbtgt password twice: Because the KDC accepts tickets signed with either the current or previous krbtgt password (for graceful rollover), you must reset the password twice with a gap between resets to truly invalidate all outstanding Golden Tickets.
# Download and use the Reset-KrbtgtKeyInteractive script from Microsoft
# Or use PowerShell manually (less safe — use the Microsoft script in production)
# First reset
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "$(([System.Web.Security.Membership]::GeneratePassword(32,4)))" -Force)
# Wait for AD replication to complete across all DCs (check with repadmin)
repadmin /showrepl * /csv > C:repl_status.csv
# Verify all DCs have replicated the new password
# Second reset (invalidates tickets signed with the first-reset key)
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "$(([System.Web.Security.Membership]::GeneratePassword(32,4)))" -Force)
# After the second reset, monitor for Kerberos authentication failures
# (legitimate users will transparently re-authenticate; only forged tickets will fail)Microsoft Defender for Identity Golden Ticket detection: MDI detects Golden Tickets by monitoring for TGTs with anomalous lifetimes, nonstandard encryption types, or usage patterns inconsistent with the account’s normal behavior. Configure MDI sensors on all domain controllers and enable the “Suspected Golden Ticket usage” detection alert.
AdminSDHolder and SDProp Hardening
AdminSDHolder is a special AD object (CN=AdminSDHolder,CN=System,DC=domain,DC=com) whose ACL is used as a template to protect privileged group members. The SDProp (Security Descriptor Propagator) process runs every 60 minutes on the PDC Emulator and overwrites the ACL of any object that is a member of protected groups (Domain Admins, Enterprise Admins, Schema Admins, Administrators, etc.) with the AdminSDHolder ACL. This prevents ACL-based persistence attacks where an attacker adds permissions to a privileged account.
# View the current AdminSDHolder ACL
$adminSDHolder = [ADSI]"LDAP://CN=AdminSDHolder,CN=System,DC=domain,DC=com"
$acl = $adminSDHolder.ObjectSecurity
$acl.Access | Format-Table IdentityReference, ActiveDirectoryRights, AccessControlType
# Remove any unexpected ACEs from AdminSDHolder
# If you find a non-standard entry (e.g., a regular user account with write access):
$acl.RemoveAccessRule($suspiciousACE)
$adminSDHolder.CommitChanges()
# Force SDProp to run immediately (normally every 60 minutes)
# On the PDC Emulator, set the RunProtectAdminGroupsTask value to 1
reg add "HKLMSYSTEMCurrentControlSetServicesNTDSParameters" /v RunProtectAdminGroupsTask /t REG_DWORD /d 1 /f
# Or use ldifde/adsiedit to trigger via RootDSE
$rootDSE = [ADSI]"LDAP://RootDSE"
$rootDSE.Put("runProtectAdminGroupsTask", 1)
$rootDSE.SetInfo()Audit AdminSDHolder ACL changes regularly. Any modification to the AdminSDHolder permissions that is not authorized should be treated as an indicator of compromise. Configure Advanced Audit Policy to log Directory Service Changes for the AdminSDHolder object.
Disabling Legacy Authentication Protocols
LM (LAN Manager) and NTLMv1 are legacy authentication protocols with known cryptographic weaknesses. LM hashes can be cracked in seconds using rainbow tables. NTLMv1 is vulnerable to offline cracking with tools like Responder. Both should be disabled in all modern environments.
# Disable LM hash storage
# Group Policy:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
Setting: Network security: Do not store LAN Manager hash value on next password change
Value: Enabled
# Or registry:
reg add "HKLMSYSTEMCurrentControlSetControlLsa" /v NoLMHash /t REG_DWORD /d 1 /f
# Enforce NTLMv2 only (disable LM and NTLMv1 challenge-response)
# Group Policy:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
Setting: Network security: LAN Manager authentication level
Value: Send NTLMv2 response only. Refuse LM & NTLM
# Registry equivalent:
reg add "HKLMSYSTEMCurrentControlSetControlLsa" /v LmCompatibilityLevel /t REG_DWORD /d 5 /f
# Values: 0=LM+NTLM, 1=NTLMv2 if negotiated, 2=NTLMv2 only, 3-5=NTLMv2 + refuse LM/NTLMEnforcing LDAP Signing and Channel Binding
Unsigned LDAP traffic is vulnerable to man-in-the-middle attacks where an attacker intercepts and modifies LDAP queries and responses. LDAP channel binding prevents relay attacks against LDAPS (LDAP over TLS). Both should be enforced on all domain controllers.
# Require LDAP signing on domain controllers
# Group Policy (applied via Default Domain Controllers Policy):
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
Setting: Domain controller: LDAP server signing requirements
Value: Require signing
# Registry (on DCs):
reg add "HKLMSYSTEMCurrentControlSetServicesNTDSParameters" /v "LDAPServerIntegrity" /t REG_DWORD /d 2 /f
# 0=None, 1=Negotiate signing, 2=Require signing
# Require LDAP channel binding
reg add "HKLMSYSTEMCurrentControlSetServicesNTDSParameters" /v "LdapEnforceChannelBinding" /t REG_DWORD /d 2 /f
# 0=Never, 1=When supported, 2=Always
# Before enforcing, audit which clients are sending unsigned LDAP binds
# Event ID 2889 in the Directory Services log on each DC indicates a
# client performing unsigned LDAP bind
Get-WinEvent -LogName "Directory Service" -FilterXPath "*[System[EventID=2889]]" |
Select-Object TimeCreated, Message |
Format-ListSecuring SYSVOL with DFS-R
SYSVOL contains Group Policy Objects and logon scripts that execute on every domain-joined machine. If SYSVOL is compromised, an attacker can deploy malicious scripts to every computer in the domain. Ensure SYSVOL is replicated using DFS-R (Distributed File System Replication) rather than the deprecated FRS (File Replication Service). All Windows Server 2012+ domains should already use DFS-R, but verify:
# Check current SYSVOL replication mechanism
# On a domain controller:
dfsrmig /getglobalstate
# Output "Eliminated" means DFS-R is in use (correct)
# Output "Start" or "Prepared" means migration is incomplete
# If still using FRS, complete the DFS-R migration:
dfsrmig /setglobalstate 0 # Prepare state
# Wait for all DCs to reach Prepared state, then:
dfsrmig /setglobalstate 1 # Redirected state
# Wait for all DCs to reach Redirected state, then:
dfsrmig /setglobalstate 2 # Eliminated (FRS removed)
# After migration, restrict SYSVOL permissions
# SYSVOL share permissions should be:
# Administrators: Full Control
# Authenticated Users: Read & Execute (needed for GPO application)
# SYSTEM: Full Control
# Audit SYSVOL for unauthorized script modifications
Get-ChildItem "\$env:USERDNSDOMAINSYSVOL$env:USERDNSDOMAINscripts" -Recurse |
Get-Acl | Format-List Path, AccessMonitoring with Microsoft Defender for Identity
Microsoft Defender for Identity (MDI) provides real-time detection of AD attack patterns and integrates with Microsoft 365 Defender for centralized incident management. Key detections relevant to the attacks discussed in this article:
MDI Detection Coverage:
- Suspected Golden Ticket usage (anomalous TGT)
- Suspected Pass-the-Hash (NTLM lateral movement)
- Suspected Pass-the-Ticket
- Suspected Overpass-the-Hash
- Suspected DCSync attack (replication anomaly)
- Suspected skeleton key malware
- Suspected Kerberoasting
- Suspected AS-REP roasting
- Account enumeration reconnaissance
- Suspicious LDAP queries
- Sensitive account credentials exposed in clear text
- AdminSDHolder modification
# MDI sensor installation (on each DC):
# Download from: https://security.microsoft.com > Settings > Identities > Sensors
.Azure ATP sensor Setup.exe /quiet /log C:MDI_install.log AccessKey="YOUR_KEY"
# Verify sensor status after installation:
Get-Service -Name AATPSensor
# Should show: RunningConfigure MDI to send alerts to your SIEM via the syslog/CEF integration in the MDI portal under Settings > Notifications. This enables correlation with other security events and integration with automated response playbooks.
Active Directory hardening is not a one-time task — it requires continuous monitoring, regular privilege audits, and response to new attack techniques as they emerge. The controls described in this article address the most critical and frequently exploited attack vectors. Prioritize adding privileged accounts to Protected Users, enabling Credential Guard on workstations, enforcing NTLMv2-only, requiring LDAP signing, and deploying MDI sensors as the highest-impact immediate actions. Build from there with the remaining controls as your change management capacity allows.
