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.
Theoretically, the Process ID field can help you identify the application through which the user opened the object. However, the corresponding event ID 592 (new process), which the Audit process tracking category generates, displays a different format of process ID than do all other Win2K events. (I've heard that Microsoft corrects this problem in Windows XP and Windows Server—formerly code-named Whistler.) For events that show indirect object access, Process ID identifies the server application rather than the client-side application through which the user opened the object. When a user opens files in a shared directory, Process ID identifies the System process as the program that opened the object. (To verify this information, you can open Task Manager, go to the Processes tab, and look for the event's process ID in the PID column.)
Primary User Name and Primary Domain identify the user account of the user who directly accessed the object. When a user accesses an object on his or her local workstation through a desktop application such as Microsoft Word or Excel, Primary User Name and Primary Domain reflect the actual user account, and Client User Name and Client Domain are blank. When a user indirectly accesses an object through a server application, Primary User Name and Primary Domain reflect the local computer's account, and Client User Name and Client Domain reflect the user's user account. For example, Figure 6, page 70, shows an event ID 560 that occurred when Joe mapped a drive to the Tecra file server and opened budget.doc. Primary User Name is TECRA$, which corresponds to the file server's domain account. Client User Name identifies Joe as the client-side user.
Primary Logon ID and Client Logon ID list the logon ID of the user account that accessed the object. To determine the logon session under which the access occurred, look for an event ID 540 (remote logon) or event ID 528 (all other logons) that shares this logon ID. (See "Tracking Logon and Logoff Activity in Win2K" for information about these events.) If a user directly opens an object on his or her local system, event ID 560's Primary Logon ID corresponds to the logon ID in the event ID 528 that Win2K recorded when the user logged on; Client Logon ID is blank. When a user accesses a file remotely, event ID 560's Primary Logon ID identifies the logon session associated with the local computer's account, and the corresponding event ID 528's Client Logon ID corresponds to the Primary Logon ID.
The Accesses field documents the types of access that the application requested. Some access types are specific to an object's class, but several types apply to every object. Table 1 lists the most common access types and their meanings.
When a user opens a file or a folder, Accesses also documents any file-specific and folder-specific access types that Win2K granted the user. These access types correspond to the special permissions available in the file's DACL. ReadAttributes and WriteAttributes specify that the user opened the file with the ability to change its usual attributes (e.g., read only, archive, hidden, system). ReadEA and WriteEA apply to the file's extended attributes, which individual applications define. To view a file's extended attributes, open Windows Explorer and right-click the file. Select Properties, and go to the Custom tab and the Summary tab.
AppendData means the user had the ability to add to the opened file. ReadData and WriteData mean the user opened the file with the ability to read or modify the file's data. When you enable auditing on executables, Win2K logs the Execute access type whenever someone runs the program.
Win2K uses the same access types—with a few differences—to track access to folders. AppendData specifies that the user created a subfolder in the folder. Win2K logs WriteData when the user creates a new file in the folder. (To determine the name of the new subfolder or file, look for subsequent event ID 560 occurrences that correspond to the new child object.) Win2K logs ReadData when a user lists a folder's contents (e.g., by using the Dir command or from Windows Explorer).
Tracking Object Closure
Whereas Win2K logs event ID 560 when a user opens an object from within an application, the OS logs event ID 562 (handle closed) when the user closes the object. Event ID 562 contains some of the same fields as event ID 560.
Note the New Handle ID field in the event ID 560 that Figure 5 shows and the Handle ID field in the event ID 562 that Figure 7 shows. Win2K generates a different handle ID for every open object. Thus, you can determine how long an object was open by linking an event ID 560 and an event ID 562 that have the same handle ID. From Event Viewer, open an event ID 560 and take note of the event's handle ID. Right-click the Security log, and select View, Find. Enter 562 in the Event ID field and the handle ID in the Description field. If your Event Viewer is displaying newest objects first, change the search direction to Up, then click Find Next.
More Than Files
You can use the Audit object access category to track access to more than just files. For example, you can use regedt32 to enable auditing on registry keys and subsequently monitor access to registry keys and values. Registry values don't have individual DACLs or SACLs; instead, the parent registry key controls both access control and auditing. Win2K logs access types that correspond to the permissions in the key's DACL and uses plain English to describe the permissions in event ID 560. When access to a registry key triggers event ID 560 occurrences, Win2K lists the Object Type as Key. The Object Name begins with \REGISTRY, followed by the subtree and the rest of the key's path. For example, the subkey HKEY_LOCAL_MACHINE\SOFTWARE\Acme displays as \REGISTRY\MACHINE\SOFTWARE\Acme.
You can also access printer and registry SACLs through Settings, Printers. Simply follow the same steps as you would for accessing a file or folder's SACL, but start from Settings, Printers rather than from Windows Explorer.
Although the Microsoft article "Monitoring and Auditing for End Systems" (http://www.microsoft.com/technet/security/monito.asp) says you can audit system services, you can't. Even when you enable auditing in a service's SACL (through Group Policy under Computer Configuration, Windows Settings, Security Settings, System Services), Win2K fails to report to the Win2K Security log when you start, stop, or disable the service. Microsoft documents specific event IDs for several other operations (e.g., object deletion), but these events aren't functional either.
SACL Inheritance
In Win2K, SACLs follow the same inheritance scheme that DACLs follow. By default, SACL entries automatically flow from parent folders and registry keys to child objects. For example, when you enable auditing of failed writes on a folder, all the files and subfolders in that folder inherit its SACL. You can customize SACL inheritance at several levels.
At the child level. To block inherited parent SACL entries from reaching a child object, open the child object's Access Control Settings dialog box, go to the Auditing tab, and clear the Allow inheritable auditing entries from parent to propagate to this object check box. Then, click OK or Apply. If any inherited SACL entries are already in place when you clear this check box, Win2K asks whether you want to remove them or make noninherited copies of them.
At the parent level. To override child objects that have blocked inheritance, open the parent object's Access Control Settings dialog box, which Figure 8 shows, go to the Auditing tab, and select the Reset auditing on all child objects and enable propagation of inheritable auditing entries check box. After you click OK or Apply, Win2K resets auditing on all child objects and clears the check box so that you can selectively block inheritance on child objects. This reset option is useful when you aren't sure whether the system is overriding auditing on child objects and you want to start over from scratch.
You can also control how deep and to which child object inheritance flows for each SACL entry. To edit an individual SACL entry, open the parent object's Access Control Settings dialog box, go to the Auditing tab, select the entry, and click View/Edit to open the Auditing Entry dialog box, which Figure 9 shows. This dialog box shows two options for controlling how Win2K propagates the entry to child objects. The Apply onto drop-down list controls which types of objects receive the audit entry. The list defaults to This folder, subfolders and files, but you can select any combination of those three items. (Figure 9 shows a setting to audit failed reads that occur only on files, not on folders.) The Apply these auditing entries to objects and/or containers within this container only check box lets you control whether Win2K propagates the entry to objects that reside only in the immediate folder or whether Win2K recursively propagates the entry to all child levels from this point down.
Best Practices
What strategies should you use when you enable object auditing? First, use Group Policy if you have a certain directory or registry key that you want to audit on multiple systems. For example, if you want to audit failed writes on the \%system-root% directory of every computer in your domain, open the MMC Active Directory Users and Computers snap-in and right-click the domain root. Select Properties, and go to the Group Policy tab. Select the Default Domain Policy Group Policy Object (GPO), click Edit, then maneuver to Computer Configuration, Windows Settings, Security Settings, File System. Right-click File System, and select Add File. Type
%systemroot%
and click OK. A permissions dialog box similar to the one that Figure 1 shows will appear. Follow the steps I described earlier to enable auditing on an object. Carefully consider how widely you enable auditing. I don't recommend limiting whom you audit because attackers often use stolen or guessed passwords to impersonate other users. Therefore, specify the Everyone group in audit control lists to ensure coverage for all users. However, I do recommend that you carefully limit which objects and access types you audit. Object auditing generates large amounts of data. To reduce the amount of useless noise in your Security log, enable fewer access types for fewer objects.
To the inexperienced eye, Audit object access events can seem to indicate more activity than truly is happening on your system. You must remember that Win2K doesn't audit actual operations (e.g., read, write) on objects; rather, it audits an application's request to access the object. Therefore, event ID 560's Accesses field documents only the access that a user might have used, not whether the user actually took advantage of that access. The problem is exacerbated by applications that automatically request all access types to an object regardless of the access that the user needs. Microsoft has stated that it might eventually enhance Win2K auditing to audit actual operations rather than potential access.
Useful Functionality
You can use the Audit object access category to solve some challenging puzzles, such as whether anyone has tried to access data they shouldn't or who might have changed a certain file. Despite the inconvenience of excessive logged data, this category earns its place in your auditing arsenal.
| Related Articles in Previous Issues |
|
This article is the fourth in Randy Franklin Smith's series about the Windows 2000 Security log. You can find similar information about the Windows NT Security log in Randy's previous series. You can read these articles online at http://www.win2000mag.com. WIN2K SECURITY LOG ARTICLES "Mining the Win2K Security Log," April 2001, InstantDoc ID 20052 "Audit Account Logon Events," March 2001, InstantDoc ID 19677 "Tracking Logon and Logoff Activity in Win2K," February 2001, InstantDoc ID 16430 NT SECURITY LOG ARTICLES "Archiving and Analyzing the NT Security Log," August 2000, InstantDoc ID 9043 "Protecting the NT Security Log," July 2000, InstantDoc ID 8785 "Monitoring Privileges and Administrators in the NT Security Log," June 2000, InstantDoc ID 8696 "Interpreting the NT Security Log," April 2000, InstantDoc ID 8288 "Introducing the NT Security Log," March 2000, InstantDoc ID 8056 |
