Radimus
(KiX Supporter)
2002-06-26 03:34 PM
remote execution

hahahahahhahahahahahah

got it... No error checking yet, but here is the basics.

code:
rmtexec("notepad.exe","wheelerc_2nd")
? @error @serror

;****************************************************************************************************
FUNCTION RMTEXEC($cmd, $computer, optional $pid)
dim $rmt, $exec
if not $pid $pid=999 endif

$rmt = GetObject("winmgmts:{impersonationLevel=impersonate}!\\$computer \root\cimv2:Win32_Process")
$exec = $rmt.Create($cmd,,,$pid)

exit @error
ENDFUNCTION



LonkeroAdministrator
(KiX Master Guru)
2002-06-26 03:36 PM
Re: remote execution

rad, you are MAD!

krabourn
(Hey THIS is FUN)
2002-06-26 06:49 PM
Re: remote execution

Good Job!

Looks like we started this one about the same time.

This is mine. I have to be able to login to WMI on some workstations.

code:
Function RemoteRun ($RemoteCommand, Optional $RemoteStartDir, Optional $ComputerName, Optional $AdminName, Optional $AdminPassword, Optional $NameSpace)
Global $RemoteProcessPid
If Not $ComputerName Or $ComputerName = ''
$ComputerName = @Wksta
EndIf
If $NameSpace = ''
$NameSpace = 'root\cimv2'
EndIf
$SystemLocator = CreateObject ('WbemScripting.SWbemLocator')
$SystemSet = $SystemLocator.ConnectServer($ComputerName, $NameSpace, $AdminName, $AdminPassword)
If @Error <> 0
$WMIQuery = ''
Exit @Error
EndIf
$SystemSet.Security_.ImpersonationLevel = 3
$ObjProcesses = $SystemSet.Get('Win32_Process')
$ObjProcessIns = $ObjProcesses.Methods_('Create').InParameters.SpawnInstance_
$ObjProcessIns.CommandLine = $RemoteCommand
If $RemoteStartDir And $RemoteStartDir <> ''
$ObjProcessIns.CurrentDirectory = $RemoteStartDir
EndIf
$ObjProcessOut = $SystemSet.ExecMethod('Win32_Process', 'Create', $ObjProcessIns)
If @Error = 0
$RemoteProcessPid = $ObjProcessOut.processid
Else
$RemoteProcessPid = ''
EndIf
Exit $ObjProcessOut.returnvalue
EndFunction

Have you tried finding out who the owner of the process is (GetOwner)? I have not been able to get the use and domain from it. It just returns zero.

Thanks


Radimus
(KiX Supporter)
2002-06-26 06:51 PM
Re: remote execution

anyone know what those addl parameters in the create statement are?

**DONOTDELETE**
(Lurker)
2002-06-26 06:59 PM
Re: remote execution

Try,
GetOwnerSid Method in Class Win32_Process

See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/getownersid_method_in_class_win32_process.asp


ShawnAdministrator
(KiX Supporter)
2002-06-26 07:20 PM
Re: remote execution

Rad, addl parameters ? You mean like ProcessStartupInformation ? We were playing with that in that Remote Execution Driving Me Insane thread ... Can create a blank Win32_ProcessStartup object, then datafill with startup parameters, like window attributes, process priority, etc ... then pass to Create, I guess.

BrianTX
(Korg Regular)
2002-06-26 07:57 PM
Re: remote execution

Why is it necessary to specify the PID?...

Brian


krabourn
(Hey THIS is FUN)
2002-06-26 07:59 PM
Re: remote execution

Let me restate what I am looking for.

I am trying to determine what user name and domain the process ($ObjProcessOut) that I just created is running under.

I would assume it is running as the account that I used to log into WMI. That account has administrative rights.

Does anyone know what account the new process is running under?


BrianTX
(Korg Regular)
2002-06-26 08:04 PM
Re: remote execution

If you like, I'll whip up a script that can check what userid a process is running under.. then you can check it. [Smile]

Brian


krabourn
(Hey THIS is FUN)
2002-06-26 08:07 PM
Re: remote execution

Thanks.

I think, I just need the syntax.

I get a zero back for @Error, but I don't know how to access the user and domain part.


ShawnAdministrator
(KiX Supporter)
2002-06-26 08:08 PM
Re: remote execution

As per that "Remote Execution driving me insane" thread. The remote process "appears" to be running with your WMI credentials (eg, if you look in XP taskmgr on remote machine, your accountid is attached to the process). But, because of some limitations with NTLM challenge response - the process on the remote machine DOES NOT really have full network rights. If you need to access a remote share - have to map it with username & password supplied.

From reading the literature. This is an basic Windows NT problem, and affects not just WMI, but other things such as remote TELNET sessions.

