See all insights
Two-Factor Authentication Solution for Windows & RDP Logons
Under a Cloud of Suspicion
Auditing File Access in the Cloud
Information Security Advice for SMB (Infographic)
The Role of File Auditing in Compliance
Key Indicators of Compromise to Prevent a Breach
There is no way in Windows to get a report saying «John logged on at 8:00 and he logged off at 11:00.»
The reason is again that the domain controller does not keep track of the fact that John is still logged on here at this computer.
Some of you might think that if we combine the security logs on those domain controllers and filter the events correctly, we could get a report of all of the initial logons that will also show us all of these connections to other servers.
If you have tried, you know how problematic it can be just to get a list of all the initial logons from looking at your domain controller security logs, unless you have the capability to correlate multiple events down to one row on your report.
Some others might suggest that we could just track all of the network logon and logoff events and then put together a report from that that shows all logon sessions, showing us not only when John logged on but how long he stayed logged on and then when he logged off. Well, that does not work. When a user maps a drive to a server, opens up a file on this server and then closes it, the file server closes (within just seconds or at the most a couple of minutes) that logon session and logs a logoff event (in the security log).
The user is still sitting at his workstation and has just no idea that he just logged off from the server. When he next tries to open up a file over here on the server, the workstation notices that he has been disconnected and the workstation silently reconnects him to the server, which generates yet another logon event on the server. And then once he closes that file and does not have any other files open on the server, the server closes that connection again, generating another logoff event in the file server. That is why file servers usually show hundreds of logon and logoff events for the same user throughout the day.
So there is absolutely no way to piece together the user's overall logon session by looking at the domain controller logs or file server logs. And that leaves the security logs on all of your workstations. Except for some very high-security, government-related, small networks, I have never seen any company that collects all of their workstations' security logs. That is not to say it is impossible, but you can imagine the storage and licensing costs on of trying to do that and it is therefore pretty impractical to try to use the security log to generate this important report in the first place.
It gives the ability to answer crucial questions when it comes to investigations following an incident. Who was really logged on? Where were they logged on? When did they log on? How long did they remain logged on? When did they log off? At any given time, which people were actually logged on at their systems? And that is what we are not getting with Windows native Windows functionality …
This feature is nonetheless required for an Information System to comply with major regulatory constraints, including:
UserLock records all session logging and locking events in an ODBC database (Access, SQL server, Oracle…) for future reference. Reports can automatically be generated at regular intervals, in order to update an Intranet Web site, or being sent by Email (using third party software).
UserLock provides 9 predefined reports:
Share this page:
Free number for US & Canada: + 1-800-492-3951
GMT +1: +33 5 59 41 42 20