Active Directory Hardening Checklist (2026)

Introduction: Why AD Hardening Still Fails in Mature Environments

Most enterprise Active Directory environments have some hardening in place. Domain controllers are on a dedicated VLAN. Antivirus is deployed. Password policies are set. A penetration test two years ago came back with only medium-severity findings. And yet the breach investigation still starts — and ends — at AD.

The reason is not that the controls are wrong. The reason is that partial hardening creates a false confidence gap. Tier 0 assets get a GPO baseline, but no one validates that the baseline is applied. Delegation is constrained on new accounts, but legacy service accounts from a 2014 migration still carry unconstrained delegation. Kerberos AES enforcement is on the backlog, blocked by a line-of-business app no one has tested against AES.

This checklist is built around that gap. Every section maps a control to its attack-reduction value, an effort estimate, and a measurable validation step. The goal is not to produce a compliance checkbox — it is to give your security operations team a scored, tier-aware playbook they can execute, automate, and repeat.

Scope and Threat Model

What this checklist covers

This guide covers the identity and administrative plane of Active Directory: account controls, Kerberos and NTLM protocol hardening, delegation governance, Group Policy baseline enforcement, and domain controller security. It follows a three-tier model aligned to Microsoft's Enterprise Access Model and/or Tiering Model — Tier 0 (identity infrastructure), Tier 1 (server and service layer), and Tier 2 (user endpoint layer).

What this checklist does not cover

Network segmentation, firewall policy, endpoint detection, and SIEM tuning are out of scope here — not because they are unimportant, but because they are addressed in companion guides. The controls in this document assume network isolation of Tier 0 is already in place. If it is not, start with your network segmentation baseline before applying identity controls.

Attack paths mapped to controls

Each major control in this checklist maps to one or more known attack techniques documented by MITRE ATT&CK and field-confirmed by the Five Eyes advisory series. The table below shows which hardening actions reduce which attack paths.

For detailed detection signatures for each of these attacks, see Five Eyes AD Attacks: Detection and Mitigation.

Hardening Design Principles (Before You Touch Production)

Before applying any hardening control, align your team on four principles that prevent common mistakes — particularly the mistake of hardening the wrong layer first.

• Principle 1 — Protect Tier 0 first. All other hardening work is undermined if domain controllers, the forest root, and identity infrastructure itself can be compromised. Tier 0 controls take priority in every implementation wave.
• Principle 2 — Enforce administrative boundaries. Tier 0 administrators must not use the same accounts to access Tier 1 and Tier 2 systems. This is Segregation of Duties. The Enterprise Access Model and Tiering Model are frameworks to help you design and enforce these boundaries. If your environment has not yet implemented tiering, this checklist still applies — but you must be disciplined in applying controls to the right accounts and systems based on their risk level. Do not apply Tier 0 controls to accounts that are used for day-to-day work, even if they have privileged access — instead, use this checklist to create a clean break between the accounts that can administer AD and the accounts that cannot. The attack containment value of hardening is only realized when the boundaries are enforced; if admins log on to servers with their DA accounts, an attacker who compromises that server gets the same access as if they had compromised a DC directly. Flat admin access destroys containment.
• Principle 3 — Remove standing privilege. Permanent group membership in Domain Admins, Enterprise Admins, and equivalent groups dramatically increases blast radius. Move toward Just-In-Time (JIT) and Just-Enough-Administration (JEA) where supported. At minimum, audit and remove unnecessary permanent memberships every 30 days.
• Principle 4 — Assume compromise and monitor continuously. Controls without detection are not controls — they are one-time locks on an open window. Every hardening action in this checklist has a paired validation command or log event ID that proves the control is functioning.

Decision Matrix: Quick Wins vs Structural Controls

Not every control can be deployed in week one. Use this matrix to sequence implementation based on risk reduction versus operational disruption:

Baseline Readiness and Prerequisites

