INFO: Validating User Accounts (Impersonation) (96005)
The information in this article applies to:
- Microsoft Win32 Application Programming Interface (API), when used with:
- the operating system: Microsoft Windows NT 3.1
- the operating system: Microsoft Windows NT 3.5
- the operating system: Microsoft Windows NT 3.51
- the operating system: Microsoft Windows XP
This article was previously published under Q96005 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 and Windows XP, 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 INFORMATIONFor 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.
Modification Type: | Major | Last Reviewed: | 4/13/2004 |
---|
Keywords: | kbinfo kbKernBase kbSecurity KB96005 |
---|
|