The security log identifies the user account that caused each recorded event to happen. In some cases, more than one account is actually involved because of the client-server design of Windows NT. This design makes it possible for one process (called a server process) to perform actions on behalf of another process (called the client process).
When the server process is acting on behalf of the client, Windows NT security treats it as though it were the client process. The server process is not allowed to access objects that are off limits to the client.
Also, the audit records for events performed by a server impersonating a client identify the "user" that "owns" the server process as the primary user (typically identified as SYSTEM), and the user responsible for starting the client process as the client user. When there is no impersonation taking place, the primary user is the actual user who started the process that caused the audited event to occur. Most often, this is the user who is actually logged on to the computer, although sometimes it can be SYSTEM.
Primary IDs and impersonation IDs provide enough information for many security administrators because they show who is performing auditable actions. However, in some cases, an operator might want to see what is going on at a process-by-process level of detail. If detailed tracking auditing is enabled, the security log shows when a new process is created (such as when an application program begins execution). Each process is assigned its own, globally unique process ID, which is included in all records of events caused by that process, to the point at which the process ends.
This information can be correlated with specific audit event records to see which user account is being used to perform auditable actions and which program was being run. Process IDs are included in audit event records regardless of whether process-level tracking is enabled. However, process IDs are useful only if process-level tracking is enabled.
Note
Because of the way impersonation works, it is impossible to know what the process ID of a client is at audit time. In fact, a single access token can actually be used by several processes simultaneously. For this reason, process IDs can only be displayed by audits generated by the Kernel.
When a particular operation consists of multiple actions, Windows NT assigns an operation ID to each so you can properly associate the separate actions with the operation. This operation ID is unique only to the process performing the operation. Furthermore, to help you track how a process accesses a particular object, each object is identified by a handle ID. Typically a new handle is allocated immediately after a file is opened, and then closed when the file is closed. If the handle ID refers to a Kernel object, the handle ID is unique only to the process to which the handle belongs. If the handle ID refers to an object managed by a protected server, the handle ID is unique across all processes.
The handle ID enables the audit to be associated with future audits. For example, when a file is opened the audit information indicates the handle ID assigned. When that handle is closed another audit event record is generated which also includes the handle ID. This allows you to determine the entire span of time the file was open, which can be useful when attempting to assess damage following a security breach.
There are two types of handle IDs, often called Kernel object handle IDs and protected server object handle IDs. Handle IDs to Kernel objects are unique only to the process to which the handle belongs. As a result, two processes can have a handle with an ID of 35, for example; they are distinguished by the process ID associated with them. Handle IDs to protected servers on the other hand, come from a single ID space and are unique across all processes.