I'm currently auditing inactive Active Directory accounts, and I've run these audits successfully for years. However, in this new environment, I've noticed some discrepancies. In the most recent audit, there are accounts that I know should have been flagged as inactive, but they weren't. When I dug deeper, I found that the 'lastLogon' and 'lastLogonTimestamp' attributes for some accounts are not matching up as I expected. Specifically, the 'lastLogonTimestamp' appears to have a recent date, which I believe is inaccurate. I know for a fact that the older 'lastLogon' date is the true last active time for these users.
To try to fix the issue, I've created a PowerShell script that queries accounts where either the 'lastLogonTimestamp' or 'lastLogon' dates are greater than my target date. My main question is: why is the 'lastLogonTimestamp' being updated when the account isn't actually being used? I thought it only updated when there's a real login, but it seems to be reflecting dates that don't match actual activity. Any insights on what's happening here?
5 Answers
To really get an accurate picture, you should run your queries against all DCs and merge the results. This way, you can find the most recent logon across the board rather than relying on a single DC’s data. If you haven't already, consider using the 'msDS-LastSuccessfulInteractiveLogonTime' attribute too—it's often more reliable than the 'LastLogonTimestamp'.
Just a heads up, if you're seeing different timestamps, it might also indicate that something is logging in on behalf of that user. Make sure to check for any automated logins like scripts or services that might be impacting the timestamps.
It sounds like you're mixing up two important attributes: 'LastLogon' and 'LastLogonTimestamp'. The 'LastLogon' date is specific to each Domain Controller (DC), meaning it reflects the last time the user logged into that specific DC. On the other hand, 'LastLogonTimestamp' is replicated to other DCs, but it may lag behind by about two weeks. If you’re seeing outdated data, it could be that there’s some activity happening (like scheduled tasks) that impacts the timestamps but isn’t a direct login by the user.
Exactly! You might want to check if there are any services or automated processes using those accounts. It's common for things like SQL Server jobs to run under user accounts that can affect logon times.
Remember, the 'LastLogonTimestamp' isn't designed for real-time accuracy. It’s fine for identifying inactive accounts, but for pinpointing active user logon, you can't rely on it. It could be that your current setup gives those accounts a false sense of activity based on background tasks or old credentials still needing to be cleaned up.
If you need the most precise data for user activity, it really is a good idea to enumerate the last logon from all DCs and take the latest value. The PowerShell community has a bunch of scripts out there that can help with that, like the one below, which you might find handy! It calculates the true last logon for each user by checking all DCs.
Right? It's often the case with legitimate jobs that run under a user’s credentials, so double-check if those accounts might be part of a process that's not being tracked as an 'active' logon.