Skip navigation

It’s 10:00 P.M.: Do You Know Who’s Logged On?

Systems engineer Michael Dragone’s batch-file solution tracks employee logons by user and computer

Downloads
95922.zip

Security problems are typically a small part of Michael Dragone's job as a systems engineer for Titleserv, a title insurance and real estate services firm in Woodbury, New York. But when senior management asked him to devise a way to track employees' network logons and logoffs, Michael was challenged to find a solution that didn't rely on the Active Directory (AD) Security event log, which retains logons, logoffs, privilege assignments, and other events only for a short time until they're overwritten. Michael talked to me about how he fulfilled management's request by using straightforward batch-file scripting to capture logon/logoff data on the clients and move that data into text files and folders for easy retrieval.

What inspired you to create the user logon/logoff solution?
Our internal production system is a Web application based on Microsoft .NET Framework, and it has an internal logging component that tells you when people logged on, when they logged off, what they did, and so on. We had a lot of requests from management to provide a similar capability for our end users' PCs. A manager might want to know, for example, if someone requested overtime pay last month, whether that employee was really working overtime. To confirm this, the manager wanted to be able to find out when someone logged on or whether an employee was working on a particular computer at a particular time. That information is logged in AD, but it goes in the Security event log, which can't retain more than 50MB of data and has other events besides those management wanted to track. It would take a lot of scraping through the logs to find the information management wanted.

So you found an alternative method for capturing the logon information?
Yes. I decided to write a batch-file command that would run on all our clients and servers at system logons and capture logon and logoff information for our Windows XP clients and our servers (Windows Server 2003, Windows 2000 Server, and Microsoft Windows Server 2003 and Windows 2000 Server Terminal Services). When a user logs on, a script runs; at logoff, another script runs. The script appends the logon and logoff information to a text file. The text files contain cumulative information: One line says, for example, "logged out of computer name on" and the date and time. The next time the user logs on, the script writes another line in the text file with the new information. (You can download an excerpt of Michael's script. To do so, go to http://www.windowsitpro.com, InstantDoc ID 95922, and click the Download the Code button.)

Another batch-file script retrieves logon/logoff information for a computer. If we want to know who logged on to a computer, we can check the computer's text file for the user name and the logged-out-on and logged-in-on information. The script copies the text file into one of several folders, depending on which machine the script is running. All the users go in one folder, whereas the logons we track by computer are copied into the folder for the appropriate computer type (e.g., server, client). The scripts are run via our existing Group Policy Objects (GPOs), which are segregated by machine. We use our GPOs in merge loop-back-processing mode, so that all user-configuration settings (including this script) are applied regardless of who logs on.

How does management access the logon/ logoff information?
Right now, management will just ask us (IT), and we'll send them over the text file. It takes us seconds to browse the file share and directories where the files are located. We have only 150 users, so this method is manageable for us. We get a lot of requests from managers saying "I need to know if so and so logged on from home. Did they do any work last night?" So we can check the Terminal Services log and find out, say, that the employee logged on at 10:00 p.m. and logged off five minutes later. We zip up the text files, so we can archive them indefinitely.

Did you look into buying a third-party tool that could provide this type of log information?
I looked at some third-party utilities, and there are a lot of utilities that do event-log stuff. But all I wanted to do was track logons and logoffs; the third-party utilities provided a lot more information than I really needed. I didn't really want to buy a utility just for that one purpose, when with a little work, I could do it for free.

How long did it take you to write the batch file, set up the folders, and test your solution?
It took just a few hours to write the batch-file scripts and test them. It took longer to set up all the directories and make sure that, based on where a computer user is in AD, the appropriate script runs and goes in the appropriate folder—so I don't have client PCs showing up in the servers folder, for example.

Have you noticed any changes in user productivity since you began using the logon/logoff tracking system?
I don't think the solution has changed peoples' work habits; they either have a work ethic or they don't. It just makes IT's life easier. Instead of having to pore through event logs, if somebody wants the information, we can just go right to the correct directory, locate the text file, and email it to them. It saves us a lot of time.

Editor's Note:
Long-time reader and contributor Murat Yildirimoglu pointed out that the scripts used in this article are similar to the scripts Murat published in August 2005 in "Prevent Multiple Logons With GPOs".

TAGS: Security
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish