For sysadmins and IT managers auditing their own domain
How to Run an Active Directory Security Audit
Most Active Directory security audits are triggered by something external — an insurer, a new CISO, a penetration test report, a merger. The work itself is not mysterious, but it is broad, and doing it by hand means a fortnight of PowerShell followed by a spreadsheet nobody updates again until the next trigger arrives.
What makes this hard
- The scope is not obvious
- Accounts, groups, delegation, password policy, stale objects, trusts. Miss a category and the audit has a hole in it that nobody notices until someone else finds it.
- The data is scattered
- Different attributes, different domain controllers, different scripts, and a last-logon value that is only accurate if you check every DC.
- It goes stale immediately
- An audit is true on the day it was run. Two weeks of joiners, movers, and leavers later, the findings describe a directory that no longer exists.
- Findings are not the same as progress
- A list of 400 stale accounts is not an outcome. Being able to show that it was 400 last quarter and is 90 now is.
A workable order to do it in
Work outward from the accounts that can do the most damage. Each step below maps to a report SysFlint AD produces, so the audit becomes something you re-run rather than something you rebuild.
1. Start with privileged access
Enumerate Domain Admins, Enterprise Admins, Schema Admins, and the operator groups recursively. Every member should have a name you can attach to a person and a reason. Disabled or stale accounts holding privilege are the first thing to fix.
2. Find the accounts nobody is watching
Enabled accounts with no logon in 90 days are live credentials with no owner paying attention. Bucket them by age and by OU so cleanup can be delegated.
3. Check the password-policy exceptions
Non-expiring passwords, accounts flagged as not requiring a password, and passwords older than the policy that governs them. Privileged accounts in this list are the urgent ones.
4. Clear the sediment
Disabled accounts that were never removed, computer objects for machines that were decommissioned years ago. Low risk individually, but they are what makes every other report noisy.
5. Do it across the whole forest
A single-domain audit in a multi-domain forest is a partial audit. Cross-domain group membership is exactly where the surprises live.
6. Put it on a schedule
The point of the first audit is to produce a baseline. The value comes from the second one. Schedule the same reports monthly and the trend does the arguing for you.
What you end up with
- A defensible list of who holds privileged access, and why
- A dated baseline you can compare future runs against
- Findings grouped by OU, so remediation can be assigned rather than pooled
- Reports that regenerate themselves monthly instead of expiring the day after the audit
Frequently asked questions
- How long does a first audit take?
- The data collection is minutes. The work is in deciding what is acceptable in your environment — which service accounts are legitimately non-expiring, which dormant accounts are deliberate. That part is yours, but you only do it properly once if the reports keep running.
- Do I need Domain Admin rights to audit?
- No. A read-only domain account covers the core reports. An audit tool asking for Domain Admin should always prompt the question of why.
- Is this a replacement for a penetration test?
- No. This is directory hygiene and access review — the findings a pentest report will list under "Active Directory misconfiguration" that you can close before anyone charges you to find them.
Get SysFlint AD
Free, forever. No license keys, no per-user pricing, no seat counts, no trial timer.