Validating User Accounts (Impersonation)

• Microsoft Win32 Application Programming Interface (API) included with:

      - Microsoft Windows NT versions 3.1, 3.5, and 3.51
  

SUMMARY

Some applications need the ability to execute processes in the context of another user. This impersonation restricts (or expands) the permissions of the account in which the application was executed (file access, permission to change system time, permission to shut down the system, and so forth).

For example, an administrator executes a network server program that allows remote users to log on to the system and perform actions, as if they were logged on to the system locally. Because the administrator initiated the server program and is currently logged on, all actions the server program performs will be in the security context of the administrator. If a guest user logs on remotely, he/she will have all the permissions the administrator account has.

With the Win32 API under Windows NT 3.1 and 3.5, impersonating a remote client is possible only via the ImpersonateDDEClientWindow(), ImpersonateNamedPipeClient() and RpcImpersonateClient() APIs.

Windows NT 3.51 introduces new Win32 APIs (Logon Support APIs) to deal with this problem:

   LogonUser
   ImpersonateLoggedOnUser
   CreateProcessAsUser

MORE INFORMATION

For versions of Windows NT prior to 3.51

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 to a remote host and have the host impose all restrictions of the client login account.

If the daemon is using named pipes, dynamic data exchange (DDE), or a remote procedure call (RPC) (using the named pipes transport), the client account may be impersonated on the server daemon, which will impose all the restrictions of the client's user account.

Using other network interfaces (such as Windows sockets--network programming interfaces), security cannot be monitored by the system. A workaround would be to impose password-level security on "login" to the application. The passwords would be maintained by the application in a private accounts database. However, none of the user actions are performed in the security context of the actual client user's account. Therefore, after the server/daemon has validated the client, the server must be careful to only perform actions on behalf of the client that the server knows the client should be allowed to do.

Another option is to create a network share with restricted access. The WNetAddConnection2() API can verify access to this system resources [disk or printer network resource (share)]. If the network share was set up to allow access by a restricted group of people, the WNetAddConnection2() could validate actual user accounts, maintained by Windows NT. As with the previous option, the daemon must be careful to perform only restricted actions on behalf of the client. This option could be used for file server daemons.