Why does the notepad process run in background ?
Vikas
I have a VB Script that *should* ideally trigger off a notepad on the
foregound/interactive (i.e Notepad should pop up on the remote
machine) - The script successfully triggers the notepad application on
the remote machine but the notepad runs only in the background
(visible in the Task Manager) .... What do I need to do in order to
make it run in the foreground ???
I did go through many postings in related groups and have checked for
all possible conditions.... Below is the list of things I checked.
Pls. let me know if anything is missing..
(1)- For starters, I have domain admin rights on the remote machine.
:)
(2)- The remote machine (where the notepad should ultimately pop up)
is a XP Pro 2002 with SP1 .... The Local machine (where I run the
script) is a Windows 2000 Pro with SP2. (I had SP3 but removed it as I
believe SP3 disallows remote interactive apps)
(3)- Remote Desktop is enabled in the System Properties of the XP
machine.
(4)- Firewall option is diabled on the XP machine
(5)- XP is part of a domain and not a workgroup.
(6)- ForceGuest value is 0 in
HKEY_LOCAL_MACHINE\SYSTEM\Current-Control-Set\Control\LSA
(7)- Guest Account is disabled on the XP box
(8)- In "Local Security Policy", I have chenged the Network Access
from *Guest Only* to *Classic*
(9)- I log on as Domain User on Local Machine (W2K) and
Administrator on Remote Machine (XP)
(10)- Both the amchines have Windows Script Host Version 5.6 running
Thanks,
Vikas
Marty List
You included everything but the kitchen sink, and the details of your code.
- Are you using the Win32_Process.Create method?
- What impersonation level are you using?
"Vikas" <vik...@eudoramail.com> wrote in message
news:b07d3d92.03041...@posting.google.com...
[MS] Scott McNairy
gets created to be interactive instead of Win32_Process post Win2k Service
Pack 3 Server release. It is a security feature to have it non-interactive.
--
[MS] Scott McNairy
WMI Test Engineer
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
"Vikas" <vik...@eudoramail.com> wrote in message
news:b07d3d92.03041...@posting.google.com...
Vikas
The script works well if I run it from the XP machine (i.e XP is the
local machine and W2K is the remote machine) ... Why does the same
script behave differently in XP environment ????? BTW, the script runs
well when locally on XP ....
For your ref, I am sending the script (below) ...
From the command line I run it like this ...
C:\>CScript Script.vbs 10.10.10.100 notepad c:\
'****************************************************
' Script.vbs
Dim oInPar 'object representing input parameters of the method
Dim oOutPar 'object representing output parameters of the method
sComputer = WScript.Arguments(0)
sCmdLine = WScript.Arguments(1)
sCurDir = WScript.Arguments(2)
Set locator = CreateObject("WbemScripting.SWbemLocator")
Set context = CreateObject("WbemScripting.SWbemNamedValueSet")
Set service = locator.ConnectServer(sComputer, "ROOT\CIMV2",
"10.10.10.100\administrator", "admin")
service.security_.ImpersonationLevel = 3
service.Security_.AuthenticationLevel = 6
Set oProcess = service.Get("Win32_Process")
Set oMethod = oProcess.Methods_("Create")
Set oInPar = oMethod.inParameters.SpawnInstance_()
oInPar.CommandLine = sCmdLine
oInPar.CurrentDirectory = sCurDir
Set oOutPar = oProcess.ExecMethod_("Create", oInPar)
If oOutPar.ReturnValue = 0 Then
WScript.Echo oOutPar.ReturnValue
WScript.Echo "Create process method completed successfully"
WScript.Echo "New Process ID is " & oOutPar.ProcessId
Else
WScript.Echo oOutPar.ReturnValue
WScript.Echo "Create process method failed"
End If
'****************************************************
Thanks,
Vikas
"Marty List" <Bill....@sun.com> wrote in message news:<b76mgu$bpemg$1...@ID-172409.news.dfncis.de>...
Vikas
Is Win32_ScheduledJob equilvalent to the AT command ?? My requirement
is to run the script as and when required (ad-hoc)..... in other
words, I don't want to schedule this script based on time, day etc
.........
Isn't there way of making this script behave that way thru'
Win32_ScheduledJob ???
Thanks,
Vikas
"[MS] Scott McNairy" <sco...@online.microsoft.com> wrote in message news:<3e970343$1...@news.microsoft.com>...
Torgeir Bakken (MVP)
> The script works well if I run it from the XP machine (i.e XP is the
> local machine and W2K is the remote machine) ... Why does the same
> script behave differently in XP environment ?????
Hi
It works against your Win2k computer because it is running SP2. If you install SP3, your script will
stop
to "work", because as you wrote in your first post, SP3 disallows remote interactive apps (just as WinXP
has done from day 1). This is done for security reasons.
--
torgeir
Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scriptcenter
Vikas
Now that I have accepted the fact that remote process cannot run in
the interactive mode on a remote (Win2K SP3 or Win XP), I am wondering
what else can be done in order to make it work. I believe there are
certain products in the market that achieve this kind of
functionality.
For example, "Remote Exec" from ISDecisions achieves this ... I have
successfully opened the notepad !!! You can download an evaluation
copy and try it out too ... The URL is
http://www.pnltools.com/productinfo.asp?productid=70
My undersanding of the product is this ...
1) On running with the necessary input, it "copies" the
RemoteExecAgent.exe (the actual app.) from the source m/c to the
remote m/c (this .exe now resides in C:\WINNT\system32 folder on both
the machines)
2) Then pops up the notepad on the remote machine be it W2K SP3 or Win
XP !!
This "RemoteExecAgent.exe" seems to be running on the TaskManager of
the remote machine till the notepad app. is running.. If one closes
the notepad, the RemoteExecAgent.exe also ends.
How is he able to do this .. Any ideas ??? Is there some other
technology (other than WMI Scripts) that can be used to achieve this
???
Thanks,
Vikas
vik...@eudoramail.com (Vikas) wrote in message news:<b07d3d92.03041...@posting.google.com>...
Mike Smith
--Mike
"Torgeir Bakken (MVP)" <Torgeir.B...@hydro.com> wrote in message
news:3E986056...@hydro.com...
[MS] Scott McNairy
this issue, and it isn't a good workaround either in that the process that
gets created runs in the context of the system as opposed to the user.
The closest you can come is to use Win32_scheduledJob to run at a very near
point in the future based on the Now() function and possibly using
SWbemDateTime interface to get the UTC datetime that the method expects.
--
[MS] Scott McNairy
WMI Test Engineer
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
"Vikas" <vik...@eudoramail.com> wrote in message
news:b07d3d92.03041...@posting.google.com...
Mathieu Paquette
running on the foreground ? I don't get that.
I mean, if I can start a process on a remote machine, be it in the
background or the foreground, it means that I have the credentials to start
a process on the machine, so I can compromise it anyway, foreground or
background. And as Scott McNairy explained, you could trick the system with
ScheduledJob, getting the process to start automatically, but needing that
the Task Scheduler be enabled, which itself can be a potential security
threat too anyway.
I don't get it.
Now I'm sad, because I was trying to write a simple WMI script that started
our remote admin server software on the remote machine (radmin by Famatech)
then starts the viewer on the local machine to connect to it. But heck, I
can't because the process starts in the background, therefore I cannot
connect to it.
Damn !
Mathieu
"Mike Smith" <do...@haveone.com> wrote in message
news:esCWUB1A...@TK2MSFTNGP11.phx.gbl...
Torgeir Bakken (MVP)
> Yeah ? And how is a process running in background is more secure than one
> running on the foreground ? I don't get that.
>
> I mean, if I can start a process on a remote machine, be it in the
> background or the foreground, it means that I have the credentials to start
> a process on the machine, so I can compromise it anyway, foreground or
> background. And as Scott McNairy explained, you could trick the system with
> ScheduledJob, getting the process to start automatically, but needing that
> the Task Scheduler be enabled, which itself can be a potential security
> threat too anyway.
>
> I don't get it.
Hi
From a previous thread that discussed this issue, with examples on how both the
local and the remote user can be the "bad" guy/girl:
From: Ivan Brugiolo [MS] (ivan...@online.microsoft.com)
Subject: Re: Win32_Process, create process
Newsgroups: microsoft.public.win32.programmer.wmi
Date: 2002-06-23 11:36:07 PST
<quote>
Just imagine 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.
</quote>
From: Ivan Brugiolo [MS] (ivan...@online.microsoft.com)
Subject: Re: Win32_Process, create process
Newsgroups: microsoft.public.win32.programmer.wmi
Date: 2002-06-24 07:21:43 PST
<quote>
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.
</quote>
Mathieu Paquette
Thanks...
Mathieu
"Torgeir Bakken (MVP)" <Torgeir.B...@hydro.com> wrote in message
news:3EA5C833...@hydro.com...
Eric Paschoalick Chaves
I'm taking the thread on the run, but I'm facing the same situation here and
share the same option (at least partial) of Mathieu. The security risk IMO
is because of User1 having credentials to start an application on the
interactive desktop, but he'll probably could harm the system in other ways,
because this should be a privileged credential. So I really don't consider
this to be an "effective" security measure. This could be easily solved by
placing a security permission on the file/folder (like those
read/execute/traverse flags) that indicate if the file could be remotly
opened/executed in the interactive desktop. Also, the system may
impersonating the logged user on the interactive desktop when running the
application,ie, if the User1 start explorer.exe on the windows desktop of
User2, explorer.exe will run on the context of user2, just like if he
started it by itself.
Cheers,
Eric
Daniel Pravat [MSFT]
good reasons to restrict this. The same user can start a process, attach
(debug)
to the shell process, impersonate it, set the workstation to the
interactive one
and call CreatePRocessAsUser.
One other exception can be when a remote user SID match the shell user SID.
Other than that you should not be able to start anything in the interactive
station.
--
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
"Eric Paschoalick Chaves" <.eric.pas...@gradiente.com> wrote in message
news:eoqBz99...@TK2MSFTNGP12.phx.gbl...