“The LastLogonTimeStamp Attribute” – “What it was designed for and how it works”

  • Article

Warren here. In Windows Server 2003 we introduced the lastLogontimeStamp attribute. Administrators can use the lastLogontimeStamp attribute to determine if a user or computer account has recently logged onto the domain. Using this information administrators can then review the accounts identified and determine if they are still needed and take appropriate action.

Intended Use

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.

If you are looking for more “real-time” logon tracking you will need to query the Security Event log on your DC’s for the desired logon events i.e. 528 –Windows XP2003 and earlier or 4624 Windows Vista2008 . See this blog post by Eric Fitzgerald for more info. (I think he knows something about auditing)

IMO your best bet for near real-time data is to use an event log collection service to gather all domain controller security event logs to a centralized database. You can then query a single database for the desired logon events. Microsoft’s solution for security event log collection is Audit Collection Services. There are many 3rd party solutions as well.

How it worked in Windows 2000

Prior to Windows Server 2003 administrators had to query the lastLogon attribute to determine the most recent logon of user or computer account. This process was time consuming as the lastLogon attribute is updated only on the DC that validates the logon request. The lastLogon attribute is not replicated. So in the past to determine the most recent logon of a user or computer account the lastLogon attribute had to be queried on all domain controllers (at least in concept) and then the most recent date for lastLogon had to be determined from all the results returned. In Windows 2003 and higher lastLogon is still has the same behavior. It is updated only on the validating DC and is not replicated.

How it works in Windows Server 2003 and later

In contrast the lastLogontimeStamp attribute is replicated so all DC's have the same value for the attribute (after replication convergence). Therefore you can query a single DC to find all the users or all the computers that have not logged in within a certain time.

Requirements

Your Windows domain must be at Windows 2003 Domain Functional Level for updates to the llastLogontimeStamp to occur.

