Access Denied: Operation-Based Auditing

We need to closely and accurately track changes to some important files. Windows 2000 Server and Windows NT Server let us use file auditing only when a user opens a file for a given type of access (e.g., write access). But a file that's been opened for write access isn't always changed—the user might have simply closed the file. I've heard that Windows Server 2003 lets you distinguish when a user has closed a file without using the access level and when a user has actually used the access he or she requested. Does Windows 2003 provide that ability? If so, how does it work?

Windows 2003 supports operation-based auditing, which Microsoft originally introduced in Windows XP. Earlier versions of Windows log just two events whenever you work with a file. When you open a file, Windows logs event ID 560. Event ID 560 identifies you, the file you opened, the program with which you opened the file, and the types of access the program requested (e.g., read, write). When you close the file, Windows logs event ID 562. You can use the handle ID that appears in the details of both events to link events. However, as you've observed, earlier versions of Windows let you know only the types of access a user had for a file when the file was opened—the OS can't tell you whether the user actually performed an operation on the file. Operation-based auditing introduces event ID 567 (Object Access Attempt). This event shows you the specific access types that were used on the object.

Say that event ID 560 tells you that Fred used WordPad to open the C:audittesttest.txt file for all types of read and write access. The Object Open section of this event lists handle ID 96 for Fred's file-open session, as Web Figure 1 (http://www.winnetmag.com/windowssecurity, InstantDoc ID 41902) shows. But did Fred actually use his write access to change the file? Looking at subsequent events in the Security log, you find the event ID 567 that Figure 1 shows; handle ID 96 tells you that this event corresponds to Fred's file-open session. Looking at the Accesses section of that event, you see that Fred used WriteData and AppendData on the test.txt file at 3:36 p.m. In other words, Fred changed the file, then saved it in WordPad. Then, you find the event ID 562 that Web Figure 2 shows, and it tells you that Fred closed the file at 3:37 p.m.

As you can see, event ID 567 provides the handle ID that the program obtained for the file when Fred opened it—the event doesn't provide the filename. To identify the filename, you must find an event ID 560 that has the same handle ID.

Operation-based auditing generates event ID 567 the first time a user exercises a specific permission on a particular file-open session. In other words, if Fred made further edits to the file, saved the file again, then closed it, Windows wouldn't log another event ID 567. However, if Fred reopened the file, changed it, then saved and closed it, Windows would generate another sequence of event IDs 560, 567, and 562.

No additional setup is required for operation-based auditing beyond what you must usually do to set up auditing on a file. To configure one computer, click Start, click Control Panel, double-click Administrative Tools, then double-click Local Security Policy. Navigate to Security SettingsLocal PoliciesAudit Policy, then click Audit Policy. In the Details pane, double-click Audit object access, then configure the Success and Failure auditing you want to use. To configure multiple computers, use the Microsoft Management Console (MMC) Group Policy Editor snap-in to enable the audit category in an appropriate Group Policy Object (GPO) under Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy.

The only difficult thing about using operation-based auditing is linking related event IDs 560 and 567. If you find an event ID 560 for an important file and you want to know which access types were exercised while the file was open, you must note the handle ID in event ID 560, then look for subsequent event ID 567s that have the same handle ID. When you find an event ID 567 and want to identify the file that it refers to, you must look for an earlier event ID 560 that has the same handle ID.