After days of messing about, I have finally founf the magic incantations
that make this work. The scenario is a common one:
DCOM delegation is needed for the following WMI scenario when creating
processes on remote machines using programs that reside on a network share
on a third machine:
A -> B -> C
where machine A runs the WMI perl script that connects to machine B and then
uses Win32_Process->Create to run a program or accesses network resources
located on a share on machine C. The WMI connection needs to use "delegate"
impersonation, kerberos authentication of the form "<AD domain>\<machine B
name>". Machines A and B must be marked "Trusted for delegation" in AD Users
and Computers snap-in. The user account that is running the script on
machine A (or that is named in the connection to machine B in the WMI API)
must be domain admin and must not be marked "Account is sensitive and called
be delegated" in AD users and computers snap-in. The requirement for being
domain admin is because the security on root\cimv2 by default requires this.
You could alter the security on this (WMI control in computer management) on
machine B to allow non-admins to connect, but this might not be a good idea
security-wise.
So, the code running on A is simply this (using the machine names above and
AD domain "DOMAIN"):
--------
#!/bin/perl
use Win32::OLE;
$program = "\\\\C\share\someprogram.exe";
$wd = "\\\\C\share";
$WMIProc=Win32::OLE->GetObject("winmgmts:{impersonationLevel=delegate,author
ity=kerberos:DOMAIN\
\B}!\\\\B\\root\\cimv2:Win32_Process") || die "Couldn\'t get WMI Process
handle for machine $machine\n";
print "Executing \"$program\" on machine B ... ";
$result = $WMIProc->Create($program,$wd,undef,$pid);
if ($result) {print "*** ERROR: $result ***\n";} else {print "OK- PID:
$pid\n";}
-----------------
NOTES
----------
I can't get $pid to return anything but blank - anybody know why?
I have had *a lot* of trouble running that as the default domain admin user
on A. I'm still pursuing this with MS. As the built-in domain admin account
for the win2k AD domain, this reliably fails on some machines with error 8
("unknown error"). This is very odd because all of my XP clients are
identical. I created a user, gave them domain admin rights and used RunAs to
start the script on A. Works fine.
Default WMI authorisation level is "Packet" for XP, "Connection" for W2k
(start wbemtest.exe on one of each and notice the radio buttons, bottom
right). This can cause trouble if, for example, trying to alter the WMI
control properties of an XP machine remotely from a win2k machine. This may
be fixed in W2k SP3, apparently.
PK
--
Dr Philip Kime
Tel/Fax: +44 (0)131 552 0732
[EMAIL PROTECTED] - http://www.kime.org.uk/PK
_______________________________________________
Perl-Win32-Admin mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
