The Impersonate Privilege and Windows .NET Server 2003

The impersonation model works really well with the trusted subsystem model the server is all-powerful and controls access to all resources it owns. However, what we are seeing now is a factored model, where the server is not all-powerful and does not own the resources they belong to the next server in the chain. Because it is possible for a not-so-trusted server to impersonate a highly privileged account and potentially become that account, we added a new privilege to Windows .NET Server 2003 SeImpersonatePrivilege. The details of the new impersonate privilege are shown in Table 7-7.

Table 7-7. The Impersonate Privilege
#define	Name	Value
SE_IMPERSONATE_NAME	SeImpersonatePrivilege	29L

By default, a process with the following SIDs in the token has this privilege:

SYSTEM
Administrators
Service

The Everyone account does not have this privilege, while the Service account has this privilege because it is very common for services to impersonate users. Installing a new service requires the user be a trusted account, such as an administrator.

You should test your application thoroughly if it uses impersonation.

Note that this privilege only applies when quality of security is set to impersonate or delegate (for example, RPC_C_IMP_LEVEL_IMPERSONATE and RPC_C_IMP_LEVEL_DELEGATE). It is not enforced for anonymous or identify (for example, RPC_C_IMP_LEVEL_ANONYMOUS and RPC_C_IMP_LEVEL_IDENTIFY). In addition, your code can always impersonate the process identity whether the account has this privilege or not. In other words, you can always impersonate yourself.