My two cents. Sorry if not much help in furthering the cause. Might want to inverstigate further.


BrianTX
(Korg Regular)
2002-06-26 08:16 PM
Re: remote execution

I'm getting the same thing.. going to have to fiddle around with this getting userid/domain stuff. For some reason KiXtart doesn't like returning info into variables in a method.

Brian


BrianTX
(Korg Regular)
2002-06-26 08:47 PM
Re: remote execution

vbs code:

code:
set wmiobj=GetObject("winmgmts:")
set procobj = wmiobj.ExecQuery("Select * From Win32_Process Where Name = 'iexplore.exe'")
For each Process in procobj
RetVal = Process.GetOwner(struser,strdomain)
wscript.echo struser
wscript.echo strdomain
Next

{fixed.. should work now}

Brian

[ 26 June 2002, 21:53: Message edited by: BrianTX ]


Kdyer
(KiX Supporter)
2002-06-26 09:00 PM
Re: remote execution

This looks vaguely familar - http://cwashington.netreach.net/depo/wmifaq/execution_of_a_remote_command.htm

HTH,

Kent


krabourn
(Hey THIS is FUN)
2002-06-26 09:24 PM
Re: remote execution

BrianTX,

Does that VBS code work for you? It does not work for me.


BrianTX
(Korg Regular)
2002-06-26 09:51 PM
Re: remote execution

Let me fix it.. it was working a minute ago.. lol
{edit}
Ok.. works for me now.. I was fiddling with it and posted the "fiddling" code instead of the code that works.

Brian

[ 26 June 2002, 21:54: Message edited by: BrianTX ]


BrianTX
(Korg Regular)
2002-06-26 11:17 PM
Re: remote execution

This frustrates me:

Methods cannot set OUTput parameter variables in KiXtart. Has ANYONE gotten this to work? I'm willing to concede I may not have the syntax right, but I have tried several different ways without success.

Brian


BrianTX
(Korg Regular)
2002-06-27 12:00 AM
Re: remote execution

I think we can safely say (unless someone has proof to the contrary) that KiXtart does not support OUT parameters for object methods.. is this something I should add to the suggestion box, or is this a bug?

Brian


krabourn
(Hey THIS is FUN)
2002-06-27 03:54 PM
Re: remote execution

Yes!!!! [Smile]

Thanks for the help.


BrianTX
(Korg Regular)
2002-06-27 04:28 PM
Re: remote execution

Ok.. I've been fiddling with this.. gotten some more progress.. anyone care to try this?

code:
$computer = "@WKSTA"
$uName = ""
$upass = ""
$namespace = "root\cimv2"
$command = "c:\winnt\system32\cmd.exe"
$sysloc = CreateObject("WbemScripting.SWbemLocator")
$sysset = $sysloc.ConnectServer($computer, $namespace, $uname, $upass)
$sysset.Security_.ImpersonationLevel = 3


$objProcStart = $sysset.Get("Win32_ProcessStartup")
$ProcStartInst = $objProcStart.SpawnInstance_
$ProcStartInst.Title = "Hi, How are you?"
$ProcStartInst.ShowWindow = 1 ; this part doesn't seem to work right.
$procStartInst.Put_


$objProc = $sysset.Get("Win32_Process")
$objProcInst = $ObjProc.Methods_("Create").InParameters.SpawnInstance_
$objProcInst.CommandLine = $command
$objProcInst.ProcessStartupInformation = $ProcStartInst
$objProcOut = $sysset.ExecMethod("Win32_Process","Create",$objProcInst)
$pid = $objProcOut.Processid
"PID used is: " + $pid

Brian


BrianTX
(Korg Regular)
2002-06-27 08:40 PM
Re: remote execution

Duh.. this is easier than I thought.. [Smile] Now I got the PID and owner and process startup options all in one script.

code:
$computer = "@WKSTA"
$uName = ""
$upass = ""
$namespace = "root\cimv2"
$command = "c:\winnt\system32\cmd.exe"
$sysloc = CreateObject("WbemScripting.SWbemLocator")
$sysset = $sysloc.ConnectServer($computer, $namespace, $uname, $upass)
$sysset.Security_.ImpersonationLevel = 3

$objProcStart = $sysset.Get("Win32_ProcessStartup")
$ProcStartInst = $objProcStart.SpawnInstance_
$ProcStartInst.Title = "Hi, How are you?"
$ProcStartInst.ShowWindow = 1 ; this part doesn't seem to work right.
$procStartInst.Put_

$objProc = $sysset.Get("Win32_Process")
$objProcInst = $ObjProc.Methods_("Create").InParameters.SpawnInstance_
$objProcInst.CommandLine = $command
$objProcInst.ProcessStartupInformation = $ProcStartInst
$objProcOut = $sysset.ExecMethod("Win32_Process","Create",$objProcInst)
$pid = $objProcOut.Processid
$owner = $sysset.Get("Win32_Process=$pid").ExecMethod_("GetOwner")

