You may also know that the difference between LASTLOGONTIMESTAMP and LASTLOGIN is that the former is replicated across DCs and the latter is not. You might then ask, why Microsoft maintains the LASTLOGIN attribute since it seems inferior.
Well, what you might NOT know is that even with an interactive logon, the LASTLOGONTIMESTAMP field is not updated 'live'. The value is only updated if the current date is more than (14 - minus random % of 5) (in other words 9 - 14) days later that the current value of that field.
- Mick logs on February 1st for the first time in ages. LASTLOGONTIMESTAMP = February 1st
- (Mick goes on vacation)
- Mick logs on March 1st. LASTLOGONTIMESTAMP = March 1st because March 1st is more than 14 days past February 1st
- Mick logs on March 3rd. LASTLOGONTIMESTAMP = March 1st because March 3rd is not 14 days passed March 1st
- Mick continues to logon every day for the rest of his life, LASTLOGONTIMESTAMP is only updated on March 15th, March 29th, April 12th........ etc.
The *14* days is configurable, but reducing it beats the domain controllers up hard.
Thus if you use LASTLOGONTIMESTAMP then the value is going to sometimes be approximate, but (and here is the rub) if you want real-time accurate data you need to look at LASTLOGON on each domain controller and take most recent date you find. That is why that value is maintained.
This is especially important for legal or e-discovery reasons.
Post a Comment