How to Audit Active Directory User Accounts: A Complete Guide

Active Directory is the identity backbone of most enterprise environments, and like any system that accumulates years of organizational change, it gets messy over time. New accounts are created for every hire, every contractor, every service integration, and every project — but accounts are rarely removed with the same discipline they were created. Role changes happen without corresponding access updates. Service accounts get created with elevated permissions for a one-time project and then forgotten. Administrative accounts multiply as IT team members come and go. The result, in most organizations that haven't run a deliberate AD audit in the past year, is an identity environment riddled with stale accounts, over-permissioned users, orphaned service accounts, and security vulnerabilities sitting in plain sight.

Regular Active Directory user account audits are the primary mechanism for keeping this environment clean, secure, and compliant. They surface accounts that shouldn't exist, permissions that were never removed, and configurations that create risk. They produce the evidence that compliance frameworks require: documented proof that your organization knows who has access to what, has reviewed it deliberately, and has remediated what doesn't belong. Without regular audits, you're managing identity on the honor system — assuming the environment is clean because no one has explicitly told you it isn't.

This guide covers the full scope of an Active Directory user account audit: why it matters from both a security and compliance perspective, what to look for in each category of account, how to use PowerShell and native tools to surface findings efficiently, what to do with the results, and how to build auditing into a sustainable recurring practice rather than an exhausting one-time cleanup exercise.

Why AD Audits Are a Security and Compliance Imperative

Stale accounts — accounts that remain active after an employee has left, a contractor's engagement has ended, or a service has been decommissioned — are consistently ranked among the most exploited vulnerabilities in enterprise environments. From an attacker's perspective, a stale account is exactly what they're looking for: valid credentials attached to an identity that nobody is monitoring, with no user who would notice or report suspicious login activity. Attackers who obtain stale credentials through phishing, credential stuffing, or brute force can operate in your environment for months before detection, because the account's activity doesn't trigger the behavioral anomaly alerts that a known active user's unusual behavior would.

The compliance dimension is equally significant. SOC 2 Type II, ISO 27001, HIPAA, and SOX all have explicit or implied requirements for user access review. Auditors want evidence that access is actively managed — that accounts are disabled when employees leave, that permissions are reviewed on a documented cadence, and that privileged access is controlled and justified by business need. An organization that cannot produce current access review documentation has a compliance gap regardless of how strong its technical security controls may be in other areas.

The operational case is also compelling but often overlooked. Stale accounts consume software licenses unnecessarily. Over-permissioned service accounts create unnecessary blast radius when they're compromised. Undocumented admin accounts create shadow privilege paths that complicate change management and incident response. Cleaning up the AD environment through regular audits reduces attack surface, reduces licensing costs, and reduces the operational complexity that accumulates silently in every environment that isn't actively maintained.

Identifying and Remediating Inactive User Accounts

The most impactful and straightforward audit task is identifying accounts that haven't been used recently. In most environments, an account with no login activity in the past 90 days is a strong candidate for review — it likely belongs to an employee who left without proper offboarding, a contractor whose engagement ended without IT notification, or a user with a secondary account that was never needed. PowerShell makes this query straightforward: Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly returns all user accounts with no logon activity in the specified window. Export the results and cross-reference against current HR records to identify accounts that should have been disabled but weren't.

Before disabling inactive accounts in bulk, review the results carefully. Some inactive accounts have legitimate explanations: employees on extended leave, part-time staff who work infrequently, emergency or break-glass accounts that are intentionally maintained but rarely used. For each account with no matching current employee record, disable rather than immediately delete — this removes the security risk of active credentials while preserving the account for investigation if a business dependency surfaces. Maintain a 30-day hold period after disabling before deletion, which is typically sufficient to surface any legitimate dependencies without creating unacceptable ongoing risk.

Document every disabled and deleted account with a record of the action taken, who authorized it, and when. This documentation trail satisfies the audit evidence requirements of most compliance frameworks and provides a clear record if a question arises later about why a specific account was removed. Store this documentation in your ITSM or a dedicated compliance record system — not in a spreadsheet on someone's local drive.

Reviewing Privileged Account Membership