Hardening applied to an environment you do not fully understand creates as many risks as it removes. Before executing any Tier 0, 1, or 2 controls, confirm the following readiness gates are met.

Identity inventory and privilege mapping

Run AD-Hardening-Assessment-Baseline.ps1 (see Script Set 1 below) to capture a snapshot of current privileged accounts, delegation configurations, and encryption type assignments. You need this baseline to measure the impact of each change, and to identify legacy misconfigurations that are invisible to normal monitoring.

At minimum, verify:

• You have an accurate list of every account in Domain Admins, Enterprise Admins, Schema Admins, and Administrators.
• You know which accounts have AdminCount=1 and why.
• You have identified all service accounts (user objects with SPNs) and their business owners.
• You know which computer accounts have unconstrained or constrained delegation configured.

Backup and recovery readiness gates

A hardening change that corrupts authentication or breaks domain controller replication can bring your environment down. Before any production change, verify:

• A recent system state backup exists for each domain controller (taken within 24 hours).
• You have tested an AD authoritative restore procedure in the last 90 days.
• You have a documented rollback plan for each change (GPO link, attribute revert, etc.).
• Recovery contact list and out-of-band communication channel are up to date.

Logging and retention prerequisites

You cannot validate that controls are working without logs. Before hardening, ensure:

• DC Security event log is at least 1 GB with a 90-day SIEM retention window.
• Advanced Audit Policy is configured: Account Logon, Account Management, Directory Service Access, Privilege Use, Policy Change at Success+Failure.
• Event ID 4625, 4648, 4672, 4768, 4769, 4776, 4964, 5136, 5141 are being forwarded to SIEM.
• NTLM Operational log (Microsoft-Windows-NTLM/Operational) is enabled on all DCs.

Change-control and rollback requirements

All Tier 0 changes must go through a change management process. Even quick wins like adding an account to Protected Users can break legacy application authentication. For each change:

• Submit a change record with rollback steps, test results, and approval from the AD team lead.
• Schedule changes during a defined maintenance window with monitoring coverage active.
• Use WhatIf / read-only modes in PowerShell before committing any automated changes.
• Document the change in the identity change log for audit trail purposes.

Tier 0 Hardening Checklist (Highest Priority)

Tier 0 is the identity infrastructure plane — domain controllers, the AD database, ADFS, certificate authorities, privileged identity management systems, and the accounts used to administer them. A single compromised Tier 0 asset gives an attacker the ability to control every identity in your forest. Apply these controls before any other tier.

Core Controls

• Domain controller OS hardening baseline. All DCs must run a supported OS version (Windows Server 2022 minimum recommended). Apply the Microsoft Security Baseline GPO. Disable all unnecessary services: Task Scheduler (for non-DC tasks), Print Spooler, LLMNR, NetBIOS over TCP/IP. Run Get-SmbServerConfiguration and verify RequireSecuritySignature = True and EnableSMB1Protocol = False on all DCs.
• Privileged account controls: Protected Users and PAW enforcement. Enroll all Domain Admins, Enterprise Admins, Schema Admins, and any account with AdminCount=1 in the Protected Users security group. This prevents NTLM authentication, caches no credentials to LSA, and enforces AES Kerberos. All administrative actions in Tier 0 must originate from a Privileged Access Workstation. Enable MFA for all Tier 0 interactive logons.
• Kerberos and NTLM hardening sequence. Before restricting protocols, run AD-Hardening-Kerberos-NTLM-Checks.ps1 to inventory RC4-dependent accounts and NTLM authentication sources. Set msDS-SupportedEncryptionTypes to 24 (AES128+AES256) on all privileged accounts and service accounts. Configure GPO "Network Security: Configure encryption types allowed for Kerberos" to AES128 + AES256 only after confirming no RC4-only dependencies. Set LmCompatibilityLevel to 5 (NTLMv2 only) on all DCs.
• AD CS and certificate trust controls. Audit all certificate templates for dangerous configurations (ENROLLEE_SUPPLIES_SUBJECT flag, no Manager Approval, overly permissive enrollment ACLs). These are the root conditions for ESC1-ESC8 attacks. Use Audit-ADCSTemplates.ps1 to enumerate vulnerable templates. Disable any template that grants enrollment to Domain Users or Authenticated Users without business justification.
• Delegation restrictions and admin session isolation. No account outside of domain controllers should have TrustedForDelegation = True (unconstrained delegation). Remove it from all non-DC computer accounts and user objects. For service accounts that legitimately require delegation, convert to constrained delegation targeting only required SPNs, or preferably resource-based constrained delegation (RBCD) scoped to a specific service account. Set ms-DS-MachineAccountQuota to 0 on the domain to prevent non-admin accounts from joining machines to the domain.
• Tier 0 monitoring and alert rules. Configure real-time alerts for: (a) any addition to Domain Admins, Enterprise Admins, or Schema Admins (Event 4728, 4756); (b) any logon with sensitive privilege use (Event 4672) from a workstation that is not a known PAW; (c) DCSync-equivalent operations — accounts performing directory replication that are not DCs (Event 4662 with GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2); (d) krbtgt password reset attempts.

