Using Windows Auditing to track user activity
Вторник, 15 - Ноябрь - 2011 8 комментариев
Time to time something happens that requires us to answer ”who did it?” question. Those occasions are not as frequent, but important ones. A systems administrator is to be ready and prepared to address such issues.
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 add Everyone 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 launch eventvwr.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 → Filter command. 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 launch eventvwr.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.
In my working experience, several companies have dealt with deletion on purpose. The typical scenario was: the employee disgrunted with a contract break decided to remove all his work results and deleted his/her home folder content as well as all the shared documents he/she was intended to work with. Such an activity is very likely to be noticed in event logs because it generates tens and even hundreds successful Object Access records in a second. In fact, it’s easy to recover the deleted stuff from Shadow Copies (Previous Versions) or daily backup. But basically, I was always able to answer questions ”Who did it?” and “When did it happen?”
Очень ждем ваших постов по IPSec.
Sorry, I’m not using IPSec in a real business environment at the moment.
Hi friends,
Thanks for a great blog. I was able to get the information that I had been looking for. Thanks once again!
Thanks for this informative article !
Though, To audit the activities of users in my working environment, I use an automated tool named Lepide active directory auditor i.e.,(http://www.lepide.com/active-directory-audit/) that monitor AD environment at granular level and provide the report with real time monitoring.
However, this well described blog looks very helpful that shares the entire process in depth.
Nice Information in brief. Thanks.
Hemant
Уведомление: Alguien sabe activar auditoria para campertas compartidas en windowsxp?
Layer8 from Logfiller delivers this info and more direct from the UI so you can investigate the whole series of events from the Window Title.
Well described, it expiation that how to audit Active Directory User Creation. I tried this active directory auditing Steps ( http://www.esystool.com/how-to-enable-active-directory-security-auditing/ ) which help to trace who created the account in active directory with the help of this tool and get the complete information, and view structural changes through snapshot reporting.