Auditing Specific Events

So far in this series, I’ve explained the importance of auditing and given you some guidelines for establishing an effective audit policy. However, the greatest audit policy in the world does little good without proper implementation. In Part 2 (
Setting Up an Audit Policy
), I began discussing some techniques you can use to audit various situations. These auditing techniques need refinement before they become truly effective; in this article, I’ll show you how to target your audit policy toward specific events.

Auditing Files and Folders

In Part 2, I showed you how to enable auditing for files and folders, but not how to select which files and folders to audit. Auditing files and folders works a little differently in Windows 2000 than it does in Windows NT. The following steps show you how to audit files and folders–assuming that you’ve already worked through Part 2 of this article series:

  1. Use My Computer to navigate to a file or folder you want to audit. This file or folder must be on an NTFS partition.
  2. Right-click on the file or folder and select Properties from the resulting context menu.
  3. In the object’s properties sheet, select the Security tab. Click Advanced to access the object’s Access Control Settings.
  4. Select the Access Control Settings properties sheet’s Auditing tab. Select the Auditing tab, and you’re ready to begin implementing the auditing process.

Before you begin adding audit policy entries to the object, you need to be aware of two check boxes at the bottom of this window. The first check box is labeled Allow Inheritable Auditing Entries From Parent To Propagate To This Object. This check box is selected by default. Its function is to automatically apply the same audit settings to the object as apply to the object’s parent. For example, suppose you have a directory called TEST that contains a subdirectory called A. If this setting is enabled and auditing is applied to TEST, the same auditing will automatically apply to TESTA.

The second check box is Reset Auditing Entries On All Child Objects And Enable Propagation Of Inheritable Auditing Entries. This check box’s function is to reset the auditing entries of child objects so that they will inherit their parent’s audit policy. This property is good for clearing out an unwanted audit policy.


Now that you know how the two check boxes work, let’s take a look at the actual process of auditing a directory:

  1. Click Add. When you do, you’ll see a list of groups. As you may recall, in Windows NT, auditing a directory involved making an audit log entry any time anyone accessed the directory. In Windows 2000, you can audit only specific groups of people.
  2. Select the group you want to audit from the list and click OK. When you do, you’ll see a long list of actions that members of the group could potentially perform. You can implement a success or a failure audit on any of these actions. For example, you could make an audit entry if a member of the Guest group tries to delete a file. You can see most of the actions that can be audited in Figure 1.

Auditing a Directory

Figure 1
Figure 1: Windows 2000 allows you to audit a wide variety of actions on a per-group basis.

As you can see, you can audit quite a few actions. Because some of the actions may be a bit unclear, and because other actions aren’t listed in the figure, I’ll describe each action:

  • Traverse Folder/Execute File–In the case of a folder, this event is triggered when a member of the group tries to pass through the folder in an attempt to reach a subfolder or parent folder. If this window were for a file, the event would be triggered if a member of the group tried to run the program.
  • List Folder/Read Data–In the case of a folder, the event is triggered when a member of the group tries to view the contents of the folder. In the case of a file, the event is triggered when a member of the group tries to read data from within the file.
  • Read Attributes and Read Extended Attributes–This event is triggered when a member of the group tries to display the attributes (or extended attributes) of the file or folder.
  • Create Files/Write Data–This event is triggered when a member of the group tries to create files in the folder or add data to the file.
  • Create Folders/Append Data–This event refers to the condition in which a member of the group either creates a subfolder within the existing folder or appends data to the end of the file without overwriting any of the file’s existing data.
  • Write Attributes and Write Extended Attributes–These events refer to a member of the group trying to change the file or directory’s attributes or extended attributes.
  • Delete Subfolders and Files–This event is triggered when a member of the group deletes a file or subdirectory within an audited directory.
  • Delete–The Delete action is logged when a group member tries to delete a file or folder.
  • Read Permissions–This event is logged when a group member tries to see who has permissions to a file or folder, or if the group member tries to determine the owner of the file or folder.
  • Change Permissions–This event is logged when a group member tries to change who has access to a file or folder.
  • Take Ownership–The Take Ownership event is triggered when a group member attempts to take ownership of a file or folder.

Remember that you can audit either successes (for example, the file was deleted) or failures (Bob tried to delete a file) or both for any event. In Part 4 of this series, I’ll continue the discussion by talking about auditing Active Directory objects. //

Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.

Actions You Can Audit

Latest Articles

Follow Us On Social Media

Explore More