Tier 0 Priority Table

Tier 1 Hardening Checklist (Server and Platform Layer)

Tier 1 covers member servers: file servers, application servers, web services, SQL instances, and the management plane that operates them. The primary Tier 1 attack vector is lateral movement via cached credentials — an attacker compromises a Tier 2 workstation, steals service account credentials, and pivots to servers where the same account is reused. Prevent this by enforcing strict account separation, strong remote access authentication, and least-privilege service identities.

• Dedicated Tier 1 admin accounts. No Tier 0 account (Domain Admin or equivalent) should ever interactively log on to a member server. Create per-tier admin accounts (e.g., T1-Username) restricted via AD Logon Workstations so they can authenticate only from designated Tier 1 management servers — never from general workstations.
• GPO security baseline enforcement. Apply the Microsoft Security Compliance Toolkit baseline for Windows Server 2022 to all member servers. Critical settings: RestrictAnonymous = 2, LmCompatibilityLevel = 5, LLMNR disabled via GPO, SMB signing required, Advanced Audit Policy configured for account logon, object access, privilege use, and directory service changes.
• Service account migration to gMSA. Conventional service accounts with static passwords are a high credential-reuse risk. Group Managed Service Accounts (gMSA) auto-rotate passwords every 30 days. Migration: verify KDS root key (Get-KdsRootKey), create gMSA with New-ADServiceAccount, update service bindings on each host. Target your top 10 highest-permission service accounts in the Day 31-60 window.
• Remote access hardening: RDP, WinRM, and SMB. RDP must enforce Network Level Authentication (NLA) and be restricted to management VLAN source IPs. WinRM listeners must use HTTPS (port 5986) with a valid certificate — never HTTP. Confirm SMB signing and SMB1 status on each server: Get-SmbServerConfiguration | Select EnableSMB1Protocol, RequireSecuritySignature. Disable Telnet, FTP, and SNMPv1/v2; replace with SFTP, WinRM, or SNMPv3 with authentication.
• LSA protection and Credential Guard. Enable LSA Protection (RunAsPPL = 1) on all servers to block LSASS memory dumps. On Windows Server 2016+, enable Windows Defender Credential Guard via UEFI lock to prevent pass-the-hash and pass-the-ticket from the server layer.
• Monthly drift detection and patch compliance. Run AD-Hardening-PrivilegedGroup-DriftReport.ps1 monthly against the Tier 1 admin group baseline. Critical and important security patches must be applied within 30 days; actively exploited CVEs within 7 days.

Tier 2 Hardening Checklist (User and Endpoint Layer)

