PSExec: Access denied when using explicit logon

Hello,

I'm having a very strange issue.

I am attempting to remotely run a command; lets call it c:\windows\system32\notepad.exe.


However, I consistently get Access Denied when I am running psexec when logged on as a non-local administrator on the source machine, and a non-local administrator on the target; even when using explicit -u -p to specify a local administrator on the target.

psexec.exe \\SERVER -u domain\remotemachineadmin -p passwordforrma -i 0 -d "c:\windows\system32\notepad.exe"

The user domain\remotemachineadmin is a local administrator on the target machine.

This strikes me as very odd as the purpose of psexec is to assume another user's rights on the target machine.


Note that it doesn't matter if domain\remotemachineadmin is a local administrator on the source machine.  If I log on to the source machine as domain\remotemachineadmin, psexec will run the specified command.


Does anyone have any ideas?


Thanks!


[edit]

I have just verified that adding the user that was previously not a member of the local Administrators group on SERVER allows the stated psexec line to be executed.    Makes no sense.  Am I going to have to use PSExec to use PSExec?


[solution]

below


Edited by branded - 14 January 2009 at 7:31pm

Humm... I'm curious if this is a feature.  I think it may be.

Anyway:

Here's my work around, get ready for the slop:

cpau.exe -u domain\remotemachineadmin -p passwordforrma -ex "psexec.exe \\SERVER -u domain\remotemachineadmin -p passwordforrma -i 0 -d c:\windows\system32\notepad.exe > NUL" -profile -c -hide

-c (close after done)
-hide (hide cpau window)
> NUL (redirects to cmd line NUL to silence output of notepad.exe)

The trick is to change security context (change user) on the local machine and have that user execute the psexec command.  runas doesn't allow you to pipe the password (because you can't handle that feature).

Although, with runas, you would be able to /savecred, which places the password int he local secure password store (which probably can be brute forced and is less secure than piping the password in each time the program is run).


I was really trying to avoid using cpau.  I know an older version of psexec allows you to do what we want, since I had used it as such.

I'm awaiting word back from some people with larger brains than me (although my question may never get answered), so that I can just write my own vbscript.



Edited by branded - 15 January 2009 at 1:11am

I had the same issue with psexec.  I did a packet trace and found the error was a denial of having access to ADMIN$ (the Windows folder share) on the target box.  If you run admin to admin, it works.

Originally posted by j153c    cmdkey.exe /add:<targetname> /user:<username> /pass:<password>    psexec.exe \\<targetname> <remote_command>

Thanks!

In my situation, I had to first change user context to be a user that is a local administrator on the remote machine.  Are you stating that cmdkey will store credentials to be used like this?

I expect that the process may be copied to ADMIN$, but is then executing using DCOM or WMI.


Edited by mbrowndcm - 18 February 2009 at 12:59am