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. With the client-server model of Windows, user account identification can be rather tricky. Although a thread that requests access to a resource is identified by the user ID, the thread may be impersonating someone else. In this case, it would be misleading to log events by user ID and may not be very useful in finding the perpetrator in the case of a security breach.
To prevent this problem, there are two levels of subject identification used in Windows NT auditing and the security log—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 where possible.
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. 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. This could be useful, for example, when you want to assess damage following a security breach.
The following list shows some of the information that Windows NT tracks within a process's access token. This information also is used for auditing.