Accuracy of LastLogon and LastLogonTimeStamp

[Don Jones]

We are using scripts to retrieve the LastLogon and LastLogonTimeStamp and are
finding that the values retrieve do not correspond with data in the security
log. With LastLogon, going to all the domain controllers and the value
retrieved is about 4 weeks older than what is in the security log. Using
LastLogonTimeStamp isn't much better, it's about 3 weeks older.

If we run the scripts against our development test AD Forest the scripts
appear to retrieve the values that are close to what is in the Security Log,
but when running against our production AD Forest,that is were we see a major
difference. We have found a single domain controller that wasn't having
changes applied. It was about 4 months behind. We do not manage our
Production AD Forest.

Is there any special privileges that are required to extract the lastlogon
or lastlogon timestamp info, that if you don't have the necessary rights will
produce bogus results? Is there a way to check the last time a domain
controller had changes applied without being a domain administrator?

Thanks.

Don Jones

[Richard Mueller [MVP]]

Don Jones wrote:

No special privileges required. The lastLogon attribute is updated at every
logon, but is not replicated. For each user a different value is saved on
every Domain Controller. The only way to get a true value is to query every
DC in the domain.

The lastLogonTimeStamp attribute is only updated if the old value is more
than 14 days old (by default, the interval can be modified). However, once
updated the value is replicated. You only need to query one DC but the value
is accurate to within 14 days. For most purposes this is satisfactory.

I have VBScript examples of programs to retrieve lastLogon and
lastLogonTimeStamp for all users in the domain at this link:

http://www.rlmueller.net/Last%20Logon.htm

--
Richard Mueller
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
--

[Don Jones]

Thanks for the reply. I ran your script and read up on LastLogon and
LastLogonTimeStamp and that is what generated the inquiry. We have another
organization that is in control of the users, and they are starting to
disable users due to inactivity, but when we look, we show a current
LastLogon for 2 controllers, and on another controller that LastLogon was
weeks out of date.

When we take what is produced and compare it with the snap-in Active
Directory Users and Computers, we see where the LastLogon and
LastLogonTimestamp is off.

I was looking at the ADIS Query and was going to exclude that one controller
to see how the dates look, but I must have the syntax wrong. I was trying to
use
strFilter = "(objectClass=nTDSDSA and AdsPath like '%some.domain')

[Richard Mueller [MVP]]

The program LastLogon.vbs is designed to query every DC in the domain. For
each user it retains the largest value for lastLogon in a dictionary object.
After querying all DC's it displays the largest (latest) value found. If any
DC has an old value there is no need to skip it.

Any value shown in ADUC must be based on lastLogonTimeStamp. If this value
is 74 days in the past, you know the user last logged on sometime between 60
and 74 days ago. This should be adequate information for disabling accounts,
unless some DC's are not replicating in your domain.

--
Richard Mueller
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
--

"Don Jones" <DonJ...@discussions.microsoft.com> wrote in message
news:CB4CC584-EF16-4A9A...@microsoft.com...

[Don Jones]

Thanks for the assistance. The group that manages our DC's have discovered
that several DC's were not replicating properly. They have contact MS for
assistance since, they have not been able to resolve it.

[coryg]

> Richard Mueller
> Microsoft MVP Scripting and ADSI
> Hilltop Lab - http://www.rlmueller.net

What about a domain running 2008 server? I have been doing some account
maintenance and I noticed that a recent password change has caused the
lastlogontimestamp attribute to be set to the timestamp when the password change
script was executed. Thanks.