How to impersonate without password

[Yoshiki]

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 ?

(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.

[CheckAbdoul]

Are you looking for ImpersonateLoggedOnUser() API ?

--
Cheers
Check Abdoul [ VC++ MVP ]
-----------------------------------

"Yoshiki" <yos...@wanaROOdooDOO.fr> wrote in message
news:uXwrZDYoCHA.2360@TK2MSFTNGP09...

[Ivan Brugiolo [MSFT]]

Do you have a piece of code runing as LocalSystem,
and this piece of code happens to have the server side of a named-pipe or
LPC-port ?
If yes, then you can call ImpersonateNamedPipeClient /
NtImpersonateClientOfPort.

If you have an RPC / DCOM server, you can call
RpcImpersonateClient/CoImpersonateClient.

If your client is wishing to partecipate to an authentication protocol,
then you can use SSPI and get the client token via
ImpersonateSecurityContext.

If you have code running as LocalSystem, you can always use NtCreateToken
to generate a token for a given user, but that token will belong to
practically no logon session,
and it would not be much useful in real world.

What are you trying to accomplish ?

--
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

"Yoshiki" <yos...@wanaROOdooDOO.fr> wrote in message
news:uXwrZDYoCHA.2360@TK2MSFTNGP09...

[Egbert Nierop (MVP for IIS)]

"Yoshiki" <yos...@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.

[Garfield Lewis]

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...@nospam.com> wrote in message
news:e$WbDOcoCHA.2188@TK2MSFTNGP09...

[Ivan Brugiolo [MSFT]]

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" <gal...@ca.ibm.com> wrote in message
news:e3M0u8hoCHA.2328@TK2MSFTNGP11...

[Garfield Lewis]

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]" <ivan...@online.microsoft.com> wrote in message
news:ODIhPWjoCHA.2292@tkmsftngp02...

[Ivan Brugiolo [MSFT]]

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" <gal...@ca.ibm.com> wrote in message

news:u1wrNmkoCHA.2084@TK2MSFTNGP12...

[Garfield Lewis]

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]" <ivan...@online.microsoft.com> wrote in message

news:u0I2J2koCHA.1532@tkmsftngp02...

[Ivan Brugiolo [MSFT]]

The code prototype would be:

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" <gal...@ca.ibm.com> wrote in message

news:uQXRUXuoCHA.1644@TK2MSFTNGP10...

[Pavel Lebedinsky]

If the intent of this code is to start notepad as the user
whose name was obtained from the socket, then it should
be using CreateProcessWithTokenW or CreateProcessAsUser.

Creating a process while impersonating is almost always
a bug. It creates a process with the same token as the
parent process, but the security descriptor for the new process
is copied from the impersonated user's token. Which results
in all kinds of interesting security problems when the new
process tries to use its own handle (GetCurrentProcess()).

[Ivan Brugiolo [MSFT]]

Good remarks.
The purpose of the conversation was about how to obtain the Token,
and not about the ramifications of creating a process with a given token.
Sorry about that.

--
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

"Pavel Lebedinsky" <m_pll at hotmail dot com> wrote in message
news:3dfe6b07$1...@news.microsoft.com...

[Ziv Caspi]

On Sat, 14 Dec 2002 01:05:05 -0800, "Ivan Brugiolo [MSFT]"
<ivan...@online.microsoft.com> wrote:

>The code prototype would be:
>
>UserName = GetTheUserNameFromSocket();
>UserSid = LookupAccountName(UserName);

[...]

I know this is not the "interesting" part of the code sample you gave;
however, I think it needs stressing out that in most cases the client
cannot be trusted (certainly in the rsh example that started this
thread). If so, the server should not rely on the client telling the
server its identity without some kind of validation. That's why your
previous advice (establish a secure channel with the client and have
it pass a username/password through it) is the one people should be
using.

Ziv

[Ivan Brugiolo [MSFT]]

I known SSPI and/or SChannel is the only correct way of doing it,
but the originator of the thread had a different opinion on the subject.
He/She will have to deal with his/her security breaches,
but he/she has been warned.

--
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

"Ziv Caspi" <zi...@netvision.net.il> wrote in message
news:3e042c09.26906749@newsvr...

[Benjamin R Heath]

I don't know if this subject is dead yet or not, but I have some comments
and a new problem. It seems like you can create a primary token with
zwCreateToken that can be used in CreateProcessAsUser(). This can be done
without a password. The process seems to have the save security as the user
used to create the token. I can share a code sample if you like, but it's
pretty much the same as the code example from "Windows NT/2000 Native API
Reference" by Gary Nebbett.

The new problem I have is that I would like to be able to call this from
Java. So I need to do this all from a JNI DLL. Whenever I try to do this I
get an access violation. I can get zwCreateToken to work in a standalone
program just fine. If I try to use it in a regular DLL (not a Java JNI DLL)
I get an access violation as well. The only thing I can figure is that the
kernel might be getting screwed up by memory allocated within a DLL versus a
stand alone program, but how can I fix it?

Thanks for any suggestions.

Ben

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message

news:#NKynnapCHA.2308@TK2MSFTNGP10...

[Ivan Brugiolo [MSFT]]

The NtCreateToken API takes a non trivial ammount of hard-to-marshal params.
Now, I'm at all familiar with the requirements of the IN/OUT param of a
function
for it to be called from JNI, but I would recomend making
all the complex strutures of that function to be contiguous in memory
(no constellation of allocations at all), and possibly making them to live
on the stack.

--
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

"Benjamin R Heath" <benjamin...@yahoo.com> wrote in message
news:IRDP9.131$mg5....@news.uswest.net...