User Logon Tracking Redux

A recent IT Pro Hero, Michael Dragone, discussed his batch-file solution for tracking employee logons on the company network and logoffs by user and computer (see "It's 10:00 p.m.: Do You Know Who's Logged On?" June 2007, InstantDoc ID 95922). Michael's solution consisted of a logon script that records the time a user logs on or off a machine and the computer being accessed, then writes this information to a log file on a server share. But one of my colleagues, Barry, a tech in the Calgary Separate School District in Calgary, Alberta, the same school district for which I work, discovered a potential loophole when he tried using a similar solution. In order for the information to be appended to the log file, users would require write access to the log file—so a student could possibly tamper with the log file. To avoid this problem, I developed a solution for my employer, Bishop Grandin High School in the Calgary Separate School District, which uses a Group Policy Object (GPO) to turn on event-log auditing, then transfers those event logs to a central network share that users can't access.

At the school, we force users to shut down or restart their computers at the end of their session rather than simply log off. On the students' computers we use Faronics Deep Freeze (http://www.faronics.com), a product that preserves a computer's original configuration by clearing any changes made to the computer and any files saved on the computer when the computer is rebooted. Thus, the next logical step in my solution was to institute a shutdown GPO, which runs a startup/shutdown script on a computer and transfers the computer's event logs to the central share using the freeware EventSave utility (more about EventSave shortly). I opted to use a computer-based GPO for the shutdown so that we wouldn't need to worry about giving a user account any special access privileges.

Moving the Logs
I knew that Frank, a systems analyst for our school division, used the freeware EventSave utility from Frank Heyne Software (http://www.heysoft.de/frames/f_home_en.htm) on his server builds. You can use the utility (eventsave.exe) in a batch file to transfer event log files from one computer to another. Frank uses scheduled batch files to regularly clear our servers' event logs while still maintaining the logs in a central location if we ever need to look up log information.

I decided to use the same method on my student workstations as part of my solution to track students' computer use. I created the following batch file (adapting its syntax from the EventSave FAQ at http://www.heysoft.de/Frames/f_faq_evt_en.htm):

start /wait \\server\share$\EventSav.exe \\server\ _
share-to-where-event-logs-are-saved /c 

(Note that the /c switch terminates the cmd.exe window and also that the previous line wraps to multiple lines because of space print constraints. You should type the actual command on one line.) Because we were simply transferring the event logs to a central share, users couldn't tamper with a log file, since no log file would exist.

Searching the Logs
After I developed the logging and shutdown mechanisms, my final step was to create an easy way to search the collection of saved event logs for events confirming an account's successful or unsuccessful logon/logoff and events stating when the computer was successfully shut down. To do so, I used the utility in the Windows Scripting Solutions article "The Event Log Query Utility," December 2006, InstantDoc ID 93973, to set up an HTML Application (HTA) that searches event logs for specific event IDs, then generates a Microsoft Excel spreadsheet containing the ID, audit type, and description of each event in the log. (Windows Scripting Solutions is now Scripting Pro VIP. For more information, go to http://www.scriptingprovip.com.) I also referred to the Microsoft article "Security Event Descriptions" (http://support.microsoft.com/?kbid=174074) to obtain information about the ID numbers used for successful and unsuccessful logon attempts.

We store the saved event-log information for a term (about two months), then typically delete it. Because of Alberta's privacy laws, only IT staff members have direct access to the logs at present. We can easily view the saved logs via the Event Viewer. Although the logs are maintained chiefly for security purposes, we can also make them available, on request, to administrative staff or teachers to provide information such as the frequency of use of computers by students, classrooms, and programs and peak-usage times.

Easy Information Access
We've been using the GPO-based solution since April. So far, the solution's chief benefit is that it gives IT an easy way to search for computer-use information upon request. Like most IT professionals, I'm used to running around to put out fires. But taking a little extra time to anticipate our staff's need for information about students' computer use has helped me to think more proactively about my IT role.

End of Article