Using Windows Auditing to track user activity

 Thanks to: http://blog.windowsnt.lv/

 In most companies there are departments like Project Managers, Accountants, Developers and other employee categories that collaborate and work together with groups of documents being stored in some shared folders on a fileserver or possibly workstations. Occasionally, someone deletes a particular important document or folder with a bunch of documents, resulting in a mission-critical data loss. Considering the described incident, few questions immediatelly arise:

• At what date and time the incident took place?
• Which backup should be used to restore the data?
• Was that an accident or an intentional user action?
• Or maybe that was some system failure that could happen again?

        In Windows OSs, there is an Auditing subsystem built-in, that is capable of logging data about file and folder deletion, as well as user name and executable name that was used to perform an action. The Auditing is not enabled by default because any monitoring you use consumes some part of system resources, so tracking down too much events may cause a considerable system slowdown. Even more, since not all user activity is of interest for logging, Auditing policies enable us capturing only event types that we consider being important.

        The Auditing subsystem is built-in into all Microsoft Windows NT OSs: Windows XP/Vista/7, Windows Server 2000/2003/2008. Unfortunately, Windows Home versions lack Auditing
policy configuration interface, thus making it too hard to configure.

What configuration should be performed?

        In order to enable Auditing, log on to a computer that keeps shared folder structure with administrative permissions, click Start → Run and launch gpedit.msc MMC console. In a Computer
Configuration node, open Windows Settings → Security Settings → Local Policies → Audit Policies folder:

        Double-click Audit object access policy and select Success checkbox. This policy enables file, folder and Windows Registry access attempts that were ended in a success.
Actually, this is true, we are only interested in a successful file or folder deletion attempts. Only enable Auditing on computers that keep required documents on their local hard drives.

        Simply enabling policy option is not enough. It is also required to designate what folders exactly are to be watched. Usually, we require auditing shared documents and business application data folders (accounting, warehouse databases and so on) – i.e., resources accessible for editing by multiple users.

        Since it’s not possible to guess who has tampered with a data, we configure auditing for Everyone system group. Thus, information about any user having deleted a watched object is to be captured and stored to the event log. Open the required shared folder properties and switch to the Security tab. Click Advanced → Auditing and addEveryone to the list, then mark both Delete checkboxes:

        It is highly possible that there will be too much events listed, so it is a good idea to configure the Security event log settings. To do this, click Start → Run and launch eventvwr.msc MMC console. Right-click the Security event log, select Properties and set the following options:

• Maximum Log Size = 65536 KB (for workstations) or 262144 KB (for servers)
• Overwrite events as needed.

Frankly, the log sizes recommended above are not calculated by any formula but are to be choosed depending on particular computer usage experience.

Finally, how do we find out the person (Windows 2003/XP)?

When the situation comes to the question, log on to the required computer, click Start → Run and launcheventvwr.msc MMC console. Open Security event log for viewing. It is
highly possible that not only the required events are logged. Right-click event log and select the View → Filtercommand. Consider the following events to be filtered:

• Event Source:Security;
• Category:         Object Access;
• Event Types:      Success Audit;
• Event ID:         560;

Watch through the filtered event list taking into account the following information fields inside each record:

• Object Name. The name of missing file or folder;
• Image File Name. The name of executable which was used to delete the object in question;
• Accesses. A set of accessed privileges.

The issue is that when performing certain procedures programs usually request multiple access types simultaneously — for example, Delete+Synchronize or Delete+Read_Control. The only important for us access type is Delete.

Finally, how do we find out the person (Windows 2008/Vista)?

When the situation comes to the question, log on to the required computer, click Start → Run and launcheventvwr.msc MMC console. Open Security event log for viewing. It is
highly possible that not only the required events are logged. Right-click event log and select the Filter Current Log command. Consider the following events to be filtered:

• Event Source:     Security;
• Category:         Object Access;
• Event Types:      Success Audit;
• Event ID:         4663;

Do not consider all the Deletes to be done on purpose. This action is frequently used as a part of normal business application standard functionality. For instance, during Save command execution Microsoft Office suite software first creates a new temporary file, saves document to it, then deletes the original document from disk. This is also true for many database applications: a temporary lock file (.lck) is created on disk and is being deleted from disk later when exiting the program.