How to Build an Active Directory Security Review Checklist

Define what to check, collect reliable evidence and turn Active Directory security findings into owned actions.

Introduction

An Active Directory security review can produce plenty of information without establishing whether the environment is well controlled. A list of administrators, a password-policy export and a successful backup job are useful evidence, but none is a complete security assessment.

A worthwhile checklist connects each security question to a defined scope, a test, an expected result and an accountable owner. It should reveal where controls are effective, where they need improvement and where the organisation simply does not have enough evidence to decide.

This guide explains how to build that checklist and use it consistently. It includes a starting set of review areas and PowerShell examples for collecting evidence. It is designed to organise a review, not replace a detailed hardening baseline, penetration test or incident investigation. Use the linked guides for deeper procedures.

1. Define the Scope Before Running Checks

Record the forests and domains being reviewed, the business services they support and the people responsible for them. Include domain controllers, administrative workstations and systems that can manage, synchronise, back up or restore identity infrastructure.

Agree the following before collection begins:

• Coverage: domains, organisational units, sites, identity services and connected management platforms.
• Population: employees, contractors, administrators, service identities, computers and emergency-access accounts.
• Review period: the snapshot date and the period covered by activity logs and operational evidence.
• Baseline: the approved security requirements and version against which results will be assessed.
• Boundaries: exclusions, inaccessible systems and separately owned services, with reasons and owners.
• Authority: who may collect data, approve tests, accept risk and authorise remediation.

Do not quietly exclude a disconnected domain or an undocumented service because it is difficult to query. Record it as a coverage gap. A review of one domain must not be described as a forest-wide assessment.

2. Give Every Checklist Item a Testable Outcome

“Check privileged accounts” is a topic, not a test. A stronger item is: “Every effective member of the groups in scope has an identified owner, current justification and an approved administrative purpose.”

For each check, record:

• A stable check ID, control objective and affected scope.
• The evidence source, collection method and collection date.
• Pass criteria agreed before reviewing the results.
• The finding, affected object identifiers and supporting evidence reference.
• The result, risk priority, remediation owner and target date.
• Any approved exception, compensating control and expiry date.
• The retest date and evidence supporting closure.

Use Pass, Fail, Not tested and Not applicable. A pass requires sufficient evidence across the stated scope. Not applicable requires a reason; not tested remains an unresolved coverage gap. Record risk acceptance separately: accepting a failed control does not make the control pass.

3. Start with This Active Directory Security Review Checklist

Use these control areas as a starting point. Split them into individual tests for each domain or system, and replace broad criteria with the measurable requirements in your approved baseline.

4. Prepare a Controlled Evidence Collection Session

The directory examples below use the Active Directory module on a secured Windows administrative workstation. The GPO example additionally requires the GroupPolicy module. Use an authorised account with the necessary read permissions, not Domain Admin merely for convenience. Run the setup once per target domain in the same PowerShell session.

Import-Module ActiveDirectory -ErrorAction Stop

# Replace with an approved, reachable DC in the domain being reviewed.
$ReviewServer = 'demo.local'
$ReviewDomain = Get-ADDomain -Server $ReviewServer -ErrorAction Stop
$ReviewForest = Get-ADForest -Server $ReviewServer -ErrorAction Stop

# Use an existing, access-controlled evidence folder.
$EvidenceRoot = 'C:\AD-Review'
if (-not (Test-Path -LiteralPath $EvidenceRoot -PathType Container)) {
    Write-Host "[-] Error: Evidence folder '$EvidenceRoot' does not exist." -ForegroundColor Red
    Write-Host "    Please create and secure the folder before running collection." -ForegroundColor Yellow
    return
}

$RunName = '{0}-{1}-{2}' -f $ReviewDomain.DNSRoot,
    (Get-Date).ToUniversalTime().ToString('yyyyMMddTHHmmssZ'),
    ([guid]::NewGuid().ToString('N').Substring(0, 8))
$ReviewPath = Join-Path $EvidenceRoot $RunName
New-Item -Path $ReviewPath -ItemType Directory -ErrorAction Stop | Out-Null

