hope someone can help me.
I am creating a new process on a remote workstation by
calling the following VB code:
Set objProcess = Services.Get("Win32_Process")
Set objStartup = Services.Get("Win32_ProcessStartup")
Set objConfig = objStartup.SpawnInstance_
objConfig.ShowWindow = SHOW_NORMAL
Result = objProcess.Create("""" & txtRemoteCommand
& """", Null, objConfig, ProcessID)
If I run notepad.exe it works no problem on the
workstation I'm logged onto.
If I run it on a remote workstation (using a services =
locator.connectserver) the process runs but is hidden.
The SDK doco does say for XP and .NET it will run hidden
however I am under the impression that:
Set objStartup = Services.Get("Win32_ProcessStartup")
Set objConfig = objStartup.SpawnInstance_
objConfig.ShowWindow = SHOW_NORMAL
Will make it visible, but this does not appear to be the
case. How do I make this process visible on the remote
workstation?
Thanks
Since the process is created in the Services windowstation,
even if you make the window visible in that windowstation\desktop,
you will never see the window in the *interactive* windowstation.
Just immagine the security implications of opening a program remotely
on somebody else interactive windowstation.
If you spawn explorer.exe for User1 in the interactive windowstation of
User2,
you can induce User2 to think it's its own copy of explorer.exe,
and you can track it's activities, install message hooks,
get its password by faking the UI of the prompt-for-credentials.
--
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
"Simon Manners" <bci...@hotmail.com> wrote in message
news:126ca01c21a9c$26e33500$35ef2ecf@TKMSFTNGXA11...
Kibitzing on this thread...
This seems to be a repeated question here as well in scripting groups, primarily
for administrative purposes.
I can see why this is not a standard part of the present WMI core. Not only
would it take a lot of counter-intuitive addition/hacking to the core services
(as well as an extended security model) but it would also be a guaranteed
Achilles Heel for Windows security initially.... and many of us who have asked
for this functionality would be griping about the problems.
That said, what about some method for allowing a session or user to "take
ownership" of a currently running process and switch its windowstation? I
understand that may introduce another set of issues, but allowing proactive
"pull" of a process somehow might be a safer workaround.
"Ivan Brugiolo [MS]" <ivan...@online.microsoft.com> wrote in message
news:#8HsaRuGCHA.1600@tkmsftngp12...
>.
>
The same change that are in WindowsXP are beeing
considered to be released together with W2K SP3.
(and please re-read the disclaimer at the end, especially the 'confer no
rights' part)
--
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
"Simon Manners" <bci...@hotmail.com> wrote in message
news:fa6801c21b12$bdca2ca0$37ef2ecf@TKMSFTNGXA13...
Now these objects are secured in a default way to prevent
User1 from opening windows in User2 desktop,
reading its clipboard, it's atom table, installing a hook, ecc, ecc.
What would you regard a reasonable administrative action ?
would something like the following pseudo-code be reasonable ?
pWin32_WinstaDesktop =
pWbemSerices->Get("Win32_WinStaDesktop.Session=1,NameSta='winsta0',NameDeskt
op='default'");
pWin32_WinstaDesktop.LowerSecurityForUser("InjectedUser","ALL_PERMISSION");
pWin32_ProcessEx = pWbemSerices->Get("Win32_ProcessEx");
pWin32_ProcessEx->Create("notepad.exe",pWin32_WinstaDesktop);
pWin32_WinstaDesktop->RestoreOriginalPermission();
You would create a window of time where the WinSta\Desktop are
"unprotected".
How would you synchronize the death of "notepad.exe" with the restoration of
the original permission ?
Who is liable of closing notepad.exe ?
How would you make User1 participant/responsible for allowing User2 to
interact with its desktop ?
Would you make this a system-level feature or a WinMgmt supported hack that
changes
on the fly security of kernel objects since it's running as LocaSystem by
chance ?
I have way too many concerns in an feature that is prone to be used in the
wong way,
and that does not fit in a reasonable security model.
If admins have to open a program for a user, why not use Remote Assistance ?
--
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
<Alex K. Angelopoulos (MVP)> wrote in message
news:u9VyuowGCHA.2684@tkmsftngp10...
Looking at the "big picture", most of the requests for this kind of capability
come from a situation where a particular application does not allow full
automation. The best resolution to that (from what I can see) seems to be
redesign of applications to allow full automation and/or remote interactivity
following remote launch with the administrator's credentials, instead of
compromising the security model...
"Ivan Brugiolo [MS]" <ivan...@online.microsoft.com> wrote in message
news:erCy#zyGCHA.1604@tkmsftngp09...
Being a Domain Admin I dont see the issue in allowing a
remote process to be created and visible regardless of
who is logged on or not. You are the Administrator and
with that goes a responsibility.
Tough call.
>> >> get its password by Í{ wÀ E 4Rj_"Èr_s° ìo faking
Guys as an Admin I can remotely change registry entries
from any profile, unisnatll software, Install Software,
make changes to the file system, you name it, it can be
done. Thats the purpose or remote Administration and
having the domain privileges to do it.
So...Why is it such an issue to create a process remotely
and if I see fit have it displayed. Given all the things
I can do remotely how does this pose a security threat. I
want to display notepad with a message in it to a user.
Big deal. If I really wanted to I could probably find
another way to do it but I am standardising on WMI
because it is so cool.
>> > "pull" of a process sÍ{ wÀ O Dʲad÷Àaĺ ìV omehow
Moreover, WinMgmt is usable remotely by any authenticated user.
You just need to flip-on the ENABLE_REMOTE bit if the ACL
in the namespace security descriptor.
That's way I was referring to USer1 and User2 in the discussion below,
because it's a matter of faking from USer2 the UI that normally runs under
User1
--
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
"Simon Manners" <bci...@hotmail.com> wrote in message
news:1171001c21b36$af356050$9be62ecf@tkmsftngxa03...
BTW, if you open an interactive application on some users desktop as a
domain admin,
who guarantees you that the user will NOT abuse of that application ?
You open Notepad.exe to leave a message to the user,
and the user uses the open/save-as dialogs to delete/replace all the logon
scripts
on the DC, since he has a process running as a domain admin.
If by any chance this process is, let's say, Word.exe, I can run VBScript
code
as a Domain Admin, maybe using it to grant myself an admin account.
--
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
"Simon Manners" <bci...@hotmail.com> wrote in message
news:faea01c21b35$712741d0$37ef2ecf@TKMSFTNGXA13...
Tough call.
>> >> get its password by ヘ{掫タ E 4Rj_"ネr_ sー �o faking