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

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

Mkline — Thu, 16 Apr 2009 09:54:15 GMT

Great information Warren!! I definitely learned some new things here.

Thanks

Mike

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

FrancisO — Thu, 16 Apr 2009 19:57:08 GMT

Outstanding article. The walkthrough was very useful.

Thanks!

Francis

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

sandeepanand — Sat, 18 Apr 2009 15:44:42 GMT

Nice Detailed article...

Warren ‘For Once not DFSR’ Williams > Was that a shot at Mr. Ned Pyle?

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

sandeepanand — Sat, 18 Apr 2009 15:44:58 GMT

Nice Detailed article...

Warren ‘For Once not DFSR’ Williams

BlogMS Weekly Articles Published – 13th April to 19th April

BlogMS - Official Microsoft Team Blogs — Mon, 20 Apr 2009 17:45:11 GMT

237 Microsoft Team blogs searched, 109 blogs have new articles in the past 7 days. 245 new articles found

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

Warren-MSFT — Mon, 04 May 2009 22:21:11 GMT

Thanks to everyone for the comments. Replying a bit late as I was out of the office.

Sandeepanand, you will have to talk with Ned about what the "For Once not DFSR" comment means. He ninja edited the document before posting it. It could be because both Ned and I work a lot on DFSR cases. However with Ned you never know...

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

KamleshAP — Tue, 05 May 2009 23:34:48 GMT

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.

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

Warren-MSFT — Wed, 06 May 2009 20:09:05 GMT

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

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

premmsn — Fri, 12 Jun 2009 23:34:37 GMT

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

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

Warren-MSFT — Sat, 20 Jun 2009 01:44:37 GMT

Thanks to everyone again for the feedback. I am beginning to see the need for some clarification on the bullet points regarding what types of authentications do not update the lastLogonTimeStamp.

It would be a rare deployment that only used “Certificate mapping through Microsoft Internet Information Services (IIS)” and “Microsoft .NET Passport mapping through IIS” for authentication to a Windows domain.

So unless you understand what “Certificate mapping through Microsoft Internet Information Services (IIS)” and “Microsoft .NET Passport mapping through IIS” are AND you know for a fact that your AD deployment uses them AND these are the only authentication types EVER used by a user then you do not need to be concerned about them.

“Username and password authentication through IIS” is too vague so it has been removed from the article.

I included these to make sure the post was complete as possible as there is always that one scenario… :) But it seems including them has been more of a distraction than has been helpful.

More information on the two methods can be found here.

Step-by-Step Guide to Mapping Certificates to User Accounts

http://technet.microsoft.com/en-us/library/bb742438.aspx

.NET Passport Authentication

http://technet.microsoft.com/en-us/library/cc778966.aspx

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

Warren-MSFT — Sat, 20 Jun 2009 01:47:13 GMT

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

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

clisbyt — Wed, 24 Jun 2009 17:21:15 GMT

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

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

Warren-MSFT — Wed, 24 Jun 2009 18:07:29 GMT

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

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

Warren-MSFT — Wed, 24 Jun 2009 19:00:00 GMT

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

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

wdanielw — Fri, 26 Jun 2009 16:59:36 GMT

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.

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

Warren-MSFT — Sat, 27 Jun 2009 00:37:53 GMT

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

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

DaveK57 — Mon, 29 Jun 2009 12:26:41 GMT

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.

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

Warren-MSFT — Mon, 29 Jun 2009 18:59:57 GMT

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

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

DaveK57 — Tue, 30 Jun 2009 10:41:09 GMT

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.

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

CameronM — Wed, 01 Jul 2009 02:39:08 GMT

Warren,

The Walkthrough section looks like it has a typo:

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

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:

6. Y ≥ X - update lastLognTimeStamp

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

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

Warren-MSFT — Wed, 15 Jul 2009 03:03:39 GMT

Cameron,

Thanks for the reply! I am glad the post was useful to you. And a big thanks as well for pointing out the error in the walkthrough example. I asked Ned to correct the article for those who don’t read all the comments.

Regards,

Warren