Domain Controller Security Hardening: A Baseline Checklist for Protecting Active Directory DCs

Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
A domain controller that is compromised equals a domain that is compromised. Every additional service, unnecessary admin account, or unsecured protocol on a DC increases the probability of that outcome. DC hardening is not a one-time event -- it requires a baseline GPO, a restricted admin model, continuous monitoring, and regular review. This guide covers the most impactful hardening controls and their implementation.
Access Control: Restrict Who Can Log On to DCs
No standard user account should ever log onto a domain controller. Implement the following logon restrictions via GPO on the Default Domain Controllers Policy: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. 'Allow log on locally': restrict to Domain Admins and specific Tier 0 break-glass accounts. 'Allow log on through Remote Desktop Services': restrict to dedicated DC management accounts -- ideally no interactive RDP at all; use WinRM from a PAW. 'Deny log on as a batch job': add Domain Users to deny standard users from running scheduled tasks interactively on DCs. 'Deny log on as a service': block standard users from running services on DCs. 'Allow log on through Remote Desktop Services': if RDP is required, limit to a specific Tier 0 admin group with JIT access. All administrative connections to DCs should originate from a Privileged Access Workstation (PAW) -- a dedicated, hardened management workstation used only for Tier 0 admin tasks. Connections from standard workstations to DCs for administration introduce the risk of pass-the-hash lateral movement from those workstations to the DCs.
Eliminate Unnecessary Services and Software
A domain controller should run only the AD DS role and its dependencies. Audit all running services: Get-Service | Where-Object { $_.Status -eq 'Running' } | Select-Object Name, DisplayName, StartType. Compare against the expected minimum set for a DC: Active Directory Domain Services, Active Directory Web Services, DNS Client, DNS Server (if DC also serves DNS), DFS Replication, File Replication (if applicable), Group Policy Client, Kerberos Key Distribution Center, Net Logon, Remote Procedure Call, Security Accounts Manager, Windows Event Log, Windows Remote Management (WinRM), and Windows Time. Everything else should be disabled or not installed. Commonly found on DCs that should not be there: DHCP Server (run on a separate server), IIS (never on a DC), SQL Server (never on a DC), Print Spooler (disable -- exploitable via PrinterBug/SpoolSample), Windows Remote Management with CredSSP enabled. The Print Spooler is particularly important: stop and disable the service on all DCs via GPO (Computer Configuration > Preferences > Control Panel Settings > Services > Stop Print Spooler, Start Mode = Disabled). This mitigates the Printer Bug attack used to coerce DCs to authenticate to attacker-controlled unconstrained delegation hosts.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Network Protocol Hardening
Disable NTLMv1 completely on all DCs: via GPO, Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > 'Network security: LAN Manager authentication level' = 'Send NTLMv2 response only. Refuse LM and NTLM'. Enable SMB signing and encryption: 'Microsoft network server: Digitally sign communications (always)' = Enabled. 'Microsoft network server: Digitally sign communications (if client agrees)' = Enabled (covered by above). LDAP signing and channel binding: 'Domain controller: LDAP server signing requirements' = 'Require signing'. 'Domain controller: LDAP server channel binding token requirements' = 'Always'. These settings prevent NTLM relay attacks against LDAP on the DC -- LDAP without signing is directly exploitable via NTLM relay to perform DCSync or add users to Domain Admins. Disable SMBv1: Set-SmbServerConfiguration -EnableSMB1Protocol $false. Restrict RPC: configure RPC port range restrictions via GPO to a predictable range and open only that range in host-based firewall rules.
Audit Policy and Monitoring
Apply the full advanced audit policy to DCs via the Default Domain Controllers Policy GPO. Critical audit categories for DCs: Account Logon > Audit Credential Validation = Success and Failure (captures all authentication attempts including NTLM pass-through). Logon/Logoff > Audit Logon = Success and Failure. Object Access > Audit Directory Service Changes = Success (Event ID 5136 -- any AD object modification). Object Access > Audit Other Object Access Events = Success (Event ID 4698 -- scheduled task creation). Account Management > Audit Security Group Management = Success. Privilege Use > Audit Sensitive Privilege Use = Success. Policy Change > Audit Audit Policy Change = Success. DS Access > Audit Directory Service Access = Success. Increase the Security event log size to 1 GB on DCs (a 20 MB log fills in hours on an active DC). Forward all Security events to your SIEM in near-real-time. Alert on any interactive logon to a DC from a non-PAW source (Event ID 4624 with Logon Type 2 or 10 from a workstation not in the PAW IP range).
Apply the Microsoft Security Baseline GPO
Microsoft provides the Security Compliance Toolkit (SCT) which includes pre-built GPO baselines for Windows Server domain controllers. Download from the Microsoft Download Center and import into Group Policy using the LGPO tool included. The DC baseline GPO includes: account lockout policy hardened settings, BitLocker configuration for DC OS drive, Defender AV policy, Windows Firewall rules, Internet Explorer/Edge restrictions, RDP security settings, and many security options. Apply the baseline to the Domain Controllers OU as a linked GPO with high priority (below any organization-specific security GPOs). After applying, test DC functionality: replication, authentication, DNS, DHCP (if applicable), and all dependent services. The baseline may conflict with legacy configurations -- review the SCT security guide for known issues and exceptions. Supplement with the CIS Windows Server benchmark, which covers additional settings beyond the Microsoft baseline. Run the CIS Configuration Assessment Tool (CIS-CAT) to score your DC against the benchmark.
The bottom line
DC hardening is the highest-leverage security investment in an Active Directory environment. The core controls are: restrict logon to Tier 0 PAW accounts only, disable Print Spooler and all non-essential services, enable LDAP signing and channel binding, disable NTLMv1, apply the Microsoft Security Compliance Toolkit baseline GPO, and forward all Security events to a SIEM with alerting on DC interactive logins. Review the DC hardening posture quarterly -- services and configurations drift over time.
Frequently asked questions
Should domain controllers be joined to the production domain?
Yes -- domain controllers are members of the domain they host. What matters from a security perspective is that the administrative accounts used to manage DCs are Tier 0 accounts (used only for DC administration, stored in a separate OU not subject to sync, protected by PAM and phishing-resistant MFA) and that those accounts do not log on to any non-Tier-0 systems. The risk is not the DC's domain membership -- it is the admin accounts for the DC being used on lower-trust systems.
How many domain controllers should an organization have?
At minimum, two DCs per AD site for redundancy (if one DC fails, domain authentication continues from the second). The PDC Emulator FSMO role should be on a highly available DC. For security, having fewer DCs reduces the attack surface and the number of systems that need to be protected at Tier 0 hardening levels. Most organizations run 2 to 4 DCs per site, and large enterprise environments may run 8 to 12 globally. Virtualized DCs should be on Tier 0 hypervisors -- a hypervisor admin can extract the DC's memory and recover credentials, so the hypervisor hosting DCs must be protected at the same level as the DCs themselves.
Can a domain controller also serve DNS?
Yes and this is the default configuration -- AD-integrated DNS runs on DCs by default. AD-integrated DNS stores zone data in the AD database and replicates automatically. Running DNS on DCs is acceptable provided the DC hardening baseline is applied (including DNS server hardening: disable zone transfers to unauthorized IPs, restrict recursive queries, enable DNSSEC for sensitive zones). The DnsAdmins group risk (DLL loading for privilege escalation) is the primary concern -- restrict DnsAdmins membership to the minimum necessary accounts.
How often should DC hardening be reviewed?
At minimum quarterly. Trigger an immediate review after: any security incident involving a DC, any major Windows Server update (some CU updates change security defaults or add new settings), any change to DC roles or services, and any change to the Tier 0 admin group membership. Automated compliance scanning (CIS-CAT, Tenable SC, or Microsoft Defender for Cloud) configured to scan DCs weekly and report deviations from the baseline is the most reliable approach -- configuration drift happens slowly and is easily missed without automated detection.
What are the highest-risk services to leave running on a domain controller?
Ranked by incident frequency: Print Spooler (ms-rprn RPC forced authentication, PrintNightmare SYSTEM execution -- disable on all DCs immediately), Remote Registry (allows remote registry reads/writes that facilitate lateral movement), SNMP (often misconfigured with default community strings, information disclosure), Windows Remote Management on default port 5985 without HTTPS (exposes PowerShell remoting without encryption), and Task Scheduler remote interface (allows remote task creation by admins). Beyond services, disable unused Windows features: Telnet, FTP Server, Internet Information Services, TFTP Client, Windows Media Player, and Windows Subsystem for Linux should all be absent from DCs. Run Get-WindowsFeature on DCs and compare to a documented approved feature list.
What is the recommended patch management process for domain controllers and how do you minimize disruption during patching?
DCs require a more controlled patch process than standard servers because they hold FSMO roles, service AD replication, and must maintain availability. The recommended process: patch one DC at a time in each site, never simultaneously, to maintain at least one available DC per site for authentication. Before patching, verify replication health with repadmin /replsummary and repadmin /showrepl -- do not patch a DC with existing replication errors, as the patch reboot can turn a warning into an outage. Patch the infrastructure master DC last in each domain. For PDC emulator (which handles time synchronization and password changes): patch it last and restore it first if rollback is needed. Apply patches in a test domain or non-production environment at least one patch cycle before production. Use maintenance windows of at least 3 hours per DC to account for the patch installation, reboot, and post-boot stabilization. After each DC reboot, verify: net logon service is running (Event ID 5719 indicates a problem), replication is functioning (repadmin /replsummary shows no errors), and Kerberos is issuing tickets (klist from a workstation). The CIS DC hardening benchmark recommends creating a DC hardening checklist that includes patch verification steps.
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, daily, 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 every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.
