14 September 2006

Cornering the Elusive LastLogin Date

It rained this morning so I didn't have my 2K jog. I could have walked on the treadmill, but it's an old thing with no digital readout so I wouldn't know how much distance I cover. Maybe I need a pedometer after all...

In my line of work as Network Account Administrator, I often need to know if a Windows NT or ActiveDirectory account is in use. As results of many mergers, the network that I manage consists of many smaller ones. Slowly and surely, users and resources from the smaller networks are brought into the uniform network, but my daily work still involves handling accounts on different networks. Half of the time, the users don't know what network they are on, yet they call to report problems. "My account is locked", "I need access to this folder", yada yada yada. Lots of time, when I go to each network to find the troublesome account, the account name would be in more than one network. By finding out which account was used recently, I can determine that's the account that needs to be fixed. For example, Joe Block's account, BlockHead, is supposedly locked out, and I find such accounts in the two networks, NetHead1 and WebFooted2. The last login date for the account in NetHead1 goes back to 2004 while that for the WebFooted2 account is today. Unlock the account in Web and we have a happy customer.

One deficiency with Windows networks is that the last login dates for user accounts are
not centralized. Each time someone logs onto the network, he is authenticated to the nearest servers (domain controller or DC for short). Depending on network traffic, the server he authenticates to is not always the same one. On the different DCs he authenticated to would be found an entry recording the last time he connects to the network, or LastLogin Date. The feeble NET USER command only reports the LastLogin Date from some DC. DameWare NT Utilities has a way to query all DCs for the last login date for a given username. However, I often need to find out the LastLogin Date for a large number of users and up to now I haven't found a way to script the task. I know it is necessary to collect the data from each DC then sort the list. I have dappled with binding to LDAP providers and able to retrieve lots of useful info for any given number of accounts, but the LastLogin Date variable remains elusive.

In KiXtart, I've been using GetObject("WinNT://domain1/user1") to extract all kinds of info for a given user, user1, from a given domain, domain1. But how would I query a particular DC? Time and again, I searched with Google using many combination of keywords, but have yet found anything. Then today I came across a User-Defined Function (UDF) on a KiXtart site. It's as simple as GetObject("WinNT://Domain1/DC1/user1, user") !

The next challenge is to get a list of all available DCs and pass the list to GetObject(). Then the list of LastLogin Dates would have to be sorted and the latest date identified. I don't like to re-invent the wheel so I already plan to use the NLTest command to grab the list of DCs. When the list of LastLogin Dates becomes available, I would have to first convert the entries into some other formats that can be properly sorted, because the typical LastLogin Date is hh:mm ap mm/dd/yyyy, e.g. 11:16 pm 09/14/2005. I am pretty sure there's a way to convert the whole thing into one lengthy number, such that together they can be easily sorted. For example, let's say 11:16 pm 09/14/2005 is equivalent to 924929421134 while 8:22 am 11/30/1999 is 842424958312, then obviously the first number is greater. Computer programs love to set time to start at some point back in time and reference everything after that with a number, supposedly representing nanoseconds or whatever. Lastly, to sort the list, I'll just use the DOS command SORT, duh. Seasoned programmers probably frown on this practice of using external programs instead of writing one's own subroutines. Well, I'm a Network Account Administrator who write scripts to make his job easier, not a programmer exploring new frontiers. With today's CPUs, my scripts are fast enough for my purpose, no matter if I use external programs. Also, I include all the external programs in my folder structure, so as long as the entire folder is copied together, the script will continue to work.

No comments:

Post a Comment