Most Active Directory compromises exploit settings that a one-day review would have found: oversized admin groups, reused local passwords, unconstrained delegation, weak certificate templates and a krbtgt password older than the domain functional level. This checklist is the run sheet for that review. It turns Microsoft's guidance for securing Active Directory into numbered checks across tiering, privileged groups, credentials, Kerberos and delegation, legacy protocols, AD CS, domain controllers, auditing and recovery, each with space for result and evidence. It is written for AD administrators, identity engineers and auditors. The risks behind each check are explained in the Top 10 Active Directory Security Risks; this page is the list you work through.
This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.
How to use this template
Replace every [placeholder] with your values. Run the checklist per forest; record each domain separately where results differ.
Mark each line Pass, Fail, Partial or Not applicable and attach evidence (PowerShell export, GPO report, screenshot, ticket reference). An attack path analysis tool output is strong evidence for sections 2 to 5; see the BloodHound and Active Directory Attack Path Guide.
Do not change production settings during the review. Record failures, then fix through change control, testing each change in audit mode first where the setting offers one.
Run the full list at least [annually] and after any compromise, merger or major AD change; run sections 3 and 9 [quarterly].
[Name], [date], [Pass / Pass with findings / Fail]
2. Administrative tiering and secure admin hosts
#
Check
Result and evidence
2.1
A documented tier model exists that places domain controllers, AD CS, identity synchronisation servers, PAM and backup systems for AD in the highest tier (Tier 0 or control plane). See the Tiered Administration and Enterprise Access Model Guide.
[ ]
2.2
Tier 0 accounts are separate from daily-use accounts and from accounts used on servers and workstations.
[ ]
2.3
Tier 0 administration happens only from secure administrative hosts that do not run email, web browsing or productivity software (Microsoft: never administer a trusted system from a less-trusted host). See the Privileged Access Workstations Guide.
[ ]
2.4
Group Policy denies Tier 0 accounts logon to lower tiers using Deny log on as a batch job, Deny log on as a service, Deny log on locally and Deny log on through Remote Desktop Services.
[ ]
2.5
Multifactor authentication is required for privileged accounts and administrative tasks.
[ ]
2.6
Tier 0 servers (including agents installed on domain controllers) are managed only by Tier 0 tooling; no lower-tier management agent or deployment system can run code on them.
[ ]
3. Privileged groups
#
Check
Result and evidence
3.1
Enterprise Admins and Schema Admins are empty except during approved changes; membership is added just in time and removed afterwards.
[ ]
3.2
Domain Admins and the built-in Administrators group contain only named Tier 0 admin accounts and the built-in Administrator; count recorded: [n].
[ ]
3.3
Account Operators, Backup Operators, Server Operators and Print Operators are empty or justified, since they carry high privilege on domain controllers.
[ ]
3.4
Membership of DnsAdmins, Group Policy Creator Owners, Key Admins, Enterprise Key Admins and Cert Publishers is reviewed and justified.
[ ]
3.5
No service account is a member of a Tier 0 group; any exception is documented with compensating controls.
[ ]
3.6
Nested group membership is expanded and reviewed: no unexpected groups or users inherit Tier 0 rights.
[ ]
3.7
The built-in Administrator account in each domain is secured per Microsoft guidance (account is sensitive and cannot be delegated, smart card required where feasible, logon restricted to domain controllers) and its use is alerted.
[ ]
3.8
Accounts protected by AdminSDHolder (adminCount=1) are reconciled against current group membership; stale entries are cleaned.
[ ]
3.9
Privileged user accounts are members of Protected Users after testing (members cannot use NTLM, DES or RC4 in Kerberos pre-authentication, or delegation, and TGTs are limited to 240 minutes).
[ ]
4. Accounts and credentials
#
Check
Result and evidence
4.1
Windows LAPS manages a unique local administrator password on every domain-joined workstation and member server, with password encryption enabled and read access restricted to the correct tier. Legacy Microsoft LAPS is deprecated and should be migrated. See the Windows LAPS Guide.
[ ]
4.2
Windows LAPS backs up the DSRM password of each domain controller to AD.
[ ]
4.3
The krbtgt password was last reset on [date]; it is reset on a regular schedule [interval] and twice after any suspected compromise, waiting at least the maximum ticket lifetime (10 hours by default) between resets. See the krbtgt account.
[ ]
4.4
Service accounts are inventoried with owner and purpose; where supported they are converted to group managed service accounts. See the Group Managed Service Accounts (gMSA) Guide.
No account has Do not require Kerberos preauthentication set, unless documented.
[ ]
4.7
No accounts have Password never expires, reversible encryption or Password not required set without documented exception.
[ ]
4.8
Enabled accounts with no logon in [90] days are disabled; disabled accounts are removed from privileged groups.
[ ]
4.9
Password policy and fine-grained password policies are documented; privileged accounts have stricter policies. Passwords are checked against known breached values where tooling allows.
[ ]
5. Kerberos and delegation
#
Check
Result and evidence
5.1
No computer or user other than domain controllers is trusted for unconstrained delegation.
[ ]
5.2
Constrained delegation entries are listed and justified; protocol transition (any authentication protocol) is used only where required.
[ ]
5.3
Resource-based constrained delegation settings (msDS-AllowedToActOnBehalfOfOtherIdentity) on Tier 0 objects are reviewed; no unexpected principals.
[ ]
5.4
RC4 use is measured from Kerberos ticket events and a plan exists to move all accounts to AES.
[ ]
5.5
Write permissions on Tier 0 objects, AdminSDHolder, the domain root and GPOs linked to domain controllers are limited to Tier 0 (including the replication rights that allow DCSync). See the Active Directory ACL and Delegation Hygiene Guide.
[ ]
5.6
ms-DS-MachineAccountQuota is set to 0 so ordinary users cannot join computers to the domain.
[ ]
6. Legacy protocols
#
Check
Result and evidence
6.1
Domain controller: LDAP server signing requirements is set to Require signing in the Default Domain Controller Policy, after reviewing events 2887 and 2889 for unsigned binds.
[ ]
6.2
Network security: LDAP client signing requirements is set to Require signing for clients.
The Print Spooler service is disabled on domain controllers where not required.
[ ]
7. Active Directory Certificate Services
#
Check
Result and evidence
7.1
CA servers are managed as Tier 0, and CA private keys are protected (HSM where possible).
[ ]
7.2
No published template allows the enrollee to supply the subject name while also allowing client authentication and enrolment by broad groups such as Domain Users or Authenticated Users.
[ ]
7.3
Enrolment and write permissions on templates and CA objects are limited; manager approval is used for sensitive templates; unused templates are unpublished.
[ ]
7.4
Domain controllers enforce strong certificate mapping (KB5014754). Microsoft states that Full Enforcement became the default with the 11 February 2025 update and that the compatibility option was no longer supported after the 9 September 2025 update; review KDC events 39, 40 and 41 for certificates without strong mapping.
[ ]
7.5
Web enrolment endpoints are disabled where unused, or require HTTPS with Extended Protection for Authentication. See the AD CS Security Guide.
[ ]
8. Domain controllers
#
Check
Result and evidence
8.1
Domain controllers run a supported operating system, are patched within [x] days and are physically secured (or protected by host and hypervisor controls when virtual).
No additional roles or software beyond those required run on domain controllers; no internet browsing from them.
[ ]
8.4
Outbound internet access from domain controllers is blocked except for required endpoints.
[ ]
8.5
Hypervisor and storage administrators for virtual domain controllers are treated as Tier 0.
[ ]
8.6
Read-only domain controllers in branch sites have a Password Replication Policy that excludes privileged accounts.
[ ]
9. Auditing and monitoring
#
Check
Result and evidence
9.1
Advanced Audit Policy on domain controllers enables success and failure auditing for Credential Validation, Kerberos Authentication Service and Kerberos Service Ticket Operations, as in Microsoft's stronger recommendation.
[ ]
9.2
Security group management, user account management, directory service changes and policy change auditing are enabled; logs are forwarded to the SIEM.
[ ]
9.3
Alerts exist for changes to Tier 0 group membership, AdminSDHolder, GPOs linked to domain controllers, and new delegation or SPN settings on privileged objects.
System state backups of at least two domain controllers per domain are taken [daily], are within the tombstone lifetime, and are stored offline or immutable.
[ ]
10.2
Backup systems and their admin accounts are treated as Tier 0.
DSRM passwords are known to the recovery team through a secure process (for example Windows LAPS backup) and tested.
[ ]
11. Findings and sign-off
Finding #
Check ref
Risk (High / Medium / Low)
Owner
Remediation and due date
[1]
[e.g. 5.1]
[High]
[Name]
[Action, date]
[2]
[ ]
[ ]
[ ]
[ ]
Approved by: [Name, role], [date]. Next review due: [date].
Implementation guidance
Start with exposure, not breadth: fix sections 3 (privileged groups), 4.1 (LAPS), 5.1 (unconstrained delegation) and 7.2 (vulnerable templates) first; they close the most common paths to domain admin.
Audit before enforcing: LDAP signing, channel binding, NTLM restrictions, SMB signing, Protected Users and strong certificate mapping can break legacy applications. Collect the audit events (for example 2887 and 2889 for LDAP, KDC events 39 to 41 for certificates), fix or exempt clients, then enforce in pilot sites before the whole estate.
Roll back cleanly: make each change through a dedicated GPO so it can be unlinked; for group membership changes keep the previous membership export.
Small versus large estates: a single-domain organisation can often complete the checklist in days and should still separate admin accounts and deploy LAPS; large multi-forest estates should run it per forest, automate checks with PowerShell or attack path tooling, and track Tier 0 membership as a continuous metric.
Measure: track the number of Tier 0 accounts, percentage of machines with LAPS-managed passwords, days since krbtgt reset, count of unconstrained delegation hosts, percentage of Kerberos tickets using RC4 and the number of open High findings.
Where identity fits
Service accounts are the most neglected part of most AD reviews: they often hold SPNs, old passwords and membership of privileged groups, and nobody owns them. Sections 3.5 and 4.4 to 4.7 apply equally to these non-human identities. See How to find service accounts with Domain Admin rights.
Common failure patterns
Same local admin password everywhere: Microsoft lists identical local privileged credentials across systems as a risky configuration; without LAPS, one compromised workstation opens all of them.
Admins on unsecured hosts: Tier 0 credentials used on everyday workstations are exposed to theft from memory.
Single krbtgt reset after compromise: because the account keeps a password history of two, one reset leaves the old key usable; Microsoft's procedure is two resets with a wait between.
Forgotten AD CS: certificate templates are outside the scope of group reviews, so a template misconfiguration grants domain admin equivalent access.
Enforcing protocol changes without audit: LDAP or NTLM enforcement breaks a line-of-business application and the change is reverted for years.
Framework mapping
Framework
Reference
Checklist sections
NIST CSF 2.0
PR.AA-01, PR.AA-05, PR.PS-01, DE.CM-03, PR.DS-11
4, 2 and 3, 6 to 8, 9, 10
NIST SP 800-53 Rev. 5
AC-2, AC-6, IA-5, CM-6, AU-2, CP-9
4, 2 and 3, 4, 6 to 8, 9, 10
CIS Controls v8.1
Control 5 Account Management; Control 6 Access Control Management; Control 4 Secure Configuration
3 and 4, 2 and 5, 6 to 8
MITRE ATT&CK v20
T1558.003 Kerberoasting, T1558.004 AS-REP Roasting, T1558.001 Golden Ticket, T1003.006 DCSync, T1649 Steal or Forge Authentication Certificates, T1550.002 Pass the Hash, T1484.001 Group Policy Modification
NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 8 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security.
nhimg.org
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.