Tier 2 is your largest attack surface: end-user workstations and the standard user accounts that operate them. Attackers gain initial access at Tier 2 through phishing, drive-by downloads, or removable media, then use privileged local admin rights or reused credentials to escalate. The goal at Tier 2 is not zero risk — it is preventing any Tier 2 credential or session from being usable against Tier 1 or Tier 0 assets.

• Local administrator account management with LAPS. Deploy Windows LAPS to all workstations to ensure every machine has a unique, auto-rotating local administrator password. This eliminates the single biggest lateral movement enabler: a shared local admin password that works across all endpoints. Windows LAPS (built into Windows 11 22H2+ and Server 2022+) stores passwords in AD or Entra ID and rotates them on a configurable schedule.
• Remove unnecessary local admin group members. Audit local Administrators group membership on all workstations quarterly. Standard users must not be members of local Administrators. Use Get-LocalGroupMember -Group Administrators via a startup script or Defender for Endpoint live query to enumerate violations at scale.
• Credential Guard on all Windows 10/11 workstations. Enable Windows Defender Credential Guard via Group Policy (Device Guard / Virtualization Based Security). This places NTLM hashes and Kerberos TGTs inside a hypervisor-protected memory region that LSASS cannot access directly — preventing in-memory credential extraction tools (Mimikatz, Rubeus) from dumping them even with SYSTEM privileges.
• Protected Users for any privileged accounts visible at Tier 2. If any administrative account (even helpdesk or desktop support) logs interactively on to Tier 2 assets, ensure those accounts are enrolled in Protected Users. This prevents NTLM authentication and credential caching that would expose Tier 1 or Tier 0 scope through a compromised workstation.
• Application control and attack surface reduction (ASR). Enable Windows Defender Attack Surface Reduction rules: block credential stealing from LSASS (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b3), block process creation from Office macros, block executable content in email. Use AppLocker or WDAC to restrict execution to business-approved publishers and paths.

Implementation Roadmap (30/60/90 Days)

PowerShell Automation Pack

The five scripts below are designed for progressive use: run the baseline discovery tool first to establish a pre-hardening snapshot, then execute the validation scripts after each phase to confirm controls are in effect, then schedule the drift and evidence scripts to run on a recurring cadence. All scripts are read-only unless explicitly noted — no configuration changes are made, only reads and reports. Run in a test domain first. Require elevated privileges (Domain Admin or equivalent read access); review the parameter block of each script before execution.

• Script Set 1 — Posture Discovery: AD-Hardening-Assessment-Baseline.ps1 captures the pre-hardening state across privileged accounts, delegation configuration, Kerberos encryption types, NTLM policy, and GPO baseline. Run this before any changes and store the output CSVs as your baseline evidence.
• Script Set 2 — Control Validation: AD-Hardening-Tier0-Validation.ps1 performs 8 pass/fail checks against Tier 0 controls and outputs an HTML compliance report. AD-Hardening-Kerberos-NTLM-Checks.ps1 calculates a 0-100 readiness score, inventories RC4-dependent principals, and scans event logs for recent NTLM authentication.
• Script Set 3 — Audit and Drift Reporting: AD-Hardening-PrivilegedGroup-DriftReport.ps1 saves a privileged group baseline on first run, then compares current membership on subsequent runs and alerts on any changes. AD-Hardening-Audit-Evidence-Export.ps1 produces a full compliance evidence package (text summary + CSVs) suitable for handing to auditors or inserting into a GRC platform.

Script Set 1: Posture Discovery

Script Set 2: Tier 0 and Protocol Validation

Script Set 3: Audit and Drift Reporting

Security Validation and Audit Evidence

Hardening without evidence is indistinguishable from doing nothing, especially during audits. Run AD-Hardening-Audit-Evidence-Export.ps1 monthly to produce a structured evidence package that covers account plane configuration, protocol hardening state, patch compliance, audit policy coverage, and optionally a GPO backup archive. The text summary and companion CSVs can be attached to audit findings, inserted into your GRC platform, or stored in a SharePoint evidence library with a timestamped naming convention.

