This excerpt from Chapter 5 of "The definitive guide to Windows 2000 security" describes the concept of impersonation and impersonation tokens.

Get a glimpse inside Paul Cooke's e-book "The definitive guide to Windows 2000 security" with this series of book excerpts, courtesy of This excerpt is from Chapter 5, "Configuring access control." Click for the book excerpt series or get the full e-book.


Before discussing impersonation access tokens, I want to go over the concept of impersonation. Windows 2000 supports the notion of impersonation, which is the ability to execute a thread with a different security context than that of the thread's owner. The need for impersonation is driven by the proliferation of client/server applications that predominate today's computing environments. When a client contacts a server, the server typically runs with the security context of some service account that has access to every resource that it might possibly need to carry out a request.

For example, if Alice contacts a service to retrieve an electronic copy of her pay stub, the service must have permission to access her pay stub. If Bob contacts the service, the service must have permission to access his pay stub. The level of access holds true for all the employees in an enterprise. However, what if the service had a bug and Alice was able to tell the service to get her a copy of Bob's pay stub? From a security perspective, this level of access is obviously something that we don't want.

Impersonation overcomes the problems inherent in allowing a service to access all resources by allowing access checks to be performed against the requestor of the service, not the service itself. Thus, the service performs access control checks against the identity of the client. Going back to the pay stub example, if impersonation is used and Alice once again tries to retrieve a copy of Bob's pay stub, the service takes on the entity of Alice, then tries to access the pay stub. Windows 2000 uses the identity of Alice and (hopefully) determines that she isn't authorized to view Bob's pay stub.

Impersonation access tokens

The ability of a process to impersonate another user is implemented using impersonation access tokens. The service runs with its usual primary token, one that is associated with the primary control thread of the service process. This token makes access checks when the service needs to access objects of its own accord.

When a service accepts a client request to perform a function, the service needs to create a thread to do the work on your behalf and associate your access token to this thread. This association is carried out using the impersonation access token, whereby your access token is copied into the impersonation token of the thread. The impersonation token is used whenever the service requests access to an object on your behalf. Once the service is done being you, the thread goes back to using its primary token and runs in the service's own security context. The notion of primary and impersonation access tokens is depicted in Figure 5.15.

Figure 5.15: Primary and impersonation access tokens

When impersonation is used, it signifies that a client has agreed to let the service act on the client's behalf, as if the service actually were the client. The client process controls to what extent a service can act on the client's behalf by selecting an impersonation level. The choice is in the hands of the client and not the service. To a certain extent, the concept of impersonation is similar to granting someone power of attorney over your affairs. Four levels of impersonation are available:

  • Anonymous -- The client is anonymous to the service.
  • Identify -- The service can use the identity of the client in its own security mechanism but cannot impersonate the client.
  • Impersonate -- The service can impersonate the client but cannot pass on the client's identity to another service.
  • Delegate -- The service can impersonate the client not only when it accesses resources on the service's computer but also when it accesses services on other computers.

Click for the next excerpt in this series: Restricted access tokens

Click for the book excerpt series or get the full e-book.

Read more on IT jobs and recruitment