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:
Network Administrator Download Link
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
{ 13 comments… read them below or add one }
Wow, what a difference. I ran the last script you had and on my network it really had no good information.
Thankfully we have auditing already turned on. I just ran Network Administrator against 10 machines and it is very interesting looking at those logon records!
Thank you for such an informative post. It is like I have an expert with me once a week helping me look like I know what I am doing 😉
Hi Steve,
(I said this in the comments of your original post and I’ll say it now again)
If an account was locked and then unlocked Windows auditing will consider that as a logon with event 528 in Windows XP (IDK about Win 7 – maybe there unlocking doesn’t get an event 4624)
and the same is if I do a ‘runas’ it logs an event 528.
Thank you,
David
Yes…you are right about that. I forgot to mention it in this article…this is because both of these are considered “Interactive” logons.
I think you would also get those if you run PSTools, or our RemoteExecute against a machine using the interactive options….since really these are interactive logons.
That is where Jeff’s script would give you much more accurate info, since those events would not get polluted with these extraneous logons.
Great script steve, I wonder, do you need to turn this auditing on for Windows 7? It seems like my machines are already recording this stuff in the event log without me making any changes.
I think it depends. You are right in that Windows seems to enable it under Windows 7…but from my testing here it is not all the time.
We wanted to log this information as well – and as easy as possible. And bluntly assuming you’re in an AD running a common login script, I simply added this to the script:
‘** Add computername to log file.
Dim WSHShell
set WSHShell = CreateObject(“WScript.Shell”)
WSHShell.Run “cmd /c echo %computername% – %date% %time% >> \\fileserver\userlogon$\%username%.txt”
This gives you a small file where you can see instantly who logged into what box, incl. Citrix sessions, at what time.
Forgot to add – By enabling logoff script through GPO, you can do the same in that and register when users log off as well. Just had a case with an ex-employee claiming she had 700 hours overtime in 8 months. This was unfortunately not enabled at the time which would have making the ex’s – or our case, much easier.
Thanks again Steffen…great info.
(…)typing this at the command line:
gpupdate /force from the command line
Is that right?
Yes that is correct…but on 2000 or NT 4 systems you need to run this command instead:
secedit /refreshpolicy
Hi Steve, great articles here. Question for you, is there a way to monitor for exmerge operators RPD logon events only?
Hello Vinny,
I think it is possible, but not with our app. You need to examine the log for more than one event. The best way to get this info is to actually create a service that watches for logins…and the reason for this is that it seems windows is not super reliable in reporting these events.