Page 2 of 2 <12
Topic Options
#86326 - 2002-06-27 08:40 PM Re: remote execution
BrianTX Offline
Korg Regular

Registered: 2002-04-01
Posts: 895
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

Top
#86327 - 2002-06-27 11:25 PM Re: remote execution
BrianTX Offline
Korg Regular

Registered: 2002-04-01
Posts: 895
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 ]

Top
#86328 - 2002-06-28 04:36 PM Re: remote execution
jtokach Offline
Seasoned Scripter
*****

Registered: 2001-11-15
Posts: 513
Loc: PA, USA
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 ]
_________________________
-Jim

...the sort of general malaise that only the genius possess and the insane lament.

Top
#86329 - 2002-06-28 04:42 PM Re: remote execution
BrianTX Offline
Korg Regular

Registered: 2002-04-01
Posts: 895
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 ]

Top
#86330 - 2002-06-28 05:17 PM Re: remote execution
jtokach Offline
Seasoned Scripter
*****

Registered: 2001-11-15
Posts: 513
Loc: PA, USA
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]
_________________________
-Jim

...the sort of general malaise that only the genius possess and the insane lament.

Top
#86331 - 2002-06-28 05:38 PM Re: remote execution
BrianTX Offline
Korg Regular

Registered: 2002-04-01
Posts: 895
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

Top
#86332 - 2002-06-28 05:41 PM Re: remote execution
jtokach Offline
Seasoned Scripter
*****

Registered: 2001-11-15
Posts: 513
Loc: PA, USA
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.
_________________________
-Jim

...the sort of general malaise that only the genius possess and the insane lament.

Top
#86333 - 2002-06-28 05:51 PM Re: remote execution
BrianTX Offline
Korg Regular

Registered: 2002-04-01
Posts: 895
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 ]

Top
#86334 - 2002-06-28 06:06 PM Re: remote execution
jtokach Offline
Seasoned Scripter
*****

Registered: 2001-11-15
Posts: 513
Loc: PA, USA
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]
_________________________
-Jim

...the sort of general malaise that only the genius possess and the insane lament.

Top
#86335 - 2002-06-28 06:10 PM Re: remote execution
BrianTX Offline
Korg Regular

Registered: 2002-04-01
Posts: 895
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

Top
#86336 - 2002-06-28 06:17 PM Re: remote execution
jtokach Offline
Seasoned Scripter
*****

Registered: 2001-11-15
Posts: 513
Loc: PA, USA
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 ]
_________________________
-Jim

...the sort of general malaise that only the genius possess and the insane lament.

Top
#86337 - 2002-06-28 06:35 PM Re: remote execution
BrianTX Offline
Korg Regular

Registered: 2002-04-01
Posts: 895
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

Top
#86338 - 2002-06-28 06:51 PM Re: remote execution
jtokach Offline
Seasoned Scripter
*****

Registered: 2001-11-15
Posts: 513
Loc: PA, USA
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


_________________________
-Jim

...the sort of general malaise that only the genius possess and the insane lament.

Top
#86339 - 2002-06-28 08:13 PM Re: remote execution
BrianTX Offline
Korg Regular

Registered: 2002-04-01
Posts: 895
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

Top
#86340 - 2002-06-28 10:56 PM Re: remote execution
jtokach Offline
Seasoned Scripter
*****

Registered: 2001-11-15
Posts: 513
Loc: PA, USA
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]
_________________________
-Jim

...the sort of general malaise that only the genius possess and the insane lament.

Top
#86341 - 2002-07-01 03:09 PM Re: remote execution
BrianTX Offline
Korg Regular

Registered: 2002-04-01
Posts: 895
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

Top
Page 2 of 2 <12


Moderator:  Shawn, ShaneEP, Ruud van Velsen, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Mart 
Hop to:
Shout Box

Who's Online
0 registered and 557 anonymous users online.
Newest Members
gespanntleuchten, DaveatAdvanced, Paulo_Alves, UsTaaa, xxJJxx
17864 Registered Users

Generated in 0.068 seconds in which 0.026 seconds were spent on a total of 13 queries. Zlib compression enabled.

Search the board with:
superb Board Search
or try with google:
Google
Web kixtart.org