Scripting. Stuff. (By Froosh)

February 2, 2009

Tracking AD last logon times

Filed under: Active Directory, Windows — Tags: , , , — Robin Frousheger @ 1:13 pm

Do some quick searches, and you will find that lastLogon is a non-replicated property that indicates when each individual Domain Controller authenticated an account, and (for Windows Server 2003 Forest Functional level domains) the lastLogonTimestamp is a replicated attribute that only updates every 14 days (minimum), but will at least be consistent across all DCs.

This is reasonably useful information, and can be found just about everywhere. But what about non-Windows client logons? What happens if clients are authenticated via LDAP or Mac OSX? How can I trust that “inactive accounts” based on lastLogonTimestamp are truly inactive?

These are my results, your mileage may vary, and my results may be inconsistent with other opinions.

My test:

  1. create a new, never used, account in AD
  2. authenticate to ad with the new account from an LDAP client (apache 2.2 on an Ubuntu server in this case)
  3. check the lastLogon and lastLogonTimestamp attributes

My results:

  • lastLogon attributes were not updated on any DC. FAIL.
  • lastLogonTimestamp was updated, then replicated to all DCs. Success.


  • Reports based on the lastLogonTimestamp can be trusted to provide a list of inactive accounts, as long as you are reporting on accounts older than 14 days. This applies to LDAP, and most likely other non-Windows client authentications.
  • Reports based on the lastLogon attribute can be much more accurate, but only for logons from Windows-based clients.  In a heterogenous environment, they are not to be trusted.

August 22, 2006

Old passwords are still valid with Windows Server 2003 SP1

Filed under: Windows — Robin Frousheger @ 12:22 pm

We’ve been pulling our hair out for a while because the software we use to provide e-mail synchronisation services for pocket pc users keeps providing very strange results when staff change their passwords.

The main symptom was that the sync software would still work without prompting for an updated password. It appeared to keep using the old password for a while, and then refuse to sync because it’s cached password was invalid. For some reason it did not recognise a password change.

The software vendor was utterly useless, sending us revision after revision of the software and claiming complete fixes. After a few fruitless cycles, they provided a work-around in which a single service account would be used to sync with their mailboxes. I wasn’t happy with their answer of “But you’re the only company reporting this issue” and they were not willing to pursue it.

Thankfully, I now at least have part of the answer: MS KB 906305 Windows Server 2003 Service Pack 1 modifies NTLM network authentication behavior.

This document states:

After you install Windows Server 2003 SP1, domain users can use their old password to access the network for one hour after the password is changed. Existing components that are designed to use Kerberos for authentication are not affected by this change.

And so it becomes clear. The sync software is using NTLM auth rather than Kerberos and so the old passwords are still accepted by the servers. It also explains why we could not reproduce it by logging into the machines interactively, as that uses Kerberos.

What I don’t have a satisfactory answer to is: When we logged a call with Microsoft Premier Support (yes, this costs a lot), they claimed that it was impossible, there was no way that the old passwords could be accepted.

Now I just have to cross my fingers and hope that the vendor will do something to fix our problem properly. I’m not expecting much.

Blog at