To find out what user deleted a specific file on the windows server

Posted on 2008-11-12
Last Modified: 2012-05-05
Is there a way to find out what user deleted a specific file on our Windows 2000 server? Some log file somewhere on the server
Question by:anandkswamy2008
    LVL 2

    Expert Comment

    Sorry bro.  I think you have to do this one ahead of time.  By default the Windows Server is not set to audit changes made to YOUR data.  You can fully choose to audit all types of drives, folders, files and shares for any type of activity you would like.  If you didn't have this set up initially you might not be able to this time.  :( Sorry dude.  Check your settings and see if you or someone else has enabled it.  Check this out.
    LVL 7

    Accepted Solution

    I would check event logs as sallyfingers stated. I would also setup a monitor and set triggers to allert you when users are deleting files.  

    Here is how you can audit folder access:

    While auditing file and folder access on a client's home computer or a networked office machine is probably overkill, I recommend auditing any publicly accessible computer, whether its networked or not. Auditing file and folder access allows you to test your security policy and determine whether any users are trying to use the machine in an unauthorized manner.

    For example, fellow TechRepublic contributor and friend Troy Thompson teaches high school computing courses. Since a classroom full of high school kids is about as hostile an environment as you're going to find, Troy audits each machine to detect any unauthorized use.

    Enabling auditing
    Before you can audit file and folder access, you must enable the Audit Object Access setting in the machines group policy. Log on to the machine with a local administrative account and open the Control Panel. Double-click the Administrative Tools icon and then the Local Security Policy icon. Doing so will display the machines group policy settings.

    Navigate through the console tree to Security Settings | Local Policies | Audit Policy. When you select the Audit Policy container, the column to the right will display a number of different events that you can audit, as shown in Figure A.

    You can audit a number of events.

    As you can imagine, its easy to get carried away with the idea of an ultrasecure machine by auditing absolutely everything. But this is a bad idea for several reasons. First, the audit process builds log files. Each entry in the log consumes a small amount of hard disk space. If too many audited events occur, your machine could run out of hard disk space. Second, each audit also consumes a small amount of CPU time and memory. So excessive auditing can negatively affect system performance.

    Perhaps the best reason for not auditing everything is information overload. I have seen situations in which several hundred events are audited every minute. This makes it virtually impossible to locate anything useful within the logs because the useful log entries blend in with the garbage entries. My advice is to use discretion when creating an audit policy. Dont audit anything that you dont absolutely need to know about. The more you refine which events are audited, the more meaningful each audited event will become.

    Lets take a look at some of the available auditing options. Obviously, which audits are appropriate for your needs will vary depending on your environment. For general purpose auditing, though, I recommend auditing logon events so that you can tell when users have logged on or off. I also recommend auditing object access (i.e., files and folders). Auditing object access will allow you to see who does what to designated files and folders. Finally, I recommend auditing policy changes. This is a big one, because if someone is tampering with the machines security policy, you really need to know about it.

    To enable these types of auditing, double-click the appropriate option within the Local Security Policy Settings console. You will then see a dialog box similar to the one shown in Figure B. As you can see in this figure, you can implement a failure audit and/or a success audit for each event.

    You can perform success and/or failure audits for each event.

    So how do you know whether to perform a success or a failure audit? Well, thats really up to you. For logins and policy changes, I recommend auditing both success and failures. For example, a success audit of login actions would create an audit log entry every time someone logged in successfully. A failure audit of the same event would write an audit log entry every time someone entered a password incorrectly. Likewise, a success audit on policy changes would let you know that someone changed a security policy, while a failure audit would tell you that someone tried to change a security policy but didnt actually manage to make the change happen.

    When it comes to auditing object access, I recommend also enabling success and failure audits. Just because success and failure audits are enabled for object access, though, it doesnt mean that you actually have to use them. Every object that you audit access for has an entire range of audit options. Enabling success and failure audits simply make these options available to you.

    Auditing object access
    You must be careful which objects you audit or you will end up with the information overload problems. It's very easy to end up with information overload because if you audit a folder, the audit applies to every object within the folder and within any subfolders. The audit applies to child objects, grandchild objects, and so on. So when possible, I recommend auditing objects at the file level. For example, if you needed to know who made the most recent changes to an Excel spreadsheet, it would be better to audit the actual XLS file than the folder containing it.

    I also recommend that you avoid auditing system files and folders. Doing so can also result in information overload. For example, if you were to audit the Windows folder, you would end up with countless audit log entries because the system is constantly accessing files found in this folder. If you really wanted to audit Windows, a better solution might be to audit the registry files.

    To audit a file or folder, right-click it and select the Properties command from the resulting menu. Youll see the objects Properties sheet. Select the Properties sheets Security tab, and click the Advanced button to display the Access Control Settings Properties sheet for the object. Select the Auditing tab. Then, click the Add button, and youll be presented with a list of users and groups. Select the users or groups that you wish to audit, and click OK.

    For example, years ago, I worked for a large insurance company. At the company, a woman on the administrative staff was deliberately doing things to sabotage the system. Before we confronted her with this information, we needed to build a case against her. So we created audit policies that applied only to her. This way, we could watch every move she made without being flooded with thousands of log entries pertaining to other users.

    Once you have selected a user or group, youll see the dialog box shown in Figure C. As you can see, you can enable success and/or failure audits for many types of access to the file or folder on a user or group basis.

    You can audit a number of different access types for files and folders.

    Viewing audit results
    You might be curious to know how to view the audit results. Open the Control Panel and double-click the Administrative Tools icon and then the Event Viewer icon. When the Event Viewer opens, click the Security container to see the security logs, as shown in Figure D. In the figure, youll notice how many log entries were applied in a matter of a few seconds. This is why its so important to use discretion when creating an audit policy. If you want to get more information on a particular event, simply double-click it.

    Good luck.....

    Featured Post

    Find Ransomware Secrets With All-Source Analysis

    Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

    Join & Write a Comment

    Forefront Threat Management Gateway 2010 or FTMG comes with some very neat troubleshooting tools built-in when trying to identify what is actually happening behind the scenes within the product when traffic is passing through its interfaces. To the …
    Many admins will agree: WSUS is is a nice invention but using it on the client side when updating a newly installed computer is still time consuming as you have to do several reboots and furthermore, the procedure of installing updates, rebooting an…
    Windows 8 comes with a dramatically different user interface known as Metro. Notably missing from the new interface is a Start button and Start Menu. Many users do not like it, much preferring the interface of earlier versions — Windows 7, Windows X…
    In this video, we discuss why the need for additional vertical screen space has become more important in recent years, namely, due to the transition in the marketplace of 4x3 computer screens to 16x9 and 16x10 screens (so-called widescreen format). …

    728 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    15 Experts available now in Live!

    Get 1:1 Help Now