Subjects and Impersonation

One objective of the Windows NT security model is to ensure that the programs a user runs don't have greater access to objects than the user does.

A subject is the combination of the user's access token plus the program acting on the user's behalf. Windows NT uses subjects to track and manage permissions for the programs each user runs.

When a program or process runs on the user's behalf, it is said to be running in the security context of that user. The security context controls what access the subject has to objects or system services. To accommodate the client-server model of Windows NT, two classes of subjects exist within the Windows NT security architecture:

• A simple subject is a process that was assigned a security context when the corresponding user logged on. It is not acting in the capacity of a protected server, which might have other subjects as clients.

• A server subject is a process implemented as a protected server (such as the Win32 subsystem), and it does have other subjects as clients. In this role, a server subject typically has the security context of those clients available for use when acting on their behalf.

In general, when a subject calls an object service through a protected subsystem, the subject's token is used within the service to determine who made the call and to decide whether the caller has sufficient access authority to perform the requested action.

Windows NT allows one process to take on the security attributes of another through a technique called impersonation. For example, a server process typically impersonates a client process to complete a task involving objects to which the server does not normally have access.

In the scenario shown in Figure 6.4, a client is accessing an object on a Windows NT server.

Figure 6.4 Server Subject Security Context

The first thread in the process is a control thread. It is waiting to receive remote procedure calls (RPCs) by means of a named pipe. This thread is not impersonating another process, so any access validation to which Thread 1 is subjected will be carried out against the process's primary token.

The second thread in the process is currently handling a call from a client. This thread handles the client's call by temporarily using the client's access token to run with that client's access permissions (that is, the client's security context). While impersonating the client, any access validation to which Thread 2 is subjected is carried out in the security context of the client.

The third thread in this scenario is an idle worker thread that is not impersonating any other process.

The following illustration shows an audited event in which impersonation was used. (Use the Event Viewer to see this type of information for your system.) Here, information for both the primary user and client user is recorded in the security log.