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.
Register
