I've been auditing inactive Active Directory (AD) accounts for years, and usually, the data is reliable. However, after running the audit in a new environment, I've encountered some discrepancies. Specifically, there were accounts that I expected to be flagged as inactive that weren't reported. Upon further investigation, I found that the "lastLogonTimestamp" and "lastLogon" date attributes for some accounts differed significantly. The scripts I've been using pull from the "lastLogonTimestamp," which is showing a recent date that doesn't seem accurate. After verifying with users, it turns out that the older "lastLogon" dates are correct. I need help understanding why the "lastLogonTimestamp" is updating without the accounts actually being used, as I thought it only changes under certain circumstances. Can anyone shed some light on what's going on?
5 Answers
LastLogonTimestamp can be a bit tricky since it's not always reflective of actual usage, particularly for accounts that do not log in very frequently. For a more precise last login time, consider looking at the msDS-LastSuccessfulInteractiveLogonTime attribute, as it might provide better insights for your audits.
There’s a crucial difference between lastLogon and lastLogonTimestamp that might be messing with your results. While the lastLogon reflects the user's last authentication on a specific DC, the lastLogonTimestamp is only updated if the new value is more than 14 days fresh compared to the last version. It’s often the case that the more accurate data for inactivity audits is the lastLogonTimestamp, but it can be misleading if you're looking for real-time data on user activity since it won't change frequently. If you're tracking inactivity, use the lastLogonTimestamp, but if you need precision for account actions, look at lastLogon from each DC.
Exactly! Keeping an eye on both helps clarify what's really going on with user activity.
The reason your lastLogonTimestamp is behaving unexpectedly could stem from how these attributes work. LastLogon is specific to the Domain Controller (DC) you’re checking; it shows when the user last logged in to that DC. Meanwhile, lastLogonTimestamp replicates across DCs and can lag behind by up to two weeks. If you need a more accurate picture, check the lastLogon on all DCs and use the most recent entry. Additionally, it sounds like something might be logging in on behalf of those users, which could explain the recent timestamps. Not every logon type updates these attributes, especially with older systems like SQL Server, which can have scheduled jobs still running under a user’s account even when disabled.
If you’re noticing discrepancies, consider that changes in login behavior by applications or services could also trigger updates to the lastLogonTimestamp without actual user activity. For example, some scheduled tasks or services might authenticate under the user’s credentials, resulting in newer timestamps showing up. Investigating scheduled tasks or service accounts could provide more insight into unusual logon behavior.
Right? It’s crucial to look at all angles that could affect those timestamps.
Definitely check those services! Often it's the unnoticed background processes that mess with our logs.
I created a PowerShell script to analyze the real lastLogon more accurately, which might help you clarify the issue. It aggregates the lastLogon data from all DCs and gets the greatest timestamp, giving you the true last login time. Happy to share it if you're interested!
Good point! I trust the lastLogonTimestamp for identifying inactive accounts, but for real-time auditing, going DC by DC is the best approach.