"Process " + $pid + " was created by " + $owner.domain +
"\" + $owner.user + "."

Brian


BrianTX
(Korg Regular)
2002-06-27 11:25 PM
Re: remote execution

Actually, I figured this out:

In my previous script:

code:
$ProcStartInst.ShowWindow = 1 

Is the line I couldn't get to work right.. well, according to Microsoft:

ShowWindow
Data type: uint16
Access type: Read/write

How the window is to be displayed to the user.

Value Meaning
1 SW_HIDE
2 SW_NORMAL
3 SW_SHOWMINIMIZED
4 SW_SHOWMAXIMIZED
5 SW_SHOWNOACTIVATE
6 SW_SHOW
7 SW_MINIMIZE
8 SW_SHOWMINNOACTIVE
9 SW_SHOWNA
10 SW_RESTORE
11 SW_SHOWDEFAULT
12 SW_FORCEMINIMIZE
.............

After playing with this, I learned the different modes work, but not the same way:
Value Meaning
0 SW_HIDE
1 SW_NORMAL
2 SW_SHOWMINIMIZED
3 SW_SHOWMAXIMIZED
4 SW_SHOWNOACTIVATE
5 SW_SHOW
6 SW_MINIMIZE
7 SW_SHOWMINNOACTIVE
8 SW_SHOWNA
9 SW_RESTORE
10 SW_SHOWDEFAULT

So, I can see some new and improved UDF's coming along.. [Smile]

Brian

{edit}
I'm still playing with the WinstationDesktop string. A blank string "" should set it to the currently logged on user... but not sure, yet.

[ 27 June 2002, 23:39: Message edited by: BrianTX ]


jtokach
(Seasoned Scripter)
2002-06-28 04:36 PM
Re: remote execution

Shawn, I think you are being shunned... [Smile]

As Shawn stated above, there doesn't seem to be anything new here.

Remote Execution

Also look at the wshPIPE() and the 23rd post of this thread.

[ 28 June 2002, 16:43: Message edited by: jtokach ]


BrianTX
(Korg Regular)
2002-06-28 04:42 PM
Re: remote execution

Naw.. I'm not shunning Shawn. I'm just fiddling around with the Win32_ProcessStartup. I don't remember it being demonstrated before... OR the owner of a process. (I know.. it's probably too easy for you to waste your time displaying it every time you figure out how something new works, but others of us are still figuring this out!) [Smile]

After looking at the WSHPipe and the thread you mentioned, I notice it is probably easier to do it with WSH, however, there may be some functionality this way that isn't included in that method - that's what I'm looking for. -- With the method above, I can specify WHERE I want the Window, the dimensions, etc. The WSH .run method does not include those options.

Brian

[ 28 June 2002, 17:01: Message edited by: BrianTX ]


jtokach
(Seasoned Scripter)
2002-06-28 05:17 PM
Re: remote execution

I wouldn't say it’s necessarily easier, the methodology is the same. It seems as though there may be additional functionality. In either case there's a lot of value and potential here. We're stuck however when it comes to network access through the remote box, which consequentially makes remote access through WMI very limited in scope; granted this a feature that PSEXEC.EXE and similar programs have.

Also, I haven't touched Win32_ProcessStartup b/c I thought it was only available to XP clients?

BTW, the previous was not directed at you. More so at stating that the original subject of this thread had already been writen and well documented in another thread. [Wink]


BrianTX
(Korg Regular)
2002-06-28 05:38 PM
Re: remote execution

Ahh. ok.. well, I'm glad it wasn't directed at me. lol.. the Win32_ProcessStartup is available on my Win2k as well. (I don't know for sure if it is by default because I've installed the .NET framework and all that rot from Microsoft.) ..

Brian


jtokach
(Seasoned Scripter)
2002-06-28 05:41 PM
Re: remote execution

Brian I see value there, however, unless you can change the owner of the process to be the current user, that process will run under the context of the user who's id was used to logon and impersonate.

This can be demonstrated by executing "cmd /c start /w winword.exe"

The problem here is that whatever you launch runs under the context of an admin's ID and potentially a Domain Admin. This can be demonstrated by logging on the remote box as a non-admin and running the remote execute with cmd /k as the process. I think that will allow the non-admin interactive access to the DOS window under your context, thereby allowing them admin access to any server.


BrianTX
(Korg Regular)
2002-06-28 05:51 PM
Re: remote execution

That's true, however if you're talking about a setup program, then it should run that program with the remote user's rights, so that you can install a program remotely. I wouldn't open a CMD.EXE on a remote computer with admin rights. This is just for testing purposes...

Brian