Track the following KPIs month-over-month as leading indicators of hardening progress and regression:

• Tier 0 account count with AdminCount=1. Should trend downward and stabilize. New entries not in prior baseline = immediate investigation.
• Protected Users enrollment percentage. Target: 100% of accounts with AdminCount=1 enrolled within the first 30 days.
• Privileged group drift events per month. Any addition outside of a Change Advisory Board (CAB)-approved ticket is a security event.
• krbtgt account password age. Must not exceed 180 days. Recommended: quarterly rotation.
• SMB signing coverage. 100% of DCs and Tier 1 servers must show RequireSecuritySignature = True.
• Accounts with unconstrained delegation (non-DCs). Target: zero. Any new entry is an immediate flag.
• RC4-capable Kerberos principals. Should trend toward zero as gMSA migration completes and AES enforcement takes effect.

Operations and Maintenance Cadence

Common Failure Modes and Troubleshooting

Legacy app authentication breakage

The most common reason hardening projects stall is undiscovered legacy applications that rely on NTLMv1, RC4 Kerberos, or SMBv1. Before enforcing restrictions, run AD-Hardening-Kerberos-NTLM-Checks.ps1 to inventory NTLM authentication sources and RC4-capable principals. For targeted testing, create a pilot OU with a test group of accounts and apply the hardened GPO there first — monitor Event 4776 (NTLM auth attempt) and Event 4769 (Kerberos ticket request) for failure codes 0x17 (password expired — often signals RC4) and 0x0D (unsupported encryption type). Exclusions should be time-bounded: document the business owner, the target remediation date, and track them in your GRC platform. Never create permanent NTLM or RC4 exclusions without a signed exception and risk acceptance.

Policy conflicts and precedence

When a hardening GPO appears to have no effect, the most likely cause is a higher-precedence GPO or a local policy override winning the merge. Diagnose with gpresult /H C:\temp\gpresult.html /F on an affected machine — this produces a full resultant set of policy with winning GPO noted per setting. Check: (1) whether the target OU is linked to the correct GPO, (2) whether any GPO higher in the hierarchy sets a conflicting value, (3) whether a WMI filter is excluding the machine, and (4) whether security filtering is missing the computer account. Use "GPO Status: Enabled" and confirm the target machine falls within scope via Get-GPResultantSetOfPolicy. For security-critical GPO settings, test in a shadow OU before production link.

False confidence from point-in-time audits

A compliance audit that passes today does not prevent a privileged group from gaining an unauthorized new member tomorrow. Point-in-time assessment capture the state at a moment — configuration drift can introduce critical exposures within hours. The only defense is continuous or frequent monitoring. Schedule AD-Hardening-PrivilegedGroup-DriftReport.ps1 as a weekly scheduled task on a management server (not a DC). Configure the email alert parameter to notify the security team immediately on any deviation from the saved baseline. Additionally, ensure your SIEM ingests DC Security event logs in real time — Event 4728 (member added to global security group) and 4756 (member added to universal group) should trigger immediate investigation, not a monthly review.

Recovery blockers discovered too late

Many organizations discover their AD backup and recovery process is broken only when they need it. Before starting a hardening project, verify: (1) System State backups of all DCs are completing successfully and are within the tombstone lifetime (default 180 days); (2) the DSRM password is documented, stored in a sealed vault, and tested — a DSRM password that has never been tested is the same as no DSRM password; (3) at least one team member has performed an authoritative restore from backup in a lab within the last year. An AD hardening effort that creates a misconfiguration in a connected forest is recoverable only if you can restore cleanly. Without a tested recovery path, any misconfiguration — including a hardening GPO that blocks all admin authentication — becomes a forest-wide outage.

Resources and References

• Microsoft Learn: Active Directory Domain Services Security Best Practices
• Five Eyes AD Attacks: Detection and Mitigation
• Tier 0 Reference Architecture
• Privileged Access Workstation Deployment Guide
• LAPS Implementation Guide