Disabling dormant accounts automatically in Active Directory closes a common persistence vector attackers use and is a tangible control to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IA.L2-3.5.6; this post shows practical, repeatable steps to implement detection and automated disablement, including real-world examples for small businesses, scripts, scheduling, and operational safeguards.
Understanding the requirement and the risk of non-implementation
IA.L2-3.5.6 requires organizations to prevent inactive accounts from becoming long-term footholds for adversaries — an account that hasn’t been used for weeks or months can be exploited for lateral movement or data exfiltration. Failing to identify and remediate dormant accounts increases the risk of unauthorized access, extended dwell time for attackers, lost contracts or penalties for non-compliance, and reputational damage if a breach arises from unused credentials.
Implementation overview for Active Directory (on-prem)
Define dormancy thresholds and policy
Start by documenting an organizational policy: define what “dormant” means (e.g., no interactive logon in 60 or 90 days), which accounts are in scope (user, service, admin), and the remediation workflow (notification → disable → quarantine OU → deletion after retention period). Typical small-business practice is 90 days for standard users and 30–60 days for privileged accounts, but your policy must align with business risk and NIST/CMMC expectations.
Choose the right detection signal
For on-prem AD, use the lastLogonTimestamp attribute (replicated) for broad scans and lastLogon (per-DC) if you need per-DC precision. Note lastLogonTimestamp is updated only when logon is sufficiently old (default ~9–14 days), so it’s reliable for multi-week inactivity checks but not for last-hour accuracy. For hybrid environments, supplement with Azure AD/Entra Sign-in logs or conditional access reports.
Automated remediation — recommended PowerShell pattern
Automate with a scheduled PowerShell runbook on a management server with the ActiveDirectory module installed. Key technical points: run as a dedicated service account with delegated rights (Account Operators or explicit deny/allow), filter out service/admin accounts (use attributes like PasswordNeverExpires, Description tags, or membership in an “ExcludeFromDormancy” group), log every action to a central SIEM or CSV, generate a ticket/notification before final disable, and move disabled accounts to a quarantined OU.
# Example: disable users not logged on in last 90 days (run with AD module)
Import-Module ActiveDirectory
$threshold = (Get-Date).AddDays(-90)
$excludeGroups = @("Domain Admins","ServiceAccountsExclude")
$disabledOU = "OU=Disabled Users,DC=contoso,DC=com"
Get-ADUser -Filter * -Properties LastLogonTimeStamp,Enabled,PasswordNeverExpires |
Where-Object {
$_.Enabled -eq $true -and
-not $_.PasswordNeverExpires -and
($_.LastLogonTimeStamp -ne $null) -and
([DateTime]::FromFileTime($_.LastLogonTimeStamp) -lt $threshold)
} | ForEach-Object {
# skip excluded group members
if((Get-ADUser $_ -Properties memberOf).memberOf -notin $excludeGroups) {
# log action
"$((Get-Date).ToString('s')) DISABLING: $($_.SamAccountName)" | Out-File C:\Scripts\dormant-disable.log -Append
# disable and move to quarantine OU
Disable-ADAccount -Identity $_.DistinguishedName
Move-ADObject -Identity $_.DistinguishedName -TargetPath $disabledOU
# optionally add description and create ticket/alert
Set-ADUser -Identity $_.DistinguishedName -Description "Disabled by dormancy automation on $((Get-Date).ToString('yyyy-MM-dd'))"
}
}
Operational steps: scheduling, notifications, and audit
Run the automation as a scheduled task or Azure Automation runbook nightly or weekly depending on the threshold. Build a notification queue: pre-disable email to account owner and manager (e.g., 7-day notice), automatic ticket creation for each disablement, and a review step before permanent deletion (retain disabled accounts for your retention period, e.g., 30 days). Ensure every change writes to a central log and that AD audits are enabled (enable success/failure auditing for Account Management events) so your compliance evidence includes who/when/what.
Practical small-business scenarios and examples
Example A — Small engineering firm (50 users): implement a 90-day dormancy threshold. Use a group-based exclusion for shared service accounts and put highly privileged accounts in a separate OU to require manual review before disablement. Example B — Small MSP (100+ employees): integrate the script with the ticketing system (e.g., ServiceNow, Jira) using API calls so a ticket is automatically generated for each disabled account and a helpdesk tech verifies if the account belongs to a contractor or long-term absence before reinstating. These simple integrations prevent business disruption while satisfying auditors.
Compliance tips and best practices
Follow these best practices: maintain a documented policy that ties dormancy thresholds to business risk; exclude service and application accounts (then track and rotate their credentials regularly); use quarantined OUs and clear naming (prefix "DISABLED_"); keep an immutable audit trail (SIEM ingestion or append-only logs); periodically review exclusions and automation logic; and test the automation in a staging OU before production rollout. Additionally, combine this with MFA and conditional access to reduce risk from overlooked accounts.
In summary, implementing automatic disablement of dormant Active Directory accounts is a highly practical control to meet IA.L2-3.5.6: define clear policies, select appropriate logon attributes, automate detection and remediation with careful exclusions and notifications, log every action for audit, and integrate with operational processes. With modest scripting, scheduled automation, and a policy-driven approach, small businesses can significantly reduce account-based attack surface while producing the evidence needed for NIST SP 800-171 Rev.2 / CMMC 2.0 compliance.
