Active Directory Security Checklist: 20 Controls to Audit Right Now

Most Active Directory security guides are written for enterprise security teams with dedicated tools and weeks to burn. This checklist is for the IT director at a credit union or small business who has a half day and needs to know what's actually exploitable.

Twenty controls, organized by attack phase. Each one includes a quick check you can run and a remediation step if it fails.

How to Use This Checklist

Work through these in order. The first sections cover the highest-impact, most commonly exploited controls. A "fail" on any control in the first two sections warrants immediate remediation — these are the controls that lead to domain compromise in a real attack.

Not every control requires you to be a security expert. Most require a domain user account and access to Group Policy Management Console or PowerShell.

Section 1: NTLM Relay Prevention (Critical)

These five controls collectively prevent the most common domain compromise attack chain.

☐ 1. SMB signing enforced on all domain members

Quick check: Get-SmbServerConfiguration | Select RequireSecuritySignature — should return True on every server. Run this on each server individually, or use Invoke-Command -ComputerName (Get-ADComputer -Filter *).Name -ScriptBlock { Get-SmbServerConfiguration | Select Name, RequireSecuritySignature } to check across the domain at once.

Fix: Group Policy → Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → "Microsoft network server: Digitally sign communications (always)" → Enabled. Apply to all OUs, not just Domain Controllers. Full context: How to Prevent NTLM Relay Attacks.

☐ 2. LDAP signing required on domain controllers

Quick check: Group Policy Results on a DC — look for "Domain controller: LDAP server signing requirements" = Require signing.

Fix: GPO applied to Domain Controllers OU → same path as above → "Domain controller: LDAP server signing requirements" → Require signing.

☐ 3. LDAP channel binding enabled on domain controllers

Quick check: Check HKLM\System\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding on DCs — value 2 = Always.

Fix: GPO → "Domain controller: LDAP server channel binding token requirements" → Always. (Note: requires domain/forest functional level 2016 or higher.)

☐ 4. ADCS Web Enrollment accessible over HTTP

Quick check: Navigate to http://[CA-server]/certsrv/ from inside the network. If you get a login prompt or are auto-authenticated, ESC8 exposure exists.

Fix: If Web Enrollment is not used, disable it in Server Manager. If it's needed, require HTTPS and enable EPA in IIS. Full steps: ADCS Misconfiguration: How to Find and Fix It.

☐ 5. Extended Protection for Authentication (EPA) enabled on ADCS

Quick check: IIS Manager on CA server → Web Enrollment site → Authentication → Windows Authentication → Advanced Settings → Extended Protection = Required.

Fix: Enable EPA as above. This requires HTTPS to be configured first — HTTP does not support EPA.

Section 2: ADCS Certificate Template Hardening (Critical)

☐ 6. No certificate templates allow enrollee-supplied Subject Alternative Names

Quick check: certtmpl.msc → each template → Properties → Subject Name → "Supply in the request" should NOT be selected for any template with broad enrollment rights.

Fix: Change to "Build from this Active Directory information." For templates that genuinely need SAN flexibility, restrict enrollment to a specific limited security group.

☐ 7. Template enrollment rights restricted (no Domain Users or Authenticated Users on sensitive templates)

Quick check: Each template in certtmpl.msc → Security tab → look for Authenticated Users or Domain Users with Enroll rights on templates that provide client authentication.

Fix: Remove overly broad enrollment rights. Create specific security groups for each template and add only the accounts that legitimately need certificates from that template.

☐ 8. No accounts have unexpected Write or FullControl on certificate templates (ESC4)

Quick check: Each template → Security tab → look for non-admin accounts with Write Properties or Full Control.

Fix: Remove non-admin Write access from templates. Template modification rights belong to Certificate Managers and Domain Admins only.

Section 3: Credential and Kerberos Security (High)

☐ 9. Service accounts with SPNs have strong, recently rotated passwords

Quick check:

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties PasswordLastSet, PasswordNeverExpires | Select SamAccountName, PasswordLastSet, PasswordNeverExpires

Any account with PasswordNeverExpires = True or PasswordLastSet older than 12 months is high risk.

Fix: Rotate to 25+ character random passwords. Migrate to gMSA where the application supports it. Full guide: Kerberoasting Attack Explained.

☐ 10. No accounts have pre-authentication disabled (AS-REP roasting exposure)

Quick check:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth | Select SamAccountName

Any result here is a finding.

Fix: Enable pre-authentication on all user accounts. Pre-auth disabled is rarely needed for legitimate purposes.

☐ 11. No user accounts have unconstrained delegation enabled

Quick check:

Get-ADUser -Filter {TrustedForDelegation -eq $true} | Select SamAccountName
Get-ADComputer -Filter {TrustedForDelegation -eq $true} | Select Name

User accounts with unconstrained delegation are almost always misconfigured. Computer accounts with it should be reviewed carefully.

