Workflow Soluiton

Hello -

I'm trying to retrieve the lastLogonTimestamp user attribute from Active Directory in a Workflow project.  I'm not able to do this using either (A) the Workflow Active Directory components, or (B) the Workflow LDAP Generator.  Does anyone have experience working with this attribute using Workflow?  Any/all insights are greatly appreciated.  Best, Tom

This post might be useful:

https://www-secure.symantec.com/connect/forums/ad-additional-attributes

Additional Attributes won't work for LastLogontimeStamp. LLTS is not a date field in AD, it is Interger(8) - which means it's a 64-bit number that represents the 100 Nano seconds interval between the last time a user logged in, and January 1, 1601.

I'll wait while you read that again, and I assure you the 1601 is NOT a typo!

According to NIST (National Institute of Standards and Time) - Dec 31, 1600 is Day 0, so Jan 1, 1601 is Day 1. The LLTS shows you how many 100 Nano-Second intervals have transpired between the last login, and Day 1. For instance, my current LLTS is 129565972450818998 - which translates into 7/25/2011 7:12:45 PM (and that is "wrong" as I logged in this morning - more on that later).

It means you can't really retieve it using WF or standard scripting, and in order to get a date from it, you need to perform a calculation against it.

Here is a VB script that does the work so you can see the math it takes to get a usable date (Fill in your full DN):
Set objUser = GetObject("LDAP://YourDistinguishedNamehere")
Set objLastLogon = objUser.Get("lastLogonTimestamp")
intLastLogonTime = objLastLogon.HighPart * (2^32) + objLastLogon.LowPart
intLastLogonTime = intLastLogonTime / (60 * 10000000)
intLastLogonTime = intLastLogonTime / 1440
Wscript.Echo "Last logon time: " & intLastLogonTime + #1/1/1601# 

Another thing to note, LastLogon and LastLogonTimeStamp are 2 seperate fields in AD. Last Logon is PER Domain Controller, and is not replicated. LastLogonTimeStamp IS replicated, but not mimmediately. It is replicated every 14 days, so doing a lookup for less than that that will bring back incorrect results. That is why my LLTS is "wrong" - it is reading it from a different DC than the one that processed my logon. If you have a single DC, then no problem, but if you have a large organization with multiple DC's spread around the world, it can be a problem.

You havea few options here. You can adapt this VB script using a script component, then just pass in a DN and you'll get back a date.

Or, you could attach a SQL server to your AD and use a function to get and convert the LLTS. This is what I do, but it does have it's disadvantages.

Powershell is another option, tho I've not tried it.

Lastly, you could use Visual Studio and create a custom DLL that does the reading and conversion, and then create a WF integration components to use it.

Good luck, and let me know if I can help!r

Rob
rob.moore@travelport.com

Over the weekend I created a custom DLL to retrieve the LLTS for any user in your AD.

All you need to do is pass in a DistinguishedName and it should return the LLTS in date time format. If the user does not have a LLTS, it will return 1/1/1601 - day 1 in microsoft parlance.

There are 2 DLL's, and you need to add BOTH to your project. It adds a new component under the Active Directory menu tree.

You need to have .NET 3.5 installed on your server. This was created in the latest version of WF 7.1 (7.1.1400.28), so you should be at that level to use this.

Just FYI - the application pool i run this under has a domain user for the identity, but that should not be needed as the AD should allow anonymous reads. If needed, I can add an authentication piece to it.

rob

Attachment(s)

LastLogonTimeStampIntegration.zip   5 KB 1 version

Awesome.  Thank you Rob.  I will give this code a try and let you know how it turns out.

As you may have guessed, my intended use case is to find instances of "inactive user accounts" within our AD environment, i.e. those accounts that have logged on in 90 days or more.  So short-term accuracy is not a big concern, but this Workflow should help me manage/police those account where, for whatever reason, "I never got the memo."

The alternative solution I started considering was to use Symantec RMS to pull the inactive accounts from AD and store the results in an MS SQL table, then create a SQL generator as part of a Workflow to read the records from the database table and take action.  That said, I find this direction more appealing since it relies exclusively on components managed within the Workflow environment.

I'll keep you posted...  Tnx, Tom

These compoennts work on DN's so you'll have retrieve all the DN's in your environemnt. if you have lots of accounts, this could be a problem, but not unmanageable.

I recently ran this against 2 domains managed by another group in my company, and of 5,000 accounts, only 800 had been accessed in the last year! They were quite shocked.

Glad to be of help, let me know if I can help! And if this works for you, make sure you mark the solution!

rob