[PSCustomObject]@{
    CollectedAtUtc = (Get-Date).ToUniversalTime().ToString('o')
    Forest         = $ReviewForest.Name
    Domain         = $ReviewDomain.DNSRoot
    QueryServer    = $ReviewServer
    Collector      = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
    Computer       = $env:COMPUTERNAME
} | Export-Csv (Join-Path $ReviewPath 'Collection-Context.csv') -NoTypeInformation -Encoding UTF8

Write-Host "[+] Collection context saved to: $ReviewPath" -ForegroundColor Green

Establish the Directory Inventory

Collect the forest context and domain-controller inventory. Compare the result with your infrastructure records, including offline or unreachable systems. A domain controller's advertised OS version does not establish its patch compliance.

$ReviewForest | Select-Object Name, ForestMode,
    @{Name='Domains'; Expression={ $_.Domains -join '; ' }} |
    Export-Csv (Join-Path $ReviewPath 'Forest.csv') -NoTypeInformation -Encoding UTF8

$DomainControllers = @(Get-ADDomainController -Filter * -Server $ReviewServer -ErrorAction Stop)
if ($DomainControllers.Count -eq 0) {
    throw 'No domain controllers returned. Verify the query scope and access.'
}

$DomainControllers |
    Select-Object HostName, Domain, Site, IPv4Address,
        OperatingSystem, OperatingSystemVersion, IsReadOnly, IsGlobalCatalog |
    Export-Csv (Join-Path $ReviewPath 'Domain-Controllers.csv') -NoTypeInformation -Encoding UTF8

The forest report lists domains; the DC query collects only the selected domain. Repeat the domain-level checks for every domain in scope. Record query failures as missing coverage rather than omitting them from the review.

5. Review Account Hygiene and Effective Privilege

Identify Accounts That Need Investigation

Collect enabled users with account-risk indicators and apparent inactivity. The following example uses 90 days as a review threshold, not a deletion rule, and includes accounts with no replicated logon timestamp.

$InactiveBefore = (Get-Date).AddDays(-90)
$UserQuery = @{
    Server      = $ReviewServer
    SearchBase  = $ReviewDomain.DistinguishedName
    Filter      = 'Enabled -eq $true'
    Properties  = @('LastLogonDate', 'whenCreated', 'PasswordLastSet',
        'PasswordNeverExpires', 'PasswordNotRequired', 'DoesNotRequirePreAuth')
    ErrorAction = 'Stop'
}
$EnabledUsers = @(Get-ADUser @UserQuery)

$EnabledUsers | Where-Object {
    $null -eq $_.LastLogonDate -or $_.LastLogonDate -lt $InactiveBefore -or
    $_.PasswordNeverExpires -or $_.PasswordNotRequired -or $_.DoesNotRequirePreAuth
} | Select-Object SamAccountName, SID, DistinguishedName, whenCreated,
    LastLogonDate, PasswordLastSet, PasswordNeverExpires,
    PasswordNotRequired, DoesNotRequirePreAuth |
    Export-Csv (Join-Path $ReviewPath 'Accounts-To-Review.csv') -NoTypeInformation -Encoding UTF8

[PSCustomObject]@{
    SearchBase       = $UserQuery.SearchBase
    EnabledUserCount = $EnabledUsers.Count
    InactiveBefore   = $InactiveBefore.ToString('o')
} | Export-Csv (Join-Path $ReviewPath 'User-Query-Scope.csv') -NoTypeInformation -Encoding UTF8

LastLogonDate is derived from replicated lastLogonTimestamp, which is not updated at every logon. A blank value does not prove an account has never been used. Compare creation dates, domain-controller evidence and dependent application activity before deciding an identity is obsolete. See our guide to finding stale accounts in Active Directory and Microsoft's timestamp documentation.

Likewise, PasswordNotRequired does not prove the current password is blank. Non-expiring passwords need assessment against the identity type and credential policy; they are not automatically evidence of compromise. This query excludes disabled users, computers and managed service accounts, which need separate review populations.

Checklist outcome: every flagged identity has a documented decision, and account lifecycle evidence has been checked against the people or services that own it.

Look Beyond the Domain Admins List

Use a stable SID to identify Domain Admins in the selected domain and collect direct and recursive memberships separately:

$DomainAdminsSid = '{0}-512' -f $ReviewDomain.DomainSID.Value
$GroupQuery = @{
    Identity    = $DomainAdminsSid
    Server      = $ReviewServer
    ErrorAction = 'Stop'
}