{edit}
I wonder if this would be of any help:

http://msdn.microsoft.com/library/en-us/wmisdk/wmi/setting_the _default_process_security_level_using_vbscript.asp
or
http://msdn.microsoft.com/library/en-us/wmisdk/wmi/setting_the_authentication_type_using_vbscript.asp

[ 28 June 2002, 18:04: Message edited by: BrianTX ]


jtokach
(Seasoned Scripter)
2002-06-28 06:06 PM
Re: remote execution

That's still a problem, b/c the current user portion of the software will install as you and not the remote user. You would need to package the CU and LM portions of the software seperately in order for that to work. This is why the other post has the suffix ...driving me insane. [Smile]

BrianTX
(Korg Regular)
2002-06-28 06:10 PM
Re: remote execution

Yes.. hmm. have you read about "cloaking"? It looks interesting in response to something Shawn said about permissions on a remote PC doing something (or not doing something) over the network.

Brian


jtokach
(Seasoned Scripter)
2002-06-28 06:17 PM
Re: remote execution

Sorry, I'm one post behind you! [Smile]

Anyhow, as far as setting the authority, I've tested everything. What I think will work is setting the authority to Delegate thereby aloowing pass-through. Unfortunately this requires Kerberos... I've also played with the security. Security in this case defines the transmission security/encryption. I think both of these were covered in the other post? Can't remember...

Anyhow, look up impersonate, connectserver, reverttoself and cosetproxy in the SDK and MSDN on WMI.

Some combination of these will most likely work, but most of these methods/classes are not available to Kix (I think), which is why I though maybe VBS may work...

Cloaking is related to one of the above, and again, I don't think its accessible by kix. This has both Shawn and I puzzled...

[ 28 June 2002, 18:20: Message edited by: jtokach ]


BrianTX
(Korg Regular)
2002-06-28 06:35 PM
Re: remote execution

Hmm. I'm puzzled, too. You can set the security of the object by:

$systemset.Security_.ImpersonationLevel = 3
$systemset.Security_.AuthenticationLevel = 6

Why wouldn't this work?

Brian


jtokach
(Seasoned Scripter)
2002-06-28 06:51 PM
Re: remote execution

B/c authentication simply verifies to the remote WMI provider you are who you say you are. It does not allow for proxy pass-through authentication or redirection. In this case the transmission between the two will be encrypted at the RPC level.

Also, here's the quote from the other post on NTLM:

quote:
Shawn,

LOL! I've been down that road already! I didn't want to bring it up in fear that I would be laughed off the board!

Here's our problem... I tried setting the $RCommand to "cmd /c net use z: \\server\share /persistent:no & pause" and sure enough... System Error 1312

This MSKB describes and also hints towards delegation. Unfortunately, without kerberos, this is worthless.

This is beginning to look like an exercise in futility...

quote:
--------------------------------------------------------------------------------


When you use Telnet to map a drive letter to a network share, the procedure may not work and the following error message may be displayed:

A specified logon session does not exist. It may already have been terminated.
NOTE : This problem does not affect Telnet sessions for which the user authentication method is clear text.

CAUSE
This issue occurs when you open a Telnet session to a computer running Windows NT Server using the NTLM authentication method. You cannot then, from within the Telnet session, connect to network resources using your implied user credentials. You must explicitly specify your credentials when making network connections from within the Telnet session.

There is no mechanism in Windows NT to perform delegation of security (pass through) for network logon attempts.

For example, if you log on to the network using NTLM from computer A to computer B, and then type "net use" at a command prompt to connect to computer C from computer B, the connection is not made. The reason is that computer B has an incomplete user token (it does not have your password), so the logon attempt to computer C does not work. This behavior is rooted in NTLM being a challenge/response protocol, and as such, it avoids sending your password across the network.

--------------------------------------------------------------------------------

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q214726




BrianTX
(Korg Regular)
2002-06-28 08:13 PM
Re: remote execution

This is tricky business, it appears. It may be possible to access network resources using runas (I would guess it can be done) from the API, but as to the security of doing so, I'm not sure. Playing with the "Delegate" impersonation level may work, but this seems like a pain!

Brian


jtokach
(Seasoned Scripter)
2002-06-28 10:56 PM
Re: remote execution

Indeed it is my friend! [Smile] I didn't think runas could take the password at the command line? Either way, even with SU, you would need the user's password to run under their context...

I think we'll find it, eventually... [Big Grin] [Big Grin] [Big Grin]


BrianTX
(Korg Regular)
2002-07-01 03:09 PM
Re: remote execution

If you set the winstationdesktop property of win32_processstartup, you get the process to run on the desktop of the user that created the process remotely. If you do not specify, it runs on the desktop of the currently logged on user.... Haven't tested how the permissions work out, yet.

Brian