Logon types and that will trigger an update to the lastLogontimeStamp attribute.

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. (The conditions are discussed below in the section Update and Replication of lastLogontimeStamp.

As of Windows 2003 SP1 these logon types will NOT update lastLogontimeStamp

  • Certificate mapping through Microsoft Internet Information Services (IIS).
  • Microsoft .NET Passport mapping through IIS.

[Update June 19, 2009 - removed one item from the list above that is under debate in a repro currently. Will update when we have more word]  

====================================================

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

1. (Assuming the value of the ms-DS-Logon-Time-Sync-Interval is at the default of 14)

2. User logs on to the domain

3. The lastLogontimeStamp attribute value of the user is retrieved

4. 14 - (Random percentage of 5) = X

5. Current date - value of lastLogontimeStamp = Y

6. X ≤ Y - update lastLognTimeStamp

7. 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.

How do I turn this thing off?

If you want to disable the lastLogontimeStamp feature set the msDS-LogonTimeSyncInterval attribute to 0.

I personally have never spoken with anyone that really had a business need to change how often lastLogontimeStamp needs to be updated. Once it was explained how the update process works and it was proven that the attribute is current and replicated to all DC’s that was all that was needed. If really think you need a more recent timestamp than 9-14 days for inactive account detection I suggest you make small changes and monitor DC workloads. This is especially true in large environments.

=======================================

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 lastLogon attribute 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 lastLogontimeStamp data. 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.

1. Using repadmin to check the value of lastLogontimeStamp on all DC's in a domain for one user:

repadmin /showattr * (DN of the target user) /attrs:lastLogontimeStamp >lastLogontimeStamp.txt

Example:

repadmin /showattr * CN=user1,OU=accounting,DC=domain,dc=com /attrs:lastLogontimeStamp >lastLogontimeStamp.txt

2. Using repadmin to dump the lastLogontimeStamp for all users in a domain including users that have no data in the lastLogontimeStamp attribute:

repadmin /showattr * /subtree /filter:"(&(objectCategory=Person)(objectClass=user))" /attrs:lastLogontimeStamp >lastLogontimeStamp.txt

3. 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

- Warren ‘For Once not DFSR’ Williams

Comments

  • Anonymous
    April 16, 2009
    Great information Warren!! I definitely learned some new things here.   Thanks Mike

  • Anonymous
    April 16, 2009
    Outstanding article. The walkthrough was very useful. Thanks! Francis

  • Anonymous
    April 18, 2009
    The comment has been removed

  • Anonymous
    April 18, 2009
    Nice Detailed article... Warren ‘For Once not DFSR’ Williams

  • Anonymous
    April 20, 2009
    237 Microsoft Team blogs searched, 109 blogs have new articles in the past 7 days. 245 new articles found

  • Anonymous
    May 04, 2009
    The comment has been removed

  • Anonymous
    May 05, 2009
    Well.. in one sentence, all network logons update the timestamp and in another sentence IIS which uses network logon is not updating the timestamp ? Can you clarify? Also, it would be lot better to know, what kind of logon type is used by different application atleast for Microsoft applications Exchange (Outlook, OWA, RPC-o-HTTP), OCS etc.

  • Anonymous
    May 06, 2009
    KamleshAP, Greetings and thanks for the question. In the blog post I stated that Network and Interactive logons will update the  lastLogonTimeStamp. These are two of the Windows logon types that can be used. The full list is documented here: http://msdn.microsoft.com/en-us/library/aa394189.aspx. The 3 IIS tasks listed in the blog post do not log the targeted user on so the user account’s lastLogonTimeStamp would not be updated. In those cases the account used for the identity of the IIS application pool would perform a network logon (if necessary) and trigger an update to the attribute of the account used for the identity of the application pool if one is needed. Warren

  • Anonymous
    June 12, 2009
    Hello Warren, If these logons: Certificate mapping through Microsoft Internet Information Services (IIS). Username and password authentication through IIS. Microsoft .NET Passport mapping through IIS. do not update the lastlogontimestamp, what is the best method to detect stale accounts ? thanks, Prem

  • Anonymous
    June 19, 2009
    The comment has been removed

  • Anonymous
    June 19, 2009
    Prem, The best way to track stale accounts is to leverage the lastLogonTimeStamp attribute. It would be rare in a scenario that a. It is important to track stale accounts b. That the enterprise would only use authentication schemes that do not actually log the user account onto the domain. So far I personally have never found a customer scenario that the lastLogonTimeStamp was not updated as expected since Windows 2003 SP1 shipped. It’s possible they are out there but they are a very rare exception. Warren

  • Anonymous
    June 24, 2009
    Nice Article Warren,   Lots of great info. We have a request to determine the last login info. for users who only use Outlook Web Access. In limited testing in our lab, I don't see these logins reflected in the LastLogonTimeStamp Attribute. Thoughts/Help/Suggestions? Tom

  • Anonymous
    June 24, 2009
    clisbyt, Thanks for the feedback. I would have to do some testing which requires I go and talk to the Exchange guys. While I get that done I suggest the following: Make sure your lab domain is at 2003 Domain Functional Level. Create a brand new user and configure email attributes. Do not log this user on. Whne done confirm their lastLogonTimeStamp attribute is blank. Have them access their mail via OWA. Check their lastLogonTimeStamp attribute. I'll get back to you after I get the test done here. Warren

  • Anonymous
    June 24, 2009
    I actually got the test done faster than I thought. I tested Exchange 2003 and Exchange 2007. Test details 2003 Setup Exchange 2003 and IIS on one server and 2003 DC Single DC domain 2007 Setup Exchange 2007, IIS and DC all on separate servers. Single DC domain All OS’s were 2003 Steps Raised Domain Functional Level to 2003 Created new user Logged user into OWA Result In both cases lastLogonTimeStamp was updated. Warren

  • Anonymous
    June 26, 2009
    If I wanted to filter out all users who had not logged on in the past 60 days, how would I construct the query? Not sure how the timestamp is stored.

  • Anonymous
    June 26, 2009
    wdanielw, The time stamp is stored in UTC format. You will need to convert to local time if you need that human readable. There are tools already created that do the heavy lifting for you if you are interested. Joeware's oldcmp comes to mind and its free. A search for inactive accounts + "active directory" will give you a lot of examples of scripts and tools. Just be sure they use the lastLogonTimeStamp. Some of the examples I have seen use lastLogon. Warren

  • Anonymous
    June 29, 2009
    Warren - it seems to me that a simple LDAP bind is not updating lastLogon on the target DC. Whereas from the list of exceptions I expected that it would. What would you expect? (we are at Windows Server 2003 domain functional level). Thank you.

  • Anonymous
    June 29, 2009
    DaveK57, Your question is about the lastLogon attribute which has different update login than the lastLogonTimeStamp. A simple LDAP bind will not update the lastLogon attribute. It will however upstate the lastLogonTimeStamp attribute. Yet another reason to use the lastLogonTimeStamp attribute for tracking stale accounts over lastLogon. The KB below describes the behavior you are seeing. 939899 The lastLogon attribute is not updated when a client computer runs an LDAP simple bind operation against a Windows Server 2003-based domain controller http://support.microsoft.com/default.aspx?scid=kb;EN-US;939899 I just ran two simple tests:  I created two test users. I use new accounts to test lastLogonTimeStamp functionality as they always have the lastLogonTimeStamp attribute blank. This makes it certain lastLogonTimeStamp will always update at next logon. I then ran ldp.exe to perform a simple bind. (you can do this by clicking the advanced button on the credential prompt). One user I selected SSPI for the auth protocol and the other NTLM. In both cases the lastLogonTimeStamp was updated. However lastLogon is not updated. This is the expected behavior per the KB above. Warren

  • Anonymous
    June 30, 2009
    Warren, Thank you very much for the clear explanation and for doing the tests to prove it, I now understand. Strangely, if you do a simple LDAP bind attempt with an incorrect password then lastLogon does seem to be updated (as well as badPasswordTime). Not very important - just an added twist. As you say lastLogonTimestamp looks a much better attribuet to use. Dave.

  • Anonymous
    June 30, 2009
    Warren, The Walkthrough section looks like it has a typo:

  1. 14 - (Random percentage of 5) = X
  2. Current date - value of lastLogontimeStamp = Y
  3. X ≥ Y - update lastLognTimeStamp
  4. X < Y - do not update lastLogontimeStamp It looks like X & Y are transposed here. This conflicts with your proceeding paragraph describing the process, and implies only logons in close proximity to the current value of the attribute (<9-14 days apart) would cause a fresh replication of the attribute. Given how you have defined X and Y, lines six and seven should be flipped to read as follows:
  5. Y ≥ X - update lastLognTimeStamp
  6. Y < X - do not update lastLogontimeStamp That, or you could just move the "update" and "do not update" to their correct lines (all depends where the equal sign really belongs). Hope that helped clarify versus mudding things up further. This was a great post that helped me to better understand these attributes, thanks for the helpful info! Regards, Cameron

  • Anonymous
    July 14, 2009
    The comment has been removed

  • Anonymous
    November 02, 2010
    The comment has been removed

  • Anonymous
    November 02, 2010
    treyguinn, Network logons are performed by computers when rebooting, requesting or renewing Kerberos tickets, establishing connections to a DC or other computer in system context etc... I hope that helps. Warren

  • Anonymous
    December 03, 2010
    Great article!!!life saver!!! I searched inactive users in AD using the statement: $searcher.Filter = "(&(ObjectClass=User)(lastLogonTimeStamp<=" + $lastLogonTimeStampLimit + "))" And found the users as below: UserA: Michelle Pleasants [LastLogon: 02/02/2010 11:17:57] [LastLogonTimeStamp: 06/06/2010 09:00:38] UserB: Kayleigh Basey [LastLogon: 01/01/1601 00:00:00] [LastLogonTimeStamp: 09/24/2009 05:22:05] (I checked that ms-DS-Logon-Time-Sync-Interval is not set, which is 14 days by default) Q1: Why is the LastLogon empty or unavailable while LastLogonTimeStamp not? Does it mean that searcher.Filter only searches PDC for Lastlogon attribute and this user never logged in via PDC but other BDC? Q2: The LastLogon attribute is not 01/01/1601 but the LastLogonTimeStamp is 01/01/1601, It happans ONLY if the date when this uesr last logged on was within 14 days after its account been created. Is it ture? Sorry, I'm newbie in AD, thank you very much in advance.

  • Anonymous
    December 27, 2013
    Pingback from Active Directory – Get user last logon time being “tricky” | ITXSolutions - Infrastructure Solutions 4 Business

  • Anonymous
    April 13, 2014
    The comment has been removed

  • Anonymous
    May 19, 2014
    Pingback from LastLogonTimeStamp vs. msDS-LastSuccessfulInteractiveLogonTime - Active Directory FAQ

  • Anonymous
    May 28, 2014
    Pingback from ESwar KONeti's » SCCM Configmgr 2012 SSRS Dashboard Client Health Summary Report

  • Anonymous
    May 28, 2014
    Pingback from ESwar KONeti's » SCCM Configmgr 2012 SSRS Dashboard Client Health Summary Report

  • Anonymous
    May 28, 2014
    Pingback from ESwar KONeti's » SCCM Configmgr 2012 SSRS Dashboard Client Health Summary Report

  • Anonymous
    October 03, 2014
    Generate 'staleness' reports with the aid of PowerShell.

  • Anonymous
    November 14, 2014
    “The LastLogonTimeStamp Attribute” – “What it was designed for and how it works” - Ask the Directory Services Team - Site Home - TechNet Blogs

  • Anonymous
    November 20, 2014
    Using AD to determine whether or not people are still working for the company and are allowed to logon

  • Anonymous
    November 27, 2014
    Scripting tips for cleaning up stale Active Directory accounts.

  • Anonymous
    May 27, 2015
    The comment has been removed

  • Anonymous
    May 27, 2015
    The comment has been removed