Get-ADGroupMember @GroupQuery |
    Select-Object Name, SamAccountName, ObjectClass, SID, DistinguishedName |
    Export-Csv (Join-Path $ReviewPath 'Domain-Admins-Direct.csv') -NoTypeInformation -Encoding UTF8

Get-ADGroupMember @GroupQuery -Recursive |
    Select-Object Name, SamAccountName, ObjectClass, SID, DistinguishedName |
    Export-Csv (Join-Path $ReviewPath 'Domain-Admins-Recursive.csv') -NoTypeInformation -Encoding UTF8

This is a starting check, not a complete privilege inventory. Recursive output does not retain every nesting path; cross-domain and foreign-principal resolution may require additional handling. Include the other built-in and custom privileged groups, delegation over sensitive objects, replication permissions and control of identity-management infrastructure.

Checklist outcome: effective privilege is mapped to a current purpose and owner, including principals that can grant themselves or others greater access. Use How to Identify Privileged Accounts in Active Directory for discovery and How to Review Privileged Group Membership in Active Directory for certification.

6. Review Passwords, Authentication and Service Identities

A domain password-policy export does not establish which policy applies to every user. Collect the default policy and fine-grained password policies, then check the resultant policy for representative users in each important account population.

$PolicyFields = @('Name', 'MinPasswordLength', 'ComplexityEnabled',
    'PasswordHistoryCount', 'MinPasswordAge', 'MaxPasswordAge',
    'LockoutThreshold', 'LockoutDuration', 'LockoutObservationWindow',
    'ReversibleEncryptionEnabled')

# 1. Export Default Domain Password Policy
try {
    $DefaultPolicy = Get-ADDefaultDomainPasswordPolicy -Identity $ReviewDomain.DNSRoot -Server $ReviewServer -ErrorAction Stop
    $DefaultPolicy | Select-Object -Property $PolicyFields |
        Export-Csv (Join-Path $ReviewPath 'Default-Password-Policy.csv') -NoTypeInformation -Encoding UTF8
    Write-Host "[+] Exported default domain password policy." -ForegroundColor Green
} catch {
    Write-Host "[-] Error retrieving default password policy: $_" -ForegroundColor Red
    return
}

# 2. Export Fine-Grained Password Policies (FGPPs)
try {
    $FGPPs = Get-ADFineGrainedPasswordPolicy -Filter * -Server $ReviewServer -ErrorAction Stop
    $FGPPs | Select-Object -Property ($PolicyFields + @('Precedence',
            @{Name='AppliesTo'; Expression={ $_.AppliesTo -join '; ' }})) |
        Export-Csv (Join-Path $ReviewPath 'Fine-Grained-Policies.csv') -NoTypeInformation -Encoding UTF8
    Write-Host "[+] Exported $($FGPPs.Count) fine-grained password policy/policies." -ForegroundColor Green
} catch {
    Write-Host "[-] Warning: Could not retrieve fine-grained password policies: $_" -ForegroundColor Yellow
}

# 3. Prompt for Username and Resolve Resultant Password Policy
$SampleUser = Read-Host -Prompt "Enter username to check Resultant Password Policy (e.g. joe.bloggs)"

if ([string]::IsNullOrWhiteSpace($SampleUser)) {
    Write-Host "[-] No username provided. Skipping resultant policy lookup." -ForegroundColor Yellow
} else {
    try {
        $ResultantPolicy = Get-ADUserResultantPasswordPolicy -Identity $SampleUser -Server $ReviewServer -ErrorAction Stop
        
        if ($null -eq $ResultantPolicy) {
            Write-Host "[!] User '$SampleUser' has no FGPP applied. Falling back to default domain policy." -ForegroundColor Yellow
            $ResultantPolicy = $DefaultPolicy
        }

        $ResultantPolicy | Select-Object -Property $PolicyFields |
            Export-Csv (Join-Path $ReviewPath "Resultant-Policy-$SampleUser.csv") -NoTypeInformation -Encoding UTF8

        Write-Host "[+] Resultant password policy for '$SampleUser' exported successfully." -ForegroundColor Green
    } catch {
        Write-Host "[-] Error retrieving resultant policy for user '$SampleUser': $_" -ForegroundColor Red
    }
}

