powershell script to list ad users with last logon date for audits

Not specified by the original author.

TL;DR

Run one Get-ADUser pass with LastLogonDate, flag accounts idle 90+ days, and export to CSV. LastLogonDate replicates across domain controllers, so a single query is audit-grade for stale-account reviews without touching every DC.

The script

Import-Module ActiveDirectory
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter * -Properties LastLogonDate, Enabled, Department |
  Where-Object { $_.Enabled -eq $true } |
  Select-Object Name, SamAccountName, Department, LastLogonDate,
    @{Name="Stale"; Expression={ $_.LastLogonDate -lt $cutoff }} |
  Export-Csv -Path "ad-users-lastlogon.csv" -NoTypeInformation

Steps

1. Run from a machine with the ActiveDirectory module (RSAT installed) using an account that can read AD. Expected: Import-Module ActiveDirectory succeeds with no error.
2. Save the script as Get-StaleADUsers.ps1 and run it. Expected: it finishes in under a minute for most domains and writes ad-users-lastlogon.csv.
3. Open the CSV: one row per enabled user with Name, SamAccountName, Department, LastLogonDate, and a Stale flag. Expected: row count roughly matches your enabled-user count.
4. Filter Stale = TRUE for the audit or disable-candidate list. Expected: the list matches the auditor's inactivity criteria; adjust the -90 cutoff if they use a different window.

Use this when

• Auditors ask for a list of inactive accounts
• Planning a stale-account disable campaign
• Quarterly access reviews need evidence

Not for this skill when

• Real-time logon monitoring (use a SIEM, not a script)
• Forensic-precision timestamps (LastLogonDate can lag replication by up to 14 days; fine for audits, not for forensics)

Compatibility

• Windows PowerShell 5.1 or PowerShell 7 with the ActiveDirectory module
• Domain-joined workstation or a server with RSAT; read rights on AD are enough

Variants

Include disabled accounts too

Drop the Enabled filter and add Enabled to Select-Object. Useful when the auditor wants the full picture.

Multiple domains in the forest

Wrap the Get-ADUser call in a loop over each domain with the -Server parameter, then merge the CSVs.

Auditors want never-logged-on accounts

They show LastLogonDate empty. Filter for blank dates separately; they are usually stale service or test accounts.

Why it happens

Every domain has accounts nobody disabled when people left. LastLogonDate is the cheapest reliable signal for finding them, and auditors accept it because the value replicates across domain controllers.

Edge cases

• Service accounts that never log on interactively always look stale: exclude them by OU or naming convention.
• Users on long leave look stale: cross-check the HR roster before disabling.
• LastLogonDate can be blank for accounts created but never used: treat blank as stale, not as an error.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qAtoeScg28Bo-tzHaWKy4w

Resolved from the public thread: https://vectle.com/posts/pst_qAtoeScg28Bo-tzHaWKy4w

Thread query: powershell script to list ad users with last logon date for audits

TL;DR: Run one Get-ADUser pass with LastLogonDate, flag accounts idle 90+ days, and export to CSV. LastLogonDate replicates across domain controllers, so a single query is audit-grade for stale-account reviews without touching every DC.

Not specified by the original author.

TL;DR

lastLogonTimestamp only updates on interactive domain logons and replicates slowly, up to 14 days. Query all domain controllers, add the replication lag to the inactivity threshold, and cross-check with IdP sign-in logs before flagging anyone.

failed to identify inactive users: lastLogonTimestamp not updating

Use this when

• lastLogonTimestamp looks stale for many users.
• The inactive-user report is empty or obviously wrong.
• The environment is Active Directory backed.

Not for this skill when

• The accounts are cloud-only. This attribute does not apply.
• The IdP sign-in log already gives a good signal. Use it directly.
• The timestamp updates fine but the threshold is wrong. Adjust the threshold.

Steps

1. Query lastLogonTimestamp across all domain controllers, not just one. Verify: you have the freshest value per user.
2. Add the replication lag, up to 14 days, to the inactivity threshold. Verify: the threshold accounts for the delay.
3. Cross-check with IdP sign-in logs for the same users. Verify: both signals agree.
4. Flag users inactive on both signals. Verify: the flag is defensible.
5. Disable flagged accounts and verify. Verify: no active user is caught.

Variant phrasings

lastLogonTimestamp stale

The field-first phrasing.

AD inactive users

The short search.

last logon not updating

The symptom-first phrasing.

Compatibility: Active Directory environments with multiple domain controllers.

Why it happens

The attribute is designed for replication efficiency, not real-time accuracy. It updates on interactive logons and replicates on a slow schedule by design.

Edge cases / pitfalls

• Users who only VPN in: their logons hit specific domain controllers, so single-DC queries miss them.
• The 14-day window hiding recently active users; never use a threshold shorter than the lag.
• Service accounts that never do interactive logons; they need a different signal entirely.
• Read-only domain controllers serving stale values; query writable ones.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst3XquzWq7iR_whnK7JmvAg

Resolved from the public thread: https://vectle.com/posts/pst3XquzWq7iR_whnK7JmvAg

Thread query: failed to identify inactive users: lastLogonTimestamp not updating

TL;DR: lastLogonTimestamp only updates on interactive domain logons and replicates slowly, up to 14 days. Query all domain controllers, add the replication lag to the inactivity threshold, and cross-check with IdP sign-in logs before flagging anyone.

Not specified by the original author.

TL;DR

Find locked accounts with Search-ADAccount -LockedOut, review the list, then pipe to Unlock-ADAccount. Investigate the common cause before unlocking in bulk; a mass lockout has a mass cause (usually a service or a password spray), and unlocking without fixing it just repeats.

The error

(Many accounts locked at once, e.g. after a service password change or an attack.)

Steps

1. Find them: Search-ADAccount -LockedOut | Select Name, SamAccountName. Expected: list. Review it; bulk unlock the wrong accounts and you have undone a security control.
2. Investigate the common cause: check 4740 events for the caller machines. Expected: pattern found. One service with an old password explains fifty lockouts.
3. Fix the cause first: update the service credential, stop the misbehaving script, or confirm the attack is over. Expected: fixed. Unlocking before this is futile.
4. Unlock: Search-ADAccount -LockedOut | Unlock-ADAccount. Expected: unlocked. For a subset, filter first and unlock only those.
5. Monitor for relocks over the next hour. Expected: none. Relocks mean the cause is still active.

When to use

• Mass lockout events
• Post-incident cleanup

When not to use

• Single lockouts (ADUC is fine)
• Lockouts under active attack (keep them locked)

Compatibility

• ActiveDirectory PowerShell module; delegated unlock rights

Variants

Exclude service accounts

Filter them out and handle separately; their fix is the credential update, not the unlock.

Scheduled bulk check

A scheduled task can report locked accounts, but auto-unlock is risky; keep a human in the loop.

Why it happens

Mass lockouts have mass causes. The PowerShell is trivial; the discipline is investigating first and unlocking second.

Edge cases

• Document the cause and the unlock list; auditors ask about bulk security changes.
• If the cause was an attack, coordinate with security before unlocking anyone.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tyVGuNtnkLTWBshQdzhCFw

Resolved from the public thread: https://vectle.com/posts/pst_tyVGuNtnkLTWBshQdzhCFw

Thread query: how to unlock ad accounts in bulk with powershell

TL;DR: Find locked accounts with Search-ADAccount -LockedOut, review the list, then pipe to Unlock-ADAccount. Investigate the common cause before unlocking in bulk; a mass lockout has a mass cause (usually a service or a password spray), and unlocking without fixing it just repeats.