- Thread impersonation by a service application.
- Posted by magtag12345@gmail.com on February 15th, 2006
Is there a way to impersonate a thread as the currently logged user and
access files on network under this user's context? This thread belong
to a service running as "system". I do not have the user name or
password. I cannot run my service with the current users previlege as
intent to support fast user switching and things like that.
The problem: my application supposed to display the information about
files that are located on a network mounted drive. My service is not
able to access the files that are on the mounted volumes, fails with
error code "Path not found", but I am sure that the file exist. I guess
this is because the mapped drives are associated with users and my
service runs as system thus it cannot safely identify the right map. I
came to the conclusion that I need to impersonate the current user to
solve the problem. Is that correct? How can I achieve this? Is there
any other perhaps easy route that I can take?
Thanks.
Mag
- Posted by Skywing on February 15th, 2006
Well, you might have a program that interacts with the service, where the
program runs under the logged on users account. Many IPC mechanisms allow
impersonation, like you could use a named pipe request to a user and
impersonate the user to access remote resources.
Be sure that you allow delegation (check your SQOS) or this will may not
work, though.
<magtag12345@gmail.com> wrote in message
news:1140021636.320883.233690@g47g2000cwa.googlegr oups.com...
- Posted by Maxim S. Shatskih on February 15th, 2006
Impersonating threads usually cannot use SMB, since the impersonation
security context is often created in a way which does not provide LSASS with
the user's password.
For instance, if the the token was created from the server side of the SSPI
API (AcceptSecurityContext etc - usual way for RPC and DCOM servers), then
there are major chances that the logon was done by NTLM challenge/response
pair, and the server's LSASS has no user's password - it only has this pair,
which cannot be used for further access to SMB servers.
So, you will need to impersonate the real logon session created by the
password - by LogonUser or such. You can keep the passwords using DPAPI.
Kerberos solves this, but Kerberos is intra-AD-domain only.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