A successful resultant-policy query with no returned fine-grained policy means the default domain password policy applies. A failed query must not be treated as that fallback. Microsoft's resultant password policy documentation explains this distinction. Retain each sample identity alongside the observed policy in the review record.

Authentication requires separate evidence. List the actual sign-in paths, including remote access, administrator connections, cloud sign-in and application authentication. Check which controls apply to each. Enabling MFA for Microsoft 365 does not establish MFA protection for every on-premises AD authentication path.

For service identities, record the application, owner, hosts, effective rights and credential-management method. Assess group managed service accounts where supported, including who can retrieve their managed passwords. For local administrator accounts, check Windows LAPS deployment, successful rotation and authorised password retrieval; a configured policy alone is insufficient.

Checklist outcome: policies are effective for the intended populations, authentication gaps are recorded and service and local credentials have accountable management. Assess legacy protocol dependencies and LDAP protections against the versions deployed; do not enforce protocol changes without compatibility testing.

7. Review Delegation, Policies and Administrative Infrastructure

Check who can change sensitive OUs, groups and GPOs, not simply who owns them. Review password-reset rights, group-membership changes, ownership and ACL modification. For GPOs, consider editing rights, links, filtering and permissions on referenced scripts or deployment files. Permission to create an unlinked GPO alone does not establish control of target computers.

Collect a GPO report from the selected domain:

Import-Module GroupPolicy -ErrorAction Stop
$GpoReport = @{
    All         = $true
    Domain      = $ReviewDomain.DNSRoot
    Server      = $ReviewServer
    ReportType  = 'Html'
    Path        = Join-Path $ReviewPath 'Group-Policy-Report.html'
    ErrorAction = 'Stop'
}
Get-GPOReport @GpoReport

Get-GPOReport reports configured settings, links, filtering and delegation. It does not prove successful application on every target. Supplement it with resultant-policy evidence and observed settings from the systems being assessed.

For domain controllers and administrative infrastructure, obtain evidence of patching, endpoint protection, hardening, replication health, DNS and time synchronisation. Review host, backup and management-console administrators as well as AD administrators. Microsoft's Enterprise Access Model extends the older AD tier model to modern access paths; the checklist should cover the systems that control identity, not rely on a tier label alone.

Where AD Certificate Services is present, include certificate authorities, published templates, enrolment rights and authentication-related configuration. Microsoft's certificate security assessments describe relevant misconfiguration risks. For hybrid identity, assess synchronisation or federation infrastructure and the permissions used to administer it. Record absent services as not applicable, with evidence, rather than leaving the questions unanswered.

Checklist outcome: the organisation understands who can alter identity infrastructure and has verified that important configuration controls apply on the intended systems.

8. Verify Auditing and Response, Not Just Logging Settings

Separate four questions: is auditing enabled, are relevant events generated, do they reach the collection platform, and does someone act on them? Keep evidence for each stage. Run this example locally on each authorised target DC through your approved administrative process; it does not use the earlier remote-server variable.

# Read the effective audit policy on THIS computer.
auditpol.exe /get /category:*
if ($LASTEXITCODE -ne 0) {
    throw 'Audit policy collection failed; record this check as not tested.'
}

Get-WinEvent -ListLog Security -ErrorAction Stop |
    Select-Object LogName, IsEnabled, RecordCount, MaximumSizeInBytes, LogMode

Get-WinEvent -LogName Security -Oldest -MaxEvents 1 -ErrorAction Stop |
    Select-Object MachineName, TimeCreated, Id

Reading Security-log configuration and events requires appropriate permissions. Retain the host identity and output in the evidence record. The oldest available local event indicates the current local history, not guaranteed retention or central collection coverage.

Include security-group management, account management and relevant directory-change auditing. Directory-change events such as 5136 depend on the necessary policy and matching SACL coverage. After approval, make a reversible test change to a designated test object covered by the intended auditing, verify collection and alert routing, then reverse it. The script above does not perform this test.

Checklist outcome: monitoring has demonstrated coverage and a response owner, with gaps documented. Use our AD change-auditing guide and Microsoft's Advanced Audit Policy guidance for detailed configuration.

9. Include Recovery as a Security Control

