|
Posted by Skywing on February 10, 2006, 11:34 am
Please log in for more thread options 1. Yes, this should work fine. Be aware that you may need to adjust the
security descriptor on the new token (especially the token default security
descriptor) so that it grants access to the appropriate objects, especially
objects that are created while working under this token. Remember that
while operating under this token, the thread will not have access to any
existing file share associations previously available on Windows XP or
later. Also remember that regardless of its privileges, this thread may
have difficulty initiating a shutdown or logoff through ExitWindowsEx while
impersonating because its LogonId will not match the cached LogonId inside
Winlogon/win32k.sys for the interactive window station.
2. No, there is no network communication done. All this does is tell LSA
that instead of using the credentials it has cached from when it got the
LsaLogonUser() call from Winlogon (or whatever other logon app logged your
session on), it should use the credentials you are giving it right now. No
remote sessions are made until some action is taken that actually uses the
credentials. The whole operation works exactly the same as you would with
default network credentials == local credentials, except that LSA sends a
different username/password/domain to remote servers.
3. Anything that uses the NT security model through LSA should pick up on
this - such as SMB-based file shares and named pipes. IIRC, things that use
a custom protocol and use things like SSPI should see your credentials too
if they are using the default credentials.
> Hi Skywing,
> Thanks for the response. So, if I understand correctly, it creates a
> logon session on the current machine with a similar token to the creator
> user's token *except* that the token contains the network credentials to
> be used in case any remote sessions are to be made using the newly spawned
> process, right?
>
> Now the next couple of questions :-)
>
> - Can I create such a token *without* having to spawn a new process? I
> mean that can I replace my thread token with such a token so that I can
> connect to servers in untrusted domains without having to create trusts
> for the purpose?
> - Are the credentials sent across the wire to create a logon session on
> the remote server? I understand that a logon session with the specified
> user's context needs to be created so that the remote resources are
> accessed accordingly; and that logon cannot happen on the current machine
> as the current machine need not have any trust relationship with the
> domain of the user whose credentials are specified in the runas command.
> - Is the "impersonated" context used for all network accesses?
> Irrespective of whether it is TCP/UDP or SMB?
>
> Thanks in advace,
> Madhu
>
>> It doesn't actually create a remote session.
>>
>> It does create a new logon session (the token gets its own
>> AuthenticationId and all of the normal restrictions associated with a new
>> logon session apply to it, like ExitWindowsEx may not work as you might
>> think and if you are running on Windows XP or later, drive shares from
>> the parent logon session will not be visible).
>>
>> All this function does is replace the *default remote credentials* used
>> if the token is used in conjunction with a remote machine. It doesn't
>> even try to validate the credentials when you call the function, so you
>> could pass a totally invalid username/password/domain and you wouldn't
>> know that anything went wrong until you actually tried to use that token
>> to access some kind of network resource that requires valid credentials.
>>
>>> Hi,
>>> How does runas with a /netonly option create a login session? As per
>>> my understanding, a logon session is not created on the local machine
>>> when a /netonly option is used. Hence, I understand that whenever the
>>> process launched with /netonly option touches any network resource, a
>>> session is made upon that resource with the credentials specified in the
>>> runas command.
>>>
>>> What API/mechanism is used to create such a remote session? I know
>>> CreateProcessAsLogonW with LOGON_NETCREDENTIALS_ONLY option manages
>>> this, but my requirement is to do the similar thing without lauching
>>> another process. I need this so that untrusted domain accounts can be
>>> used to run tasks without requiring a logon and impersonation on my
>>> local machine.
>>>
>>> Thanks in advance,
>>> Madhu
>>>
>>
>>
>
>
|