Domain Controller Hardening: The Seven Settings That Matter Most

Domain Controller Hardening: The Seven Settings That Matter Most

A quarterly DC review does not need to be a sprawling audit. Most breaches that pivot through Active Directory exploit a small set of misconfigured defaults that ship in environments built before hardening guidance caught up. The seven items below are the ones that show up repeatedly in post-incident reviews. Each takes under 30 minutes to verify and remediate.

Run these against every DC in your estate, not just the PDC emulator. Retrievy's GPO X-Ray can surface policy gaps across your OU hierarchy if you want a fleet-wide view rather than a host-by-host walk.

1. LDAP signing enforced

   • Bad: Domain controller: LDAP server signing requirements is set to None or Negotiate signing. Clients can bind over unsigned LDAP, enabling relay attacks (the class of technique documented under MITRE ATT&CK T1557).
   • Good: GPO set to Require signing. Pair it with Network security: LDAP client signing requirements also set to Require signing so the DC-to-DC traffic matches.
   • Why: Unsigned LDAP lets an attacker relay authentication to your DC and query or modify the directory without cracking a single credential.

2. LDAP channel binding enabled

   • Bad: LdapEnforceChannelBinding registry value is absent or set to 0. TLS-wrapped LDAP connections are not bound to the channel, leaving them vulnerable to LDAP relay even over port 636.
   • Good: HKLM\System\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding = 2. Microsoft's March 2020 hardening guidance (and subsequent ADV190023) describes this value.
   • Why: Channel binding ties the LDAP session to the TLS certificate, defeating relay even when an attacker intercepts an encrypted connection.

3. SMB signing required

   • Bad: Microsoft network server: Digitally sign communications (always) is disabled. SMB relay (T1557.001) becomes trivially executable with tools that have been publicly available for years.
   • Good: Both Microsoft network client and Microsoft network server signing policies set to Enabled and Always. On Windows Server 2022, SMB signing is required by default for DC-to-DC traffic, but verify non-default DCs explicitly.
   • Why: A single unsigned SMB session on a DC can be relayed to obtain a SYSTEM-level authentication token.

4. SMB v1 disabled

   • Bad: SC query lanmanserver shows mrxsmb10 driver loaded, or Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol returns Enabled. The SMBv1 protocol surface includes CVE-2017-0144 (EternalBlue) and the broader MS17-010 family.
   • Good: SMBv1 feature removed via Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol and Set-SmbServerConfiguration -EnableSMB1Protocol $false. Confirm with Get-SmbServerConfiguration | Select EnableSMB1Protocol.
   • Why: No modern Windows client or application requires SMBv1. Its continued presence is a liability with no operational benefit.

5. NTLM auditing active

   • Bad: Network security: Restrict NTLM policies are all set to Disabled. You have no visibility into which services, accounts, or hosts are still negotiating NTLM, making it impossible to scope a future block without causing outages.
   • Good: Set Audit NTLM authentication in this domain to Enable all and Audit incoming NTLM traffic to Enable auditing for all accounts. Review Event ID 8004 (NTLM blocked) and 4776 (credential validation) weekly for 30 days before enforcing any block.
   • Why: Auditing before blocking prevents service disruption and gives you the dependency map needed to reduce NTLM scope safely over a 90-day window.

6. RPC access restricted

   • Bad: No RPC filters applied. Any authenticated user can invoke sensitive RPC interfaces, including those used by DCSync (MS-DRSR) and remote service creation (T1543.003).
   • Good: Apply RPC endpoint mapper filters via Windows Firewall GPO to restrict MS-DRSR access to replication partners only. Verify with netsh rpc filter show filter. Accounts that are not domain controllers should never appear in replication-related RPC calls.
   • Why: Restricting RPC at the endpoint forces attackers to use an account that is explicitly allowed to replicate, making DCSync attempts visible and harder to execute.

7. DCSync delegation hygiene

   • Bad: Accounts outside the built-in Domain Controllers and Domain Admins groups hold Replicating Directory Changes and Replicating Directory Changes All permissions on the domain naming context. Run (Get-Acl "AD:\DC=yourdomain,DC=com").Access | Where-Object { $_.ActiveDirectoryRights -match "DS-Replication" } to check.
   • Good: Only machine accounts for DCs and explicitly approved service accounts (Azure AD Connect, backup agents) hold replication rights. Review the list quarterly and remove any account that cannot be explained. Flag with Retrievy's GPO X-Ray if drift is detected between review cycles.
   • Why: DCSync (T1003.006) does not require malware on a DC. A single over-privileged user account with replication rights can dump every credential hash in the domain from a workstation.

Verification cadence: Run items 1 through 4 as part of every quarterly review. Run items 5 through 7 monthly, because delegation and NTLM usage drift faster than firewall rules. If you automate nothing else, automate the DCSync ACL check in item 7. It is the highest-impact finding and the easiest to overlook.