Impersonation (fairly simple I thought)

  • Thread starter Thread starter Rob Bolton
  • Start date Start date
R

Rob Bolton

Hi there,

If a program running under the interactive logon session (say Susan), needs
to impersonate Bob (via "LogonUser()"), but Bob needs to access the network
as Susan (i.e., his local credentials will be his own, but his network
credentials will be Susan's), is there anyway to do this? The problem seems
to rest with the fact that Bob needs Susan's cleartext password to invoke
any of the appropriate functions but he can't get it - this despite the fact
that Susan has been interactively logged on and simply wants to hand off her
network credentials to him. Any help would be greatly appreciated. Thanks.
 
Rob Bolton said:
Thanks for the reply but it doesn't answer my question :)
Click to expand...

That's because your question wasn't very clear. What are you
doing with the token returned from LogonUser? If you start a process
with this token then this is not "impersonation". Impersonation
is when a thread is assigned its own token (normally threads don't
have their own tokens and use the process token).

If you have a process running as Bob then to access network as Susan
Bob needs to somehow obtain a token for Susan (or her password, but
this is probably not a good idea).

There are several ways to get the token. For example, the parent
process could pass a copy of its own token to the child using handle
inheritance. Or the child could open a named pipe, have the parent
connect to it, and then do ImpersonateNamedPipeClient.
 
That's because your question wasn't very clear.

Maybe you're right (more details would have been better) but I normally try
to keep my posts brief. I think the question was sufficiently clear enough
however that a response such as "try to call RevertToSelf()" was simplistic
at best :)
What are you doing with the token returned from LogonUser?
Click to expand...

The interactive logon session (Susan) needs to impersonate Bob via
"ImpersonateLoggedOnUser()" (or any other relevant function) whereby all of
Bob's *local* activity will run under his credentials. However, when making
any outbound (network) calls, authentication must occur under the
credentials of the interactive logon session instead (Susan's). It's easy
enough to get the token of the interactive logon session but not their
password of course. Therefore, since all relevant functions seem to require
a clear-text password (read on), how can I make use of that token? That is,
how can I pass Susan's credentials to Bob so he can use them to access the
network (given that I only have Susan's token but not her password). Note
(FYI) that Bob simply needs to read a shared network directory but doesn't
have appropriate rights to it. Susan does so her credentials are therefore
required to access it. To accomplish this, Bob could normally just invoke
"NetUseAdd()" to connect to that share by passing Susan's credentials
instead of using his own (by filling in a USE_INFO_2 structure with Susan's
credentials and passing it to "NetUseAdd()"). He needs her password for this
however but doesn't have it nor can the interactive user (Susan) get hold of
it apparently. I'm therefore trying to figure out how to pull off the same
thing without the password. It should be doable I would think given that
Susan is already interactively logged on (she typed her password in already)
and simply wants to hand her cached credentials to Bob so he can use them to
access the network (and for no other purpose).
 
If you control the code that accesses the network share then you
can call RevertToSelf() before doing this, then impersonate again.

If you don't control that code then you might be out of luck. Looks
like you need something like the reverse of LOGON32_LOGON_NEW_CREDENTIALS,
and I suspect that there is no way to do that.
 
If you control the code that accesses the network share then you
can call RevertToSelf() before doing this, then impersonate again.

If you don't control that code then you might be out of luck. Looks
like you need something like the reverse of LOGON32_LOGON_NEW_CREDENTIALS,
and I suspect that there is no way to do that.
Click to expand...

I don't control the code that access the network unfortunately (it's
3rd-party) and I'm beginning to think you're right. The prospects of finding
a solution are looking grim. Thanks for your assistance anyway.
 
Back
Top