This article was previously published under Q96005
This article has been archived. It is offered "as is" and will no longer be updated.
Some applications need the ability to execute processes in the context ofanother user. This impersonation restricts (or expands) the permissions ofthe account in which the application was executed (file access, permissionto change system time, permission to shut down the system, and so forth).
For example, an administrator executes a network server program that allowsremote users to log on to the system and perform actions, as if they werelogged on to the system locally. Because the administrator initiated theserver program and is currently logged on, all actions the server programperforms will be in the security context of the administrator. If a guestuser logs on remotely, he/she will have all the permissions theadministrator account has.
With the Win32 API under Windows NT and Windows XP, impersonating a remoteclient is possible only via the ImpersonateDDEClientWindow(),ImpersonateNamedPipeClient() and RpcImpersonateClient() APIs.
Windows NT 3.51 introduces new Win32 APIs (Logon Support APIs) to deal withthis problem:
A common application of impersonation is network server programs (daemons).For example, a remote login daemon needs a user to be able to to log in toa remote host and have the host impose all restrictions of the client loginaccount.
If the daemon is using named pipes, dynamic data exchange (DDE), or aremote procedure call (RPC) (using the named pipes transport), the clientaccount may be impersonated on the server daemon, which will impose all therestrictions of the client's user account.
Using other network interfaces (such as Windows sockets--networkprogramming interfaces), security cannot be monitored by the system. Aworkaround would be to impose password-level security on "login" to theapplication. The passwords would be maintained by the application in aprivate accounts database. However, none of the user actions are performedin the security context of the actual client user's account. Therefore,after the server/daemon has validated the client, the server must becareful to only perform actions on behalf of the client that the serverknows the client should be allowed to do.
Another option is to create a network share with restricted access. TheWNetAddConnection2() API can verify access to this system resources [diskor printer network resource (share)]. If the network share was set up toallow access by a restricted group of people, the WNetAddConnection2()could validate actual user accounts, maintained by Windows NT. As with theprevious option, the daemon must be careful to perform only restrictedactions on behalf of the client. This option could be used for file serverdaemons.