|
|
|||||||
hahahahahhahahahahahah got it... No error checking yet, but here is the basics. code:rmtexec("notepad.exe","wheelerc_2nd") |
||||||||
|
|
|||||||
rad, you are MAD! |
||||||||
|
|
|||||||
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: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.Function RemoteRun ($RemoteCommand, Optional $RemoteStartDir, Optional $ComputerName, Optional $AdminName, Optional $AdminPassword, Optional $NameSpace) Thanks |
||||||||
|
|
|||||||
anyone know what those addl parameters in the create statement are? |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
Why is it necessary to specify the PID?... Brian |
||||||||
|
|
|||||||
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? |
||||||||
|
|
|||||||
If you like, I'll whip up a script that can check what userid a process is running under.. then you can check it. Brian |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
vbs code: code:{fixed.. should work now}set wmiobj=GetObject("winmgmts:") Brian [ 26 June 2002, 21:53: Message edited by: BrianTX ] |
||||||||
|
|
|||||||
This looks vaguely familar - http://cwashington.netreach.net/depo/wmifaq/execution_of_a_remote_command.htm HTH, Kent |
||||||||
|
|
|||||||
BrianTX, Does that VBS code work for you? It does not work for me. |
||||||||
|
|
|||||||
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 ] |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
Yes!!!! Thanks for the help. |
||||||||
|
|
|||||||
Ok.. I've been fiddling with this.. gotten some more progress.. anyone care to try this? code:Brian$computer = "@WKSTA" |
||||||||
|
|
|||||||
Duh.. this is easier than I thought.. Now I got the PID and owner and process startup options all in one script. code:Brian$computer = "@WKSTA" |
||||||||
|
|
|||||||
Actually, I figured this out: In my previous script: code:Is the line I couldn't get to work right.. well, according to Microsoft:$ProcStartInst.ShowWindow = 1 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.. 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 ] |
||||||||
|
|
|||||||
Shawn, I think you are being shunned... 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 ] |
||||||||
|
|
|||||||
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!) 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 ] |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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 ] |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
Sorry, I'm one post behind you! 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 ] |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
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: |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
Indeed it is my friend! 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... |
||||||||
|
|
|||||||
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 |