A successful backup job is only one checkpoint. Record which domains and identity dependencies are protected, how backup access is restricted, and whether recovery remains possible if production identity services or administrator credentials are unavailable.

Require evidence of an isolated recovery exercise, accountable recovery owners and agreed recovery-time and recovery-point objectives. Include access to the runbook, recovery credentials, DNS and other dependencies without storing their secrets in the review itself.

AD Recycle Bin, replication and virtual-machine snapshots are not substitutes for a tested forest-recovery plan. Validate the supported recovery method and the practical sequence using Microsoft's Active Directory Forest Recovery Guide.

Checklist outcome: the organisation can demonstrate a protected, tested recovery capability rather than merely report that backups exist.

10. Turn Findings into Prioritised Actions

Assess findings by the control they expose, the access needed to exploit them, the affected systems and the likely business impact. An unexplained route to identity control deserves more attention than a missing group description. Do not average a critical failure away inside a high overall checklist score.

For example, a finding could record:

• Check: AD-03, effective privileged-group membership.
• Evidence: an enabled former support account remains a nested member of a server administration group.
• Validation: the owner confirms its support role ended; dependent services still need checking.
• Action: review dependencies, approve removal of the unnecessary access and verify all membership paths afterwards.
• Closure: updated effective-access evidence and confirmation that the affected service still operates.

Assign one remediation owner and an agreed deadline to each finding. Preserve the pre-change state, approval and rollback route. Risk exceptions need an approver, compensating controls and expiry; overdue exceptions should return to the review queue. If evidence suggests active compromise, invoke incident response instead of treating it as routine housekeeping.

11. Make the Review Repeatable

Keep the checklist definition separate from each completed review. Version the control set, retain the scope and collection context, and compare results using stable identifiers such as SIDs and object GUIDs. Record collection failures alongside successful exports.

A practical starting cadence is continuous monitoring of sensitive changes, monthly attention to account hygiene and overdue actions, and a quarterly broader review. Adjust this to your risk, change rate and obligations. Repeat relevant checks after acquisitions, major identity changes, incidents or new administrative integrations; schedule recovery exercises explicitly.

Before signing off a review, confirm that:

• All agreed domains and systems are covered or identified as gaps.
• Each result has current evidence and a clear rationale.
• Sampling limits and untested areas are visible.
• Failed controls have owners, deadlines or approved time-bound exceptions.
• Remediated findings have been retested.
• The next review and responsible person are recorded.

Common Checklist Mistakes

Treating a Script as the Assessment

Scripts can collect configuration; they cannot establish business need, validate every operational dependency or certify a recovery capability. Pair technical output with owner review and controlled testing.

Marking Configuration as Proof of Enforcement

A linked GPO, configured alert or installed credential-management component is evidence of intent. Verify application, collection and behaviour on the target systems.

Applying Automatic Fixes to Every Flag

Flags require interpretation. Removing group membership, disabling an inactive account or changing authentication requirements without dependency checks can disrupt production services.

Claiming Compliance from a Generic Checklist

This guide provides a review framework, not certification against a regulation or standard. If formal compliance is required, map the individual tests to the applicable requirements and retain the supporting evidence.

Where Automation and Specialist Platforms Help

Active Directory reporting can make evidence collection more consistent, while access governance and permissions management supports accountable access decisions. Treat Active Directory backup and recovery as a separate capability to validate, not something an auditing tool supplies by implication.

Netwrix Auditor can support directory change auditing and investigation. Adaxes can support controlled delegation and repeatable identity administration. Neither should be presented as a complete security review or as proof that every control in this checklist is effective; Adaxes operation history is also not a substitute for independent auditing of changes made outside the platform.

Begin with the evidence or control gap, then evaluate the appropriate tooling. Armstrong can help scope the review and assess which capabilities are needed. Our guide to securing Active Directory against privilege escalation provides a practical next step when the review identifies excessive access or exposed administrative paths.

Final Thoughts

A useful Active Directory security review checklist is a set of questions the organisation can answer with evidence. It defines what is in scope, what satisfactory control looks like, which tests were completed and who is responsible for unresolved findings.

Start with a manageable baseline, retain uncertainty where evidence is missing and close findings only after verification. That turns a periodic collection of reports into a repeatable process for reducing identity risk.