Privileged account review is the highest-stakes component of any AD audit. The groups that matter most — Domain Admins, Enterprise Admins, Schema Admins, Backup Operators, and local Administrators on critical servers — should have the smallest membership possible, with every member justified by a documented, current business need. In practice, these groups routinely contain accounts added for specific projects that were never removed, former IT staff who weren't fully offboarded from privileged groups, service accounts that were given domain admin rights because it was easier than determining minimal permissions, and generic accounts whose owners are long forgotten.

Export the current membership of every privileged group and review each account with the IT security team. For each account, three questions matter: Is this person or service currently employed or active? Does their current role genuinely require this level of privilege? Has this access been reviewed and recertified in the past 12 months? Any account that cannot be clearly answered "yes" to all three should be removed immediately. Privilege is not an entitlement to accumulate and keep indefinitely — it's access that should exist only as long as the business need exists.

Service accounts in privileged groups deserve special attention. Service accounts with Domain Admin rights are among the most dangerous configurations in an AD environment. They represent persistent, elevated privilege running continuously on systems throughout the network, often with non-expiring passwords unchanged for years. Remediating these requires identifying the minimum permissions each service account actually needs to function and reconfiguring accordingly — which may require coordination with application owners. The security improvement is significant enough to justify that coordination effort in virtually every case.

Auditing Password and Account Configuration Settings

Beyond account activity and group membership, a thorough AD audit reviews the configuration attributes of user accounts for policy violations and security risks. The most common finding is accounts configured with "Password Never Expires" — a setting that is occasionally legitimate for managed service accounts but should never apply to standard user accounts. User accounts exempt from password expiration are not subject to your organization's rotation policy, which is a direct compliance violation in most regulated environments and an unnecessary security risk in any environment.

Other configuration risks to look for include "Password Not Required" (accounts that can authenticate with a blank password), "Store Password Using Reversible Encryption" (stores passwords in a form that can be decrypted, essentially in cleartext), "Account is Trusted for Delegation" (allows the account to impersonate other users when accessing network services), and "Do Not Require Kerberos Pre-Authentication" (makes the account vulnerable to AS-REP Roasting attacks). Each of these settings represents a specific Active Directory attack vector and should be present only where there is a documented, current business justification.

Use PowerShell to query for each of these conditions across all user accounts in the domain. The Get-ADUser cmdlet with appropriate filters surfaces these findings quickly and consistently, regardless of how large your environment is. Compile the results into a finding report organized by risk level, and prioritize remediation accordingly — accounts with multiple risk settings are higher priority than accounts with a single low-risk misconfiguration.

Using PowerShell to Automate Audit Data Collection

Manual AD auditing — browsing through ADUC looking for problems — doesn't scale and doesn't produce the consistent, documented evidence that compliance requires. PowerShell is the right tool for systematic AD audit data collection. The Active Directory module for PowerShell, available on any system with the RSAT tools installed, provides cmdlets that can query every attribute of every account in the domain and export the results in formats suitable for review and documentation.

Build a reusable audit script that collects the findings that matter most: inactive accounts, privileged group membership, password configuration violations, accounts with non-standard delegation settings, and accounts without managers assigned. Run this script on a scheduled basis — monthly for the most critical findings, quarterly for the comprehensive audit — and save the output to a shared location where the IT security team and compliance stakeholders can review it. The existence of scheduled, documented audit runs with timestamped outputs is itself evidence of compliance with access review requirements.

For organizations with large or complex environments, dedicated AD auditing tools from vendors like Tenable, Semperis, or Netwrix provide deeper analysis, graphical reporting, and change tracking capabilities that go beyond what PowerShell scripts alone can provide. These tools are particularly valuable for detecting sophisticated misconfigurations — like nested group paths that grant unexpected privilege — that are difficult to surface through manual scripting.

Building a Sustainable Audit Cadence

A one-time AD audit is valuable but insufficient. Accounts accumulate and permissions drift continuously, so the findings from a single cleanup effort will begin to reaccumulate within months. The goal is a sustainable recurring audit practice — a regular cadence of focused reviews that keeps the AD environment continuously clean rather than allowing debt to build between infrequent major cleanups. A quarterly cadence works well for most organizations: inactive account and privileged group reviews each quarter, with a more comprehensive audit covering all account settings and configuration annually before major compliance reviews.

