One of the most important aspects of security is determining who is actually behind operations of security interest, such as file writes or security policy change. Although a thread that requests access to a resource is identified by the user ID, the thread might be impersonating someone else. In this case, it would be misleading to log events by user ID and might not be useful in finding the perpetrator in the case of a security breach.
Windows NT auditing and the security log use two levels of subject identification: the user ID (also called the primary ID) and the impersonation ID (also called the client ID), as applicable. These two IDs show security administrators who are performing auditable actions.
In some cases, however, a security administrator wants to see what is happening with each process. To meet this need, auditing information also includes a subject's process ID.
When process tracking is enabled (through the Audit Policy dialog box of User Manager), audit messages are generated each time a new process is created. This information can be correlated with specific audit messages to see not only which user account is being used to perform auditable actions, but also which program was run.
Many audit events also include a handle ID, enabling the event to be associated with future events. For example, when a file is opened, the audit information indicates the handle ID assigned to the file. When the handle is closed, another audit event with the same handle ID is generated. With this information, you can determine exactly how long the file remained open.
The following list shows some of the information from the security access token that Windows NT uses for auditing: