How does runas with /netonly option work?

[Madz]

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

 

[Skywing]

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.

 

[Madz]

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

 

[Skywing]

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.