Connect the audit cadence to your offboarding and role change processes so that the quarterly audit serves as a safety net for exceptions rather than the primary cleanup mechanism. When offboarding is properly automated and role changes trigger access updates, the quarterly audit should surface relatively few issues — which is the target state. When it surfaces many issues, that's a signal that the upstream provisioning and deprovisioning processes need improvement, not just that the audit needs to run more frequently. A user access lifecycle audit shows where those joiner, mover, and leaver processes break down.

Conclusion

Active Directory user account auditing is one of the highest-return security practices available to IT teams. The investment is primarily time — PowerShell queries, human review, and remediation work — and the return is a dramatically cleaner security posture, more defensible compliance evidence, and a significantly reduced attack surface. Organizations that build regular AD auditing into their IT security program consistently discover and remediate risk that would otherwise remain hidden until an attacker found it first.

Build the practice, automate the data collection, and make it a standing item on the quarterly security calendar. Over time, as your offboarding and access management processes improve in response to what audits reveal, the findings will decrease and the effort required will shrink. That trajectory — from many findings to few, from reactive cleanup to proactive maintenance — is exactly what a mature identity security program looks like. If you haven’t audited before, start with a baseline audit to see where you stand.

How ezOnboard Keeps Your Active Directory Clean

ezOnboard prevents the account accumulation that makes AD audits painful by automating deprovisioning at the moment of departure. When an employee leaves, ezOnboard disables their AD account immediately as part of the offboarding workflow—eliminating the inactive accounts that audit tools flag as security risks. Combined with automated provisioning on hire, ezOnboard ensures your Active Directory accurately reflects your current workforce rather than every employee who has ever worked for you. Less cleanup in audits, less risk in between them.

Frequently Asked Questions

Why should organizations regularly audit Active Directory user accounts?

Active Directory grows over time in ways that don't always reflect the current state of your workforce. Accounts accumulate for departed employees, contractors, service accounts, and test accounts that were never cleaned up. Each inactive or orphaned account is a potential security liability—an entry point that could be exploited through credential stuffing, social engineering, or misconfiguration. Regular audits identify these accounts before they become incidents, ensure access aligns with current roles, and keep the directory clean enough to be manageable. Audits are also a standard requirement in most security frameworks, including SOC 2, ISO 27001, and NIST.

How do you find inactive accounts in Active Directory?

Active Directory stores the last logon timestamp for each user account, which provides a useful signal for identifying inactive accounts. PowerShell is the standard tool: the Search-ADAccount cmdlet with the -AccountInactive parameter lets you query for accounts with no logon activity in a defined number of days. Set a threshold appropriate for your environment—90 days is common, though some organizations use 60 or 30 for higher-security environments. Review results carefully before disabling, as service accounts and shared accounts may legitimately have long gaps between interactive logons.

What's the safest way to handle accounts identified for removal during an audit?

The standard safe approach is a three-stage process: disable the account first (not delete), wait 30 to 90 days to confirm there are no operational complaints, then delete. Disabling preserves all account attributes and group memberships while preventing logon—so if a service dependency or business need surfaces after the fact, the account can be re-enabled quickly. Immediate deletion is irreversible and occasionally causes disruption when an account was being used for something undocumented. For accounts tied to departed employees confirmed through HR records, the timeline can be compressed; for ambiguous accounts, err toward caution.

How do you handle service accounts during an Active Directory audit?

Service accounts are among the most overlooked and highest-risk accounts in any Active Directory environment. They often have elevated permissions, rarely change passwords, and don't follow the same lifecycle as user accounts. During an audit, identify all service accounts, verify that each is still associated with an active application or service, confirm that the password policy is appropriate (long, complex, managed through LAPS or a privileged access management tool), and ensure they're not being used for interactive logons. Document each service account's purpose, owner, and the system it supports—this documentation is invaluable when someone inherits administration of the environment.

What should an Active Directory audit report include?

A comprehensive AD audit report should cover: total account count broken down by active, disabled, and never-logged-in; accounts with last logon older than your defined threshold; accounts with password never expires set; accounts not requiring a password; privileged group memberships (Domain Admins, Schema Admins, Enterprise Admins); stale computer accounts; and any accounts with anomalous properties. The report should be reviewed by both IT security and management, and findings should be tracked to remediation with defined owners and timelines.