It is important to note that the intended purpose of the lastLogontimeStamp attribute to help identify inactive computer and user accounts. The lastLogon attribute is not designed to provide real time logon information. With default settings in place the lastLogontimeStamp will be 9-14 days behind the current date.
The lastLogontimeStamp attribute is not updated with all logon types or at every logon. The good news is that the logon types that admins usually care about will update the attribute and often enough to accomplish its task of identifying inactive accounts.
Interactive, Network, and Service logons will update the lastLogontimeStamp. So if a user logs on interactively, browses a network share, access the email server, runs an LDAP query etc… the lastLogontimeStamp attribute will updated if the right condition is met.
Update and Replication of lastLogontimeStamp
First become acquainted with the ms-DS-Logon-Time-Sync-Interval attribute. It is an attribute of the domain NC and controls the granularity (in days) with which the lastLogontimeStamp attribute is updated. The default value is 14 and is set in code. Meaning that if you look at this attribute in ADSIEDIT.MSC and you see it as “Not Set” don’t be alarmed. This just means the system is using the default value of 14.
The lastLogontimeStamp attribute is not updated every time a user or computer logs on to the domain. The decision to update the value is based on the current date minus the value of the (ms-DS-Logon-Time-Sync-Interval attribute minus a random percentage of 5). If the result is equal to or greater than lastLogontimeStamp the attribute is updated. There are no special considerations for replication of lastLogontimeStamp. If the attribute is updated it is replicated like any other attribute update. This is not urgent replication
Walkthrough of a lastLogontimeStampUpdate update
- (Assuming the value of the ms-DS-Logon-Time-Sync-Intervalis at the default of 14)
- User logs on to the domain
- The lastLogontimeStampattribute value of the user is retrieved
- 14 – (Random percentage of 5) = X
- Current date – value of lastLogontimeStamp= Y
- X ≤ Y – update lastLognTimeStamp
- X > Y – do not update lastLogontimeStamp
Why the Randomization?
This randomization is done to prevent an update of the lastLogontimeStamp attribute from many accounts at the same time causing a high replication load on the DC’s. Remember the purpose of the lastLogontimeStamp attribute is locate inactive accounts not provide real-time logon information.
Controlling the update frequency of lastLogontimeStamp.
It is possible to change the frequency of updates to the lastLogonTime stamp or turn it off completely if desired. If you need a different time interval you will need to adjust the value of the msDS-LogonTimeSyncInterval attribute to a value between 5-100,000. Yes that’s right: the max value is 100,000 days… Or if you prefer ~280 years… And the max value was set in code not in the schema. (I guess the dev was counting on medical science to solve that pesky aging problem.)
In my experience the default settings can accommodate almost anyone and there is no need to change the update interval. Most customers I have talked to start considering accounts potentially inactive at the 30 day or higher mark of inactivity.
Note: If the msDS-LogonTimeSyncInterval is less than 5 days, the randomization is not put into effect.
Clearing up the confusion – Verifying that LastLogontimeStamp is in sync across all DCs in the domain.
Many times customers will be concerned about what their tools are displaying to them (usually a very old date) as the lastLogontimeStamp of a user compared to what they know to be a more accurate date. This is almost always due to the admin using a tool that queries the lastLogonattribute instead of the lastLogontimeStamp attribute.
For example acctinfo.dll that is included with the Account Lockout tools will display the lastLogon attribute data not the lastLogontimeStampdata. In some cases the date the tool reports may be months or years out of date or display nothing at all. This is because they are querying the lastLogon attribute and the user they are looking up has either never been authenticated by the reference DC (in the case of null) or has not been authenticated by the reference DC in a very long time.
How to tell if lastLogontimeStamp is in sync
To verify if the lastLogonTime stamp is being updated and replicated as expected you can use repadmin.exe with the showattr switch. Some examples are given below. These examples are intended to demonstrate that lastLogontimeStamp is being updated within the window of 9-14 days and replicated to all DC’s in the domain. They are not an example of how to manage stale accounts.
- Using repadmin to check the value of lastLogontimeStampon all DC’s in a domain for one user:
repadmin /showattr * (DN of the target user) /attrs:lastLogontimeStamp >lastLogontimeStamp.txt
repadmin /showattr * CN=user1,OU=accounting,DC=domain,dc=com /attrs:lastLogontimeStamp >lastLogontimeStamp.txt
- Using repadmin to dump the lastLogontimeStampfor all users in a domain including users that have no data in the lastLogontimeStampattribute:
repadmin /showattr * /subtree /filter:”(&(objectCategory=Person)(objectClass=user))” /attrs:lastLogontimeStamp >lastLogontimeStamp.txt
- Dump lastLogonTime stamp for users but only ones that have the attribute populated
repadmin /showattr * dc=domain,dc=com /subtree /filter:”((&(lastLogontimeStamp=*)(objectCategory=Person)(objectClass=user)))” /attrs:lastLogontimeStamp >lastLogontimeStamp-2-22-2009.txt