Re: Can't get something basic to work (WMI)

• Previous message: Rob Bolton: "Re: Can't get something basic to work (WMI)"
• In reply to: Ivan Brugiolo [MSFT]: "Re: Can't get something basic to work (WMI)"
• Messages sorted by: [ date ] [ thread ]

Date: Sun, 18 Apr 2004 21:40:00 +0200

Hello Ivan and All,

thanks a lot for the clarification. Better, in the future, I'll write:

just a note from a person, which will never understand DCOM in all details
and also security ;-)

I have had never a chance currently to work with w2k/AD/kerberos until now
[said to say]. For NT4/W2K in a NT4-domain, my solution works very well. If
the remote process uses a DCOM component, which is installed on that remote
machine and which is configured to run in the context of the interactive
user and if there is someone logged on - what should be determined before
instantiating this component - the remote process can display messages on
the WinSta0, the interactive workstation. That was, what I mainly wanted to
explain.

I use a WSC component, which - in turn - instantiates Internet Exploer,
which is the display. So I am flexible and can just put any message onto the
screen of the user. This is [D]COM. And this will surely work in all
security contexts [w2k/kerberos], because it has nothing to do with it.

For networking, I prefer to copy necessary files by pushing them to the
remote machine, before they are needed, for example, an installation packet.

Thanks so far and
best regards,
Manfred

"Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> wrote in message
news:u1%23hKOXJEHA.2904@TK2MSFTNGP09.phx.gbl...
> This has nothing to do with DCOM, but with the security packages in the
SSPI
> infrastructure,
> of which DCOM, like RPC and the very same rdbss.sys / srv.sys
> (where the SMB/CIFS protocols are implemented) are just plain clients.
>
> the NTLM Authentication Package does not allow delegation,
> while Kerberos does. This is the only essence of the problem.
> Attempting to delegate impersonated credentials from NTLM
> will end up in the usage of the Null-Session, that is on average forbidden
> in many well administered networks.
>
> Delegation is a feature of networks with a W2K or greater
> authenticaiton infrastructure provided by Active Directory.
>
> The process created by WIn32_Process.Create on the remote machine
> will NOT be created under the LocalSystem account.
> If will be created under the account making the call.
> It will be created in the "Service-0x0-3e7$" WindowsStation,
> that is not the "Winsta0" windowstation.
> This makes the process to appear invisible.
> One more thing about the net-use commands is the fact that
> the shares are "local" to a logon session (in WinXP and above),
> and thus they are desighed to not contaminate each other.
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> Use of any included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>
> "Manfred Braun" <aa@bb.cc> wrote in message
> news:eECbuRVJEHA.2904@TK2MSFTNGP09.phx.gbl...
> > Hi,
> >
> > just a note from a person, which will never understand DCOM in all
> details,
> > but ....
> >
> > The process, you create, is running on the remote box under the
> > <LocalSystem> account, which has no network access rights. The
credentials
> > specified, are only used to check, if the calling user [which requests
the
> > creation of the remote process] is allowed to do this. You could write a
> > small cmd or vbs, which simply waits for, say a minute, and then go to
the
> > taskmanager of this machine and you'll see the process running.
> >
> > As an administrator, I found this behavior always very annoying and
there
> > seem to be no simple way in the MS world to solve this problem.
> > Additionally, you are not able to display something on the screen for
the
> > same reason.
> >
> > What helps:
> >
> > Create two separate components, I've done that for experimental purposes
> > only, so, please don't ask for the code, it is too muddy to become
> > published. One component to display a message on the screen, one to do
a
> > network connection. Install this components, I'v cretaed them in script
> > [.wsc], on the remote box. In the component management, configure the
> > component, which displays the message, to run under the interactive
user.
> > Configure the second component to run under a well-known admin account,
> > which you are able to control. Write a script, which instantiates the
> > network-component and store this script onto the remote box. Execute
this
> > script with your remote connection via WMI and it will work.
Additionally,
> > this way you can start a second script, which instantiates the
> > display-component and shows some message to the logged-on user, if any.
> >
> > You can do all this things locally and export the components via
> > component-services as MSI files. This MSI files in turn can be installed
> > remotely via WMI.
> >
> > Hope, this leads you into the right direction.
> >
> > Best regards,
> > Manfred Braun
> >
> > (Private)
> > Mannheim
> > Germany
> >
> > mailto:_manfred.braun_@manfbraun.de
> > (Remove the anti-spam-underscore to mail me!)
> >
> > "Rob Bolton" <_nospam@_nospam.com> wrote in message
> > news:eeujDvTJEHA.2412@TK2MSFTNGP12.phx.gbl...
> > > Thanks very much. I just started learning WMI so haven't studied
> scripting
> > > yet. Will spend some time deciphering this and try again. BTW (for my
> own
> > > information), is this the generally recommended way of doing it? I
> > followed
> > > the (fairly short C++) example at the following link which appears to
be
> > > more mainstream (I could be wrong):
> > >
> > >
> http://www.codeguru.com/Cpp/W-P/system/processesmodules/article.php/c2831/
> > >
> > > BTW, please feel free to get technical if required (I'm experienced).
> > > Thanks.
> > >
> > > "Jiachuan Wang [MSFT]" <jiawang@online.microsoft.com> wrote in message
> > > news:%23S7mxDKJEHA.2572@TK2MSFTNGP12.phx.gbl...
> > > > try the following script.
> > > >
> > > >
> > > > Function ProcessCreate(Server, cmd)
> > > >
> > > > Dim process, processid, nRet
> > > >
> > > >
> > > >
> > > > If Server = "" THEN
> > > >
> > > > SET process =
> > > >
> > >
> >
>
GetObject("WinMgmts:{impersonationLevel=impersonate}!/root/cimv2:Win32_Proce
> > > > ss")
> > > >
> > > > ELSE
> > > >
> > > > SET process =
> > > > GetObject("WinMgmts:{impersonationLevel=impersonate}!//" & Server &
> > > > "/root/cimv2:Win32_Process")
> > > >
> > > > End IF
> > > >
> > > > nRet = process.Create(cmd, null, null, processid)
> > > >
> > > > If (nRet <> 0) Then WScript.Quit nRet
> > > >
> > > > SET process = Nothing
> > > >
> > > > End Function
> > > >
> > > >
> > > >
> > > > If WScript.Arguments.Count <> 2 Then
> > > >
> > > > WScript.Echo "Usage: cscript " & WScript.ScriptName & "
> > server
> > > > command"
> > > >
> > > > WScript.Quit 1
> > > >
> > > > End If
> > > >
> > > >
> > > >
> > > > On Error Resume Next
> > > >
> > > > ProcessCreate WScript.Arguments(0), WScript.Arguments(1)
> > > >
> > > > If Err Then
> > > >
> > > > WScript.Quit Err.Number
> > > >
> > > > Else
> > > >
> > > > WScript.Quit 0
> > > >
> > > > End If
> > > >
> > > >
> > > > --
> > > > This posting is provided "AS IS" with no warranties, and confers no
> > > rights.
> > > >
> > > >
> > > > "Rob Bolton" <_nospam@_nospam.com> wrote in message
> > > > news:%236wZUvBJEHA.3576@tk2msftngp13.phx.gbl...
> > > > > Hi there. I need to run a application on a remote machine and
> > apparently
> > > > WMI
> > > > > is the only convenient way of doing it (can't find anything in the
> > > native
> > > > > APIs that is). However, after trying to master the basics of
> > > > "Win32_Process"
> > > > > today by simply running "xcopy.exe" for now (on the remote
machine),
> I
> > > > seem
> > > > > to have everything set up correctly but nothing is being copied. I
> get
> > > no
> > > > > errors in fact and the event log on the remote machine even shows
> many
> > > > > entries associated with my connection (note that I'm in the local
> > > > > administrator's group on the remote machine). Can anyone provide
> some
> > > > > assistance (no .NET please). Thanks.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

• Previous message: Rob Bolton: "Re: Can't get something basic to work (WMI)"
• In reply to: Ivan Brugiolo [MSFT]: "Re: Can't get something basic to work (WMI)"
• Messages sorted by: [ date ] [ thread ]