A few weeks ago I wrote an article about seeing who logged on to a computer.
After many of you emailed me, I started to investigate how accurate the script was – and it turns out not so much.
That script uses a WMI object to get its information. It returns what windows considers a ‘logon’. This can be anything from mapping a network drive to simply browsing for computers on the local network…but from our perspective this is not what we are looking for.
What we want to know is, did a user sit in front of this computer and actually logon?
An email from Emily shows how dangerous this inaccurate info can be:
“Hi Steve, I have used your script today because of a request by management to see if a fired employee was on other computers before he was let go. The strange part is that it shows I logged into computers I have never been on”
This is bad. Real bad.
Why does it show this bogus info? Because the WMI query shows every type of logon interaction. There is no way to filter out actual logins to the desktop.
What we really want is just the Interactive logons. The ones that happen when you sit in front of a machine, type a username and password, and login.
So what *is* the most accurate way to get this info? Auditing. The downside to this answer is that you need to enable auditing for logons *before* you need it, or it won’t be written to the security event log.
Let me start out by showing you how to enable auditing on your domain.
On your domain controller, open group policy for the group of computers you want to keep track of.
Then drill down to:
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy
On the right you will see a few options. Double click “Audit Logon Events” (Don’t mix it up with “Audit account logon events” – that will not help us here)
A settings window will pop up. Check “Define these policy settings” and check “Success” so you can audit successful logons.
After that you may need to wait 15 minutes or more for the policy to propagate across your network.
From a PC you want to audit, you can force group policy to refresh by typing this at the command line:
gpupdate /force from the command line
Now we are ready to get our logon info. Where does it show up?
It is in the security event log. The tricky part is that the event has a different code on different versions of Windows.
If you have Vista or higher, then you need to look for the event 4624. If you have a version of windows older than that then it would be 528.
I don’t know about you, but digging through that event log mess gives me a headache. So I created a script that will automatically parse this stuff out and print it out nice and neat:
You can get it from here:
Download it and just rename it to .vbs
One thing you will notice on Vista, Windows 7, Windows 8, 2008, 2012 systems…there are duplicate entries for a logon. I can’t find any documentation on this, but it only happens with Administrator accounts. My thinking is that this has to do with the split tokens used for UAC when you logon with an administrator account. No big issue really, since they are easy to spot.
On other thing to note – the times and dates are not in local time, but UTC.
Keep that in mind when you are preparing a report for someone.
We also updated the last logon report for Network Administrator. The nice part is you can use either method, the less reliable one, or the audit method:
Once you run the last logon report, it is quick to see who logged in, and when:
You can get a copy of it from here:
A special thanks to Steve in Ontario Canada for helping me test this, and noticing the duplicate issue.
As always our tools and scripts are free from adware, spyware – only IntelliAdmin goodness.
One more thing…Subscribe to my newsletter and get 11 free network administrator tools, plus a 30 page user guide so you can get the most out of them. Click Here to get your free tools