Fix: Remove unconstrained delegation from user accounts. For computer accounts, migrate to constrained or resource-based constrained delegation (RBCD).

Section 4: Privileged Access Hygiene (High)

☐ 12. Domain admin account count is minimal and justified

Quick check:

Get-ADGroupMember "Domain Admins" -Recursive | Select Name, ObjectClass

Every member should be a named individual with a documented business need. Service accounts, shared accounts, or "IT Admin" generic accounts in Domain Admins are red flags.

Fix: Remove accounts that don't require domain admin. Create separate admin accounts for privileged tasks (don't use the DA account for daily work).

☐ 13. Domain admins don't have active sessions on non-DC machines

Quick check: BloodHound "Domain Admin Sessions" query shows where DA accounts have active sessions. Alternatively: look at currently logged-in users on file servers and workstations.

Fix: Domain admin accounts should only be used from dedicated jump hosts/PAWs (Privileged Access Workstations), never from general-purpose machines. Log off DA sessions when not actively needed.

☐ 14. Local administrator password solution (LAPS) deployed on all machines

Quick check: Legacy LAPS: Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd | Where {$_."ms-Mcs-AdmPwd" -ne $null} — Windows LAPS (Server 2022+ / Win 11): Get-ADComputer -Filter * -Properties msLAPS-Password | Where {$_."msLAPS-Password" -ne $null}. If neither returns results, LAPS is not deployed.

Fix: Deploy Microsoft LAPS (or Windows LAPS, available natively in Windows 11/Server 2022+). Without LAPS, every machine sharing the same local admin password is vulnerable to pass-the-hash lateral movement.

☐ 15. DCSync rights are held only by domain controllers and explicit admin groups

Quick check: (see DCSync Attack: What Is It for the full PowerShell script) — look for accounts with DS-Replication-Get-Changes rights on the domain root that are not DC machine accounts.

Fix: Remove replication rights from non-DC accounts. Review any service accounts or legacy accounts that hold these permissions.

Section 5: Monitoring and Detection (Medium)

☐ 16. Advanced Security Audit Policy enabled on domain controllers

Quick check: auditpol /get /subcategory:"Directory Service Access" on a DC — should show Success and Failure auditing enabled.

Fix: GPO applied to Domain Controllers OU → Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → DS Access → Audit Directory Service Access → Success and Failure.

☐ 17. Event ID 4662 (replication access) alerts configured

Quick check: Does any monitoring solution alert when Event ID 4662 occurs with replication ACE GUIDs and a non-DC subject? If no SIEM or MDI: this detection is not in place.

Fix: Microsoft Defender for Identity has built-in DCSync detection. Windows Event Forwarding (WEF) can collect DC logs centrally for review.

☐ 18. Certificates issued by your CA in the last 90 days reviewed

Quick check: On the CA, open Certification Authority console → Issued Certificates → filter by date. Look for unexpected requesters, machine account certificates requested by user accounts, or certificates from unusual templates.

Fix: Enable audit logging on the CA (Event IDs 4886/4887) and review quarterly.

Section 6: Network Controls (Medium)

☐ 19. Network segmentation isolates domain controllers from user workstations

Quick check: Can a standard workstation on the user VLAN initiate connections directly to domain controllers on non-standard ports? DC traffic should be restricted to what's operationally necessary.

Fix: Firewall rules should restrict workstation-to-DC communication to only the required protocols (Kerberos, LDAP, DNS, SMB for SYSVOL). SMB direct from workstations to DCs is not typically required.

☐ 20. Backups are immutable and tested

Quick check: Are backup files or backup agents accessible from domain-joined machines? In ransomware scenarios, attackers actively target and delete backups before deploying ransomware.

Fix: Offline or air-gapped backups. Immutable backup storage (object lock). Regular restoration tests — a backup that hasn't been restored successfully is not a backup.

Scoring Your Results

Fails in Sections 1-2 Action
Any fail Immediate remediation required — these are the controls that lead to domain compromise
Fails in Sections 3-4 Action
1-3 fails Prioritized remediation within 30 days
4+ fails High risk — prioritize AD security project
Fails in Sections 5-6 Action
Multiple fails Detection and recovery gaps — address after prevention controls

What This Checklist Doesn't Replace

This checklist identifies the most common, highest-impact AD security misconfigurations. It does not:

A full Active Directory penetration test validates these controls under realistic attack conditions, identifies the specific attack paths that reach your critical systems, and provides the documented evidence that NCUA examiners and cyber insurance carriers want to see.

→ For a deeper understanding of what a penetration test adds beyond this checklist: Active Directory Penetration Testing for Credit Unions: A Complete Guide

Stay sharp. Stay prepared. — ThreatForged AI

Written by Ryan Kucher, founder of ThreatForged AI. Book a scoping call to have ThreatForged AI validate these controls against real attack scenarios.