> UserName = GetTheUserNameFromSocket();
> UserSid = LookupAccountName(UserName);
> EnablePrivilege(SeCreateTokenPrivilege);
> hToken = NtCreateToken(UserSid,UserGroup,UserPrivilege);
> DisablePrivilege(SeCreateTokenPrivilege);
> SetThreadToken(hToken);
> CreateProcess("notepad.exe");
> RevertToSelf();

> the book "Windows NT/2000 Native API Reference" has a sample of
> NtCreateToken.
> All others are published APIs.
> --
> This posting is provided "As Is" with no warranties, and confers no
rights.
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm

> "Garfield Lewis" <gale...@ca.ibm.com> wrote in message
> news:uQXRUXuoCHA.1644@TK2MSFTNGP10...
> > Are there any examples of NtCreateToken I cannot find any reference to
it
> on
> > the MSDN website?

> > All I want to be able to do is write an rsh daemon (I do not want/wish
to
> > rewrite the client side rsh command) that will accept the command stream
> > that is sent to it and do the work in the context of the client. That
> means
> > I do not have write any special rsh command that will open secure
channels
> > and send passwords. The rsh daemon should accept the stream in the
> > recognized rsh format which I think still is:

> > [stderr port] [remote user] [local user] [command]

> > After recieving this the rsh daemon would send a null string to client
to
> > acknowledge recieving the request. It then runs the command under the
> > context of the user and returns the result (success or failure). The
> > question is how (without a password) would I be able to get the user's
> > context? If NtCreateToken can do this then great but how?

> > --
> > Garfield A. Lewis
> > DB2 UDB Development,
> > IBM Canada Laboratory

> > "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in message
> > news:u0I2J2koCHA.1532@tkmsftngp02...
> > > NtCreateToken offers you the "su" capabilities, with no Logon Session.
> > > You can create a primary token just starting from a SID.

> > > the SAMBA folks are able to authenticate to a Windows IPS$ "share",
> > > it means that they have an SSPI "implementation",
> > > because srv.sys uses SSPI-server side to authenticate your network
logon
> > > credentials.

> > > the official "su" for windows is runas.exe,
> > > that, as you pointed out, requires passwords.

> > > You can always create a "secure channel" a-la-SSL to just transmit the
> > > password on the other side,
> > > so that the "daemon" can do a
> CreateProcessWithLogon/CreateProcessAsUser.

> > > I will not even go to the topic of discussing the security
ramifications
> > of
> > > 'su',
> > > and all the exploits based on the 'suid' bit.

> > > --
> > > This posting is provided "As Is" with no warranties, and confers no
> > rights.
> > > Use of included script samples are subject to the terms specified at
> > > http://www.microsoft.com/info/cpyright.htm

> > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message
> > > news:u1wrNmkoCHA.2084@TK2MSFTNGP12...
> > > > The goal of RSH is to execute the command in the context of the
client
> > so
> > > > unless the client can be impersonated (local or remote) then you
will
> be
> > > > running under the contest of the local system or whatever account
you
> > use
> > > to
> > > > login your rshd service ("daemon").

> > > > SSPI is all well and good in a Windows only environment (even though
I
> > > doubt
> > > > that the rsh.exe that is shipped with Windows is written using SSPI,
> in
> > > fact
> > > > I am pretty sure of it). But the reality is most companies/customers
> run
> > > > multiple platforms (AIX, Windows, Linux, ... and on and on). So how
> > would
> > > a
> > > > non-Windows client accomplish a rsh request?

> > > > It would be nice if one had the ability to su on Windows as on UNIX.
> So
> > > that
> > > > if you are running in the context of the system (root) you can login
> as
> > > (or
> > > > get the context of) a user without a password and have full control.
> > Then
> > > a
> > > > rshd could be written that does the job without needing a password
for
> > the
> > > > client requestor.

> > > > --
> > > > Garfield A. Lewis
> > > > DB2 UDB Development,
> > > > IBM Canada Laboratory

> > > > "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in
> message
> > > > news:ODIhPWjoCHA.2292@tkmsftngp02...
> > > > > You can write RSH if you have a "daemon" process with the
> > > > > SeCreatePrimaryToken privilege,
> > > > > but the created token would belong to the system logon session,
and
> > the
> > > > > token would have
> > > > > no chance to do much apart from the local machine.

> > > > > The phylosophically correct approach would be to use SSPI
> > > > > to correclty create the identity of the remote account in the
local
> > > > machine.
> > > > > There would be no password transmission.
> > > > > The API to look at would be InitialzieSecurityContext on the
> > > client-side,
> > > > > followed by a chain of AcceptSecurityContext on the server side.
> > > > > When the negotiation has happened, the Server would call
> > > > > ImpersonateSecurityContext.
> > > > > If the SSPI is going to use Kerberos as the authentication
package,
> > > > > then you can even delegate the credentials of the remote user.

> > > > > --
> > > > > This posting is provided "As Is" with no warranties, and confers
no
> > > > rights.
> > > > > Use of included script samples are subject to the terms specified
at
> > > > > http://www.microsoft.com/info/cpyright.htm

> > > > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message
> > > > > news:e3M0u8hoCHA.2328@TK2MSFTNGP11...
> > > > > > This is an interesting answer, how would one then write a
> compliant
> > > RSH
> > > > > > daemon on Windows without first knowing the password of every
> > possible
> > > > > user
> > > > > > who could run a rsh command against it? Remember that rsh its
> > requests
> > > > in
> > > > > a
> > > > > > specific format and a password is not part of this data stream.

> > > > > > Just a thought...

> > > > > > --
> > > > > > Garfield A. Lewis
> > > > > > DB2 UDB Development,
> > > > > > IBM Canada Laboratory

> > > > > > "Egbert Nierop (MVP for IIS)" <egbert_nie...@nospam.com> wrote
in
> > > > message
> > > > > > news:e$WbDOcoCHA.2188@TK2MSFTNGP09...
> > > > > > > "Yoshiki" <yosh...@wanaROOdooDOO.fr> wrote in message
> > > > > > > news:uXwrZDYoCHA.2360@TK2MSFTNGP09...
> > > > > > > > Hi,

> > > > > > > > Does anybody know a way to impresonate a process which is
> > running
> > > > > under
> > > > > > > > the SYSTEM account to an other account for which the process
> > > doesn't
> > > > > > > > know the password ?

> > > > > > > This is *not* possible, if it were, windows-hell broke... the
> idea
> > > of
> > > > > > having
> > > > > > > passwords on a system would be voided.

> > > > > > > > (Sorry if it's not the right place to ask my question. If
not,
> > > > please
> > > > > > > > tell me where I can do it :-)

> > > > > > > > Thanks a lot !

> > > > > > > > Antoine.