Impersonation

[Chris Koiak]

Hi,

Is it possible to contain impersonation to a given AppDomain rather than
impersonation consuming the full process?

I have a service running under the local system account, but need to
impersonate the current user for some functionality (e.g. accessing the
current users network share). However I don't want the full service to
change it's access rights. I can spawn a seperate process (which
impersonates a specifed user) but this therefore consumes more memory.

My service needs to run as the Local System account (not a specified account
particular to the domain).

Any ideas?

Thanks
Chris

 

[richlm]

Impersonation happens at the thread level.
If you impersonate on the main thread, you are effectively impersonating the
process.
But if you spawn a new thread (System.Threading) and impersonate there, your
main thread should remain in the original context.
As far as I know you can't do this directly by appdomain.

Hope this helps.
Richard.

 

[Willy Denoyette [MVP]]

This is not true, when impersonating, only the calling thread (whatever
thread that may be) uses the impersonating security token, you can never
change the process security context once a process is started.

Willy.

 

[richlm]

Yes - I agree. Thanks Willy! That sentence 'If you impersonate on the main
thread...' is totally wrong/misleading.
The main thread gets the identity of the process initially; if you
impersonate on the main thread only the main thread - not the process -
impersonates.

Chris - it just occurred to me you are expecting a user to be logged on -
but a service can be running with no user logged on (or >1 user remotely on
a server).
Would another design perspective be to start a separate process when the
user logs on (which will automatically run in the context of the user) and
have that communicate with the service? That way you don't have to fiddle
around with trying to impersonate the logged-on user from your windows
service.

Richard.