SysFlint AD
Stale and Inactive Account Detection
A disabled account is a housekeeping problem. An enabled account nobody has used in eight months is a security problem — it has a password, it has group memberships, and nobody is watching it. Stale accounts are one of the most reliable footholds in a domain compromise precisely because their owners are not around to notice anything odd.
How this is normally done
The usual approach filters on LastLogonDate, which is close enough for a rough pass:
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter { Enabled -eq $true -and LastLogonDate -lt $cutoff } `
-Properties LastLogonDate, PasswordLastSet, DistinguishedName |
Select-Object Name, SamAccountName, LastLogonDate, PasswordLastSet |
Sort-Object LastLogonDateWhere it stops being enough
- LastLogonDate is replicated on a delay of up to ~14 days — accounts near the boundary land on the wrong side of it.
- Accounts that have never logged on have a null value and silently fall out of the filter entirely.
- Service accounts and break-glass accounts look identical to abandoned ones without an exclusion list you maintain by hand.
- There is no trend: you cannot tell whether stale accounts are being cleaned up faster than they appear.
What SysFlint AD does instead
Accurate inactivity, sensible defaults, and a definition of "stale" you set once instead of re-deriving in every script.
- Queries every domain controller for the real last-logon value rather than trusting the replicated one.
- Catches never-logged-on accounts instead of dropping them out of the filter.
- Configurable thresholds — 30, 60, 90 days, or your own — with accounts bucketed by age.
- Exclusion lists for service and break-glass accounts, so the report stays signal, not noise.
- Run-over-run history that shows whether the backlog is shrinking.
What's in the report
- Enabled accounts bucketed by days since last logon
- Accounts that have never been used since creation
- Password age alongside logon age — a stale account with an ancient password is the worst case
- Group memberships carried by each stale account
- OU breakdown so cleanup can be assigned to the right owner
Frequently asked questions
- What counts as a stale account?
- You choose. The default view uses 90 days without a logon on an enabled account, and accounts are also bucketed at 30 and 60 days so you can see the problem forming rather than just the backlog.
- How do you handle service accounts?
- They are excludable, individually or by OU or naming pattern, so a deliberately dormant service account does not sit at the top of every report forever.
- Is this the same as a disabled account report?
- No, and the difference matters. Disabled accounts cannot authenticate. Stale accounts are enabled, can authenticate, and nobody is watching them. See the disabled account reports page for the other half.
Related features
Related use cases
Get SysFlint AD
Free, forever. No license keys, no per-user pricing, no seat counts, no trial timer.