lastLogon vs lastLogonTimestamp

As I can see frequently in questions on forums, people ask about possibility to check the last date when user logged on into a domain. They very often try to get that information basing on lastLogon attribute. When other person tells that this should be checked using lastLogonTimestamp instead of lastLogon attribute, they are surprised and ask why this atribute is not the proper one.

I will try to explain in this short article difference between these 2 LDAP attributes.

If you want to determine when user was logged on within domain for the last time, you need to run appropriate query to get that information. You can use one of two attributes to see the time of last successful logon:

lastLogon

lastLogonTimeStamp

the most simple difference between them is that lastLogon attribute stores information about last successful user logon only on that particular Domain Controller and it is NOT replicated to other Domain Controllers.

So, if you want to simply know when user was authenticated for the last time by this particular DC, you can use this attribute.

In other case when you are interested in the date of the last successful logon in a domain for a user, you need to use lastLogonTimestamp attribute. The small inconvenience of using the attribute is that this is accurate between 9-14 days. However, it is far enough to determine when user was logged on to the domain the last time.

Now, you can see how to search that information in a domain. I have prepared test domain environment with 3 Domain Controllers on which I have logged on using iSiek user (except DC03). I will show you what kind of tools you can use to simplify that process.

Microsoft DS Tools

This method is the least convenient but it is available on any Domain Controller without requirement of any additional software to install. When you query AD for that attribute using DSQUERY command in LDAP query mode, its output is returned in int64 format which is unreadable to human and it is really difficult to determine a date when user logged on to domain. However, you can get that attribute and convert to human readable mode using i.e. w32tm command with /ntte switch.

Let’s try to get that information with DSQUERY and w32tm commands.

Note! Remember that this test environment has only 3 Domain Controllers and it is much more easy to run these commands on each of them separately to show you how this looks like. In real word, you may encounter many Domain Controllers per domain and it would be very difficult to run the query on each DC to get information about lastLogon attribute. If you want to get the date and time for particular Domain Controller then this attribute is accurate for you in other case you should use lastLogonTimestamp to determine the date of the last successful logon in a domain.

On each of my Domain Controllers in test lab I will run in command-line

On DC02 you can see the same lastLogonTimestamp attribute’s value as this was replicated between Domain Controllers but lastLogon attribute has different value as my user was authenticated by DC02 another day.

Output from DC02

to see that difference I will convert lastLogon int64 value

lastLogon attribute converted from int64 to human readable format

now, as you can see there is different date than on DC01

Difference between DC01 and DC02 lastLogon attribute

however, lastLogonTimestamp is the same on DC02

lastLogonTimestamp converted from int64 to human readable format

Now, on DC03 you can see that there is no value for lastLogon attribute as Domain Controller never authenticated the user

Output from DC03

and the last screen from DC03 for lastLogonTimestamp attribute. It is the same as on the other Domain Controllers

lastLogonTimestamp converted from int64 to human readable format

Quest PowerShell module for Active Directory

This is a 3rd party tool which needs to be downloaded from Quest web site and installed on any machine. When you do that, please see output of this query within a Quest console

as you can see, this tool is much more convenient in use than MS DS Tools. It automatically converts int64 value and displays only human readable date and time format. The same syntax was run on DC02 and DC03, so you can see results below

Output from Quest tool on DC02

Output from Quest tool on DC03

Windows PowerShell module for Active Directory

This tool is available when you have Windows Server 2008R2 Domain Controller. You can use it then from DC or from Remote Server Administrative Tools (RSAT) on Windows 7 client machine. This command differs a little bit from Quest syntax but it does the same.

you can see different output as lastLogon and lastLogonTimestamp attributes were not converted automatically from int64 value. To get date and time in human readable mode, you need to use another attribute in syntax. This is lastLogonDate

as in previous examples, you can see another Domain Controllers and their output in Microsoft PowerShell module for Active Directory

thank you for reading my article and for your suggestion 🙂
Yes I know ADFIND, but this is separate tool which is not always permitted in some companies that’s why I did not decide do describe it. But who knows, maybe some day, I will write an article how to use ADFIND?

no in this case position does not matter becasue there is “implication” (AND) used. That means the object must be from User class AND from Person category. The same for the second option: object mus be Person category AND User class.

Position matters if you use OR then it is really important to place syntax in correct order.

I hope I could somehow explain it to you 🙂 If you have other questions do not hesitate to ask.

And yes, I will try to prepare some article about ADFIND. Thank you very much for your suggestion