How do you figure out when someone was actually logged onto their PC?  By “logged onto” I mean, physically present and interacting with their computer. The data is there in the security log, but it’s so much harder than you’d think.

First of all, while I said it’s in the security log, I didn’t say which one. The bad news is, it isn’t in the domain controller log.  Domain controllers know when you logon, but they don’t know when you logoff. This is because domain controllers just handle initial authentication to the domain and subsequent authentications to each computer on the network. These are reflected as Kerberos events for Ticket-Granting Tickets and Service Tickets, respectively. But domain controllers are not contacted and have no knowledge of when you logoff – at all.  In fact, look at the events under the Account Logon audit policy subcategory. These are the key domain controller events that are generated when a user logs on with a domain account. As you can see, there is no logoff event. That event it only logged by the Logoff subcategory.

And really, the whole concept of a discreet session with a logon and logoff has disappeared.  You may remain “logged on” to your PC for days, if not weeks.  So the real question is not, “Was Bob logged in?” It’s more about, “Was Bob physically present, interacting with the PC?”  To answer this, you have to look at much more than simple logon/logoff events, which may be separated by long periods of time during which Bob is anywhere but at his computer.

Physical presence auditing requires looking at all the events between logon and logoff, such as when the console locks, the computer sleeps and screen saver events.

Logon session auditing isn’t just a curious technical challenge. At every tradeshow and conference I go to, people come to me with various security and compliance requirements where they need this capability. In fact, one of the cases that I was consulted as an expert witness centered around the interpretation of logon events for session auditing.

The absolute only way to track actual logon sessions is to go to the workstation’s security log. There you need to enable 3 audit subcategories:

1. Logon
2. Logoff
3. Other Logon/Logoff

Together, these 3 categories log 9 different events relevant to our topic:

• 4624 – An account was successfully logged on
• 4634 – An account was logged off
• 4647 – User initiated logoff
• 4800 – The workstation was locked
• 4801 – The workstation was unlocked
• 4802 – The screen saver was invoked
• 4803 – The screen saver was dismissed

But how do you correlate these events? Because that’s what it’s all about when it comes to figuring out logon sessions. It is by no means a cakewalk.  Matching these events is like sequencing DNA, but the information is there.  The best thing to do is experiment for yourself.  Enable the 3 audit policies above and then logon, wait for your screen saver to kick in, dismiss the screen saver, lock the console as though you are walking away and then unlock it.  Allow the computer to sleep. Wake it back up.

As you can see, there is some overlap among the above events. What you have to do is –between a given logon/logoff event pair (linked by Logon ID) — identity the time periods within that session where the user was not present as a result of:

• Sleep (that of the computer)
• Hibernation
• Screen saver
• Console locked

And count any session as ending if you see:

• Event ID 4647 for that session’s Logon ID (User initiated logoff)
• Event ID 4354 for that session’s Logon ID (Logoff)
• Event ID 4608 – System startup

As you can see, the information is there. But you have to collect it, and that is a challenge for most organization because of the sheer number of workstations. SIEM solutions like EventTracker automate this for you whether by remote event collection, which can be practical in some cases, or with the more feasible end-point agent.