Keeping Tabs on Object Access

Windows 2000's Audit object access category is an important source of OS-level information about how users employ your network. You can use this category to track the source, time, and method of access to files, folders, registry keys, and printers. To gather specific details about the logon session under which an access attempt occurred or the application through which a user tried to open an object, you can link object-access events to corresponding logon or process-tracking events.

Tracking at Two Levels
To track object access, you must activate Win2K auditing at both the system level and the object level. First, you need to enable the Audit object access category for success and failure events. (For details about how to enable system audit policy, see "Tracking Logon and Logoff Activity in Win2K," February 2001. For a full list of articles in this series about the Win2K Security log or my earlier series about the Windows NT Security log, see "Related Articles in Previous Issues," page 66.) Second, you need to enable auditing for each object you want to monitor. Each object has two ACLs: a discretionary ACL (DACL) and a system ACL (SACL).

The DACL. The DACL controls who can access the object and how. (Many people simply refer to the DACL as the ACL.) To open an object's DACL from Windows Explorer (for files and folders) or from Settings, Printers (for printers), right-click the object, select Properties, and go to the Security tab, which Figure 1 shows. This tab's simplified view of the DACL shows permissions for only one user or one group at a time. To view the entire DACL, click Advanced. This action opens the object's Access Control Settings dialog box, which Figure 2 shows.

The SACL. The SACL defines which actions Win2K audits for the object. An object's SACL consists of access control entries (ACEs). An ACE defines exactly which types of access Win2K records in the Security log when a specified user or group accesses the object. Each ACE also has a flag that specifies whether the ACE applies to successful or failed access attempts. To open an object's SACL, open the object's Access Control Settings dialog box and go to the Auditing tab. Each entry in the Auditing Entries box is an ACE. Figure 3 shows the SACL for a sample file (i.e., payroll.xls) and shows that Win2K will audit the Everyone group's successful attempts to gain write access and failed attempts to gain read access.

Tracking Attempts to Open Objects
Win2K audits object access at the moment when a user attempts to obtain access through an application. When a user tries to access an object from within an application, the application asks Win2K for a handle to the object. (Handles permit an application to operate on an object.) To determine whether to grant or deny the handle, Win2K compares the object's DACL with the user account under whose authority the application is running and with the access types (e.g., read, write) that the application has requested. Next, Win2K determines whether you've enabled the system audit policy to log the comparison's outcome. (For example, if the access attempt fails, Win2K determines whether you've enabled the system audit policy to log failed object access.)

If the system audit policy is enabled to log the outcome, Win2K then processes the object's SACL. Win2K examines each ACE that applies to the outcome and determines which of those ACEs specify the account under which the application is running or any groups that the user belongs to. Win2K then examines the access types that these ACEs specify. If any of the access types in the ACE match any of the access types that the application requested, Win2K generates event ID 560 (object opened) with an appropriate event type (i.e., Failure Audit or Success Audit). In the Microsoft Management Console (MMC) Event Viewer console, a lock icon identifies failed audit events and a key icon identifies successful audit events.

For example, suppose that Harold is working in Microsoft Excel and tries to open payroll.xls. Excel asks Win2K for a handle to payroll.xls. Win2K compares the file's DACL with Harold's user account and with Excel's request for read access; according to the DACL, Harold doesn't have permission to read payroll.xls. (As Figure 2 shows, only the Administrators and HR groups have access to payroll.xls, and Harold isn't a member of either group.) Win2K determines that the system audit policy is enabled to log failed object access, so the OS searches payroll.xls's SACL and examines each ACE that audits failed access attempts. Win2K determines which of these ACEs specify either Harold's user account or a group that Harold belongs to. As Figure 3 shows, the object's SACL contains an ACE that applies to failed read access and to the Everyone group, so Win2K logs the event ID 560 that Figure 4, page 68, shows.

Suppose that Sally also attempts to open payroll.xls through Excel. Because Sally is a member of the HR group, she has read and write access for payroll.xls. The system audit policy is enabled to log successful object access, and the file's SACL contains an ACE that applies to successful write access and to the Everyone group, so Win2K logs the event ID 560 that Figure 5, page 68, shows.

Event ID 560's fields are easy to understand. Object Server is always Security. Object Type identifies whether the audited object is a file, folder, registry key, printer, or service. Win2K fills in New Handle ID only when the object was opened successfully. If the user doesn't have the proper permission to the object, the attempt to open the object fails and Win2K doesn't create a handle ID. Operation ID is simply a number that Win2K increments for each operation that Active Directory (AD) performs.