Hi
Am having a problem with an app I wrote to test patch delivery. I
contact a remote PC, and get it to run a patch which is installed on a
server. It works fine if I use psexec for example and I know it's not
NTFS/share-level security at fault - it's readable to everyone which
is usually enough for scheduler or any other usually-not-network-user
to reach it.
I've checked my credentials in my remote session and it says it's
running as "me", but it appears I've lost my network identity.
check.cmd is just basically "dir \\server\share >> c:\log.log 2>&1",
but when called remotely it results in "Access is denied" in the log.
If I change it to "dir c:\ ...", it works fine though. Remember, I'm
calling that batch file on the remote PC. I'm also a domain admin by
the way, and for good measure I've also added myself to the admins
group on my remote test pc.
Here's the code:
Dim options = New ConnectionOptions
options.EnablePrivileges = True
options.Authentication = AuthenticationLevel.Call
options.Impersonation = ImpersonationLevel.Impersonate
Dim scope = New ManagementScope("\\" + pc + "\root\cimv2", options)
scope.Connect()
Dim processClass = New ManagementClass("Win32_Process")
processClass.Scope = scope
Dim inParams = processClass.GetMethodParameters("Create")
Dim startup = New ManagementClass("WIN32_ProcessStartup")
startup.Scope = scope
inParams("CommandLine") = "cmd /c c:\check.cmd"
inParams("ProcessStartupInformation") = startup
Dim outParams = processClass.InvokeMethod("Create", inParams, Nothing)
Debug.WriteLine("CreateProcess returned :" +
outParams("ReturnValue").ToString())
Any that can help with this will earn my undying gratitude and respect
(and a million pounds!)*
Cheers
AW
* offer of prize money will not be honoured :) 22 5323
Per default domain admins have no rights to access WMI on member servers.
You can check and enable this running wmimgmt.msc on the remote server (or
running it on a local machine and connecting to a remote server).
Right click on WMI Control and select properties, in the control properties
dialog click the "security" tab and add the domain admin account to the ACL
list, make sure at least "execute", "read and write" and "remote enable" are
selected.
Willy.
"andrew_webby at hotmail" <an**********@hotmail.com> wrote in message
news:f4************************@posting.google.com ... Hi
Am having a problem with an app I wrote to test patch delivery. I contact a remote PC, and get it to run a patch which is installed on a server. It works fine if I use psexec for example and I know it's not NTFS/share-level security at fault - it's readable to everyone which is usually enough for scheduler or any other usually-not-network-user to reach it.
I've checked my credentials in my remote session and it says it's running as "me", but it appears I've lost my network identity.
check.cmd is just basically "dir \\server\share >> c:\log.log 2>&1", but when called remotely it results in "Access is denied" in the log. If I change it to "dir c:\ ...", it works fine though. Remember, I'm calling that batch file on the remote PC. I'm also a domain admin by the way, and for good measure I've also added myself to the admins group on my remote test pc.
Here's the code:
Dim options = New ConnectionOptions options.EnablePrivileges = True options.Authentication = AuthenticationLevel.Call options.Impersonation = ImpersonationLevel.Impersonate
Dim scope = New ManagementScope("\\" + pc + "\root\cimv2", options) scope.Connect()
Dim processClass = New ManagementClass("Win32_Process") processClass.Scope = scope
Dim inParams = processClass.GetMethodParameters("Create")
Dim startup = New ManagementClass("WIN32_ProcessStartup") startup.Scope = scope
inParams("CommandLine") = "cmd /c c:\check.cmd" inParams("ProcessStartupInformation") = startup Dim outParams = processClass.InvokeMethod("Create", inParams, Nothing)
Debug.WriteLine("CreateProcess returned :" + outParams("ReturnValue").ToString())
Any that can help with this will earn my undying gratitude and respect (and a million pounds!)*
Cheers
AW
* offer of prize money will not be honoured :)
Hi Willy
Thanks for the suggestions. However, I tried adding Domain Admins in where
you suggest and it didn't help.
Although I am a domain admin (and therefore by default in the local
'Administrators' group on the member PCs - which already have the
permissions you suggest), I am actually trying this in two different
configurations. One from WinXP -> WinXP and one from Win2k3 -> WinXP.
My problem doesn't appear to be the accessing/creation/whatever of WMI - I
can create the remote process no problem. It's just when I want that remote
process to access the network that my troubles begin.
Any other suggestions as I'm running a little short on hair here... ;)
AW
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:OV**************@TK2MSFTNGP11.phx.gbl... Per default domain admins have no rights to access WMI on member servers. You can check and enable this running wmimgmt.msc on the remote server (or running it on a local machine and connecting to a remote server). Right click on WMI Control and select properties, in the control
properties dialog click the "security" tab and add the domain admin account to the
ACL list, make sure at least "execute", "read and write" and "remote enable"
are selected.
Willy.
"ms" <andrew_webby@hotmail> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Hi Willy
Thanks for the suggestions. However, I tried adding Domain Admins in where you suggest and it didn't help.
Hi Andrew,
Sorry, should have read your post more carefully.
The problem you have is the famous multiple hop issue when using NTLM
authentication.
The remote process is impersonating "me" (the token obtained is a
impersonation token - no user/password was obtained by this process), that
means you don't have network credentials, and anonymous (I'm not sure this
is the case on W2K3) will be used to access the shared network resource.
One thing you could try is to force Kerberos authentication, and set
ImpersonationLevel.Delegate (so you will have to set
ConnectionOption.Authority = "Kerberos:<principalname>).
But, even that is not guaranteed to work, as WMI is free to reject Kerberos
and fall back to NTLM authentication.
I suggest you enabled auditing on the remote share, that way you can check
which account is used to access the share?
Willy.
Hmm.
I see it's trying to connect to my share as remotepcname$ which is of course
the machine's 'user' account in the domain. So for fun and larks, I gave
access to the PC inquestion at the share/ntfs level but it still won't work.
This would even do for anonymous readonly access to the world if I could get
that to work. I'll see what I can find on the Kerberos side, but so far this
doesn't sound very encouraging.... http://msdn.microsoft.com/library/de...delegation.asp
That seems to be suggesting I would need to mark every client computer in my
domain as Trusted For Delegation - which I'm not really willing to do.
There must be an easier way, surely? A colleague here suggested mapping a
network drive remotely with a username/password and maybe that would clear
up the ID issue - what do you reckon?
Thanks for the top suggestions so far :)
AW
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:u3****************@TK2MSFTNGP10.phx.gbl... "ms" <andrew_webby@hotmail> wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... Hi Willy
Thanks for the suggestions. However, I tried adding Domain Admins in
where you suggest and it didn't help.
Hi Andrew,
Sorry, should have read your post more carefully. The problem you have is the famous multiple hop issue when using NTLM authentication. The remote process is impersonating "me" (the token obtained is a impersonation token - no user/password was obtained by this process), that means you don't have network credentials, and anonymous (I'm not sure this is the case on W2K3) will be used to access the shared network resource. One thing you could try is to force Kerberos authentication, and set ImpersonationLevel.Delegate (so you will have to set ConnectionOption.Authority = "Kerberos:<principalname>). But, even that is not guaranteed to work, as WMI is free to reject
Kerberos and fall back to NTLM authentication.
I suggest you enabled auditing on the remote share, that way you can check which account is used to access the share?
Willy.
Andrew,
I've done some tests myself, and as far I see this can't work, simply
because WMI (actually wmiprvse.exe) launches the command shell (cmd) in the
security context of the impersonated domain account, but it's logon type is
3 (NETWORK), that means its token is obtained by a network logon, so it runs
without network privileges!
Note that Kerberos was used to authenticate the client, but the ticket
obtained by WMI is dropped on the floor when he starts another process.
PS. I'm not clear as why you see machine$ is used to access the share, are
you sure it's not the Logon session event written when wmiprvse.exe is
spawned by svchost.exe?
Willy.
"andrew_webby at hotmail" <andrew_webby@hotmail> wrote in message
news:Or**************@tk2msftngp13.phx.gbl... Hmm.
I see it's trying to connect to my share as remotepcname$ which is of course the machine's 'user' account in the domain. So for fun and larks, I gave access to the PC inquestion at the share/ntfs level but it still won't work.
This would even do for anonymous readonly access to the world if I could get that to work. I'll see what I can find on the Kerberos side, but so far this doesn't sound very encouraging....
http://msdn.microsoft.com/library/de...delegation.asp
That seems to be suggesting I would need to mark every client computer in my domain as Trusted For Delegation - which I'm not really willing to do.
There must be an easier way, surely? A colleague here suggested mapping a network drive remotely with a username/password and maybe that would clear up the ID issue - what do you reckon?
Thanks for the top suggestions so far :)
AW
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message news:u3****************@TK2MSFTNGP10.phx.gbl... "ms" <andrew_webby@hotmail> wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... > Hi Willy > > Thanks for the suggestions. However, I tried adding Domain Admins in where > you suggest and it didn't help. >
Hi Andrew,
Sorry, should have read your post more carefully. The problem you have is the famous multiple hop issue when using NTLM authentication. The remote process is impersonating "me" (the token obtained is a impersonation token - no user/password was obtained by this process), that means you don't have network credentials, and anonymous (I'm not sure this is the case on W2K3) will be used to access the shared network resource. One thing you could try is to force Kerberos authentication, and set ImpersonationLevel.Delegate (so you will have to set ConnectionOption.Authority = "Kerberos:<principalname>). But, even that is not guaranteed to work, as WMI is free to reject
Kerberos and fall back to NTLM authentication.
I suggest you enabled auditing on the remote share, that way you can check which account is used to access the share?
Willy.
Andrew,
I've done some tests myself, and as far I see this can't work, simply
because WMI (actually wmiprvse.exe) launches the command shell (cmd) in the
security context of the impersonated domain account, but it's logon type is
3 (NETWORK), that means its token is obtained by a network logon, so it runs
without network privileges!
Note that Kerberos was used to authenticate the client, but the ticket
obtained by WMI is dropped on the floor when he starts another process.
PS. I'm not clear as why you see machine$ is used to access the share, are
you sure it's not the Logon session event written when wmiprvse.exe is
spawned by svchost.exe?
Willy.
"andrew_webby at hotmail" <andrew_webby@hotmail> wrote in message
news:Or**************@tk2msftngp13.phx.gbl... Hmm.
I see it's trying to connect to my share as remotepcname$ which is of course the machine's 'user' account in the domain. So for fun and larks, I gave access to the PC inquestion at the share/ntfs level but it still won't work.
This would even do for anonymous readonly access to the world if I could get that to work. I'll see what I can find on the Kerberos side, but so far this doesn't sound very encouraging....
http://msdn.microsoft.com/library/de...delegation.asp
That seems to be suggesting I would need to mark every client computer in my domain as Trusted For Delegation - which I'm not really willing to do.
There must be an easier way, surely? A colleague here suggested mapping a network drive remotely with a username/password and maybe that would clear up the ID issue - what do you reckon?
Thanks for the top suggestions so far :)
AW
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message news:u3****************@TK2MSFTNGP10.phx.gbl... "ms" <andrew_webby@hotmail> wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... > Hi Willy > > Thanks for the suggestions. However, I tried adding Domain Admins in where > you suggest and it didn't help. >
Hi Andrew,
Sorry, should have read your post more carefully. The problem you have is the famous multiple hop issue when using NTLM authentication. The remote process is impersonating "me" (the token obtained is a impersonation token - no user/password was obtained by this process), that means you don't have network credentials, and anonymous (I'm not sure this is the case on W2K3) will be used to access the shared network resource. One thing you could try is to force Kerberos authentication, and set ImpersonationLevel.Delegate (so you will have to set ConnectionOption.Authority = "Kerberos:<principalname>). But, even that is not guaranteed to work, as WMI is free to reject
Kerberos and fall back to NTLM authentication.
I suggest you enabled auditing on the remote share, that way you can check which account is used to access the share?
Willy.
I reviewed most of the thread. Did you enable the computer account that is
the WMI Server in Active Directory to be enabled for delegation? Also is
the file share mentioned a part of this Active Directory or one if it's
member servers?
The other steps are also required, enabling kerberos authority and
specifying the delegation on the Impersonation Level.
--
[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
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Andrew, I've done some tests myself, and as far I see this can't work, simply because WMI (actually wmiprvse.exe) launches the command shell (cmd) in
the security context of the impersonated domain account, but it's logon type
is 3 (NETWORK), that means its token is obtained by a network logon, so it
runs without network privileges! Note that Kerberos was used to authenticate the client, but the ticket obtained by WMI is dropped on the floor when he starts another process.
PS. I'm not clear as why you see machine$ is used to access the share, are you sure it's not the Logon session event written when wmiprvse.exe is spawned by svchost.exe?
Willy.
"andrew_webby at hotmail" <andrew_webby@hotmail> wrote in message news:Or**************@tk2msftngp13.phx.gbl... Hmm.
I see it's trying to connect to my share as remotepcname$ which is of course the machine's 'user' account in the domain. So for fun and larks, I gave access to the PC inquestion at the share/ntfs level but it still won't work.
This would even do for anonymous readonly access to the world if I could get that to work. I'll see what I can find on the Kerberos side, but so far this doesn't sound very encouraging....
http://msdn.microsoft.com/library/de...delegation.asp That seems to be suggesting I would need to mark every client computer
in my domain as Trusted For Delegation - which I'm not really willing to do.
There must be an easier way, surely? A colleague here suggested mapping
a network drive remotely with a username/password and maybe that would
clear up the ID issue - what do you reckon?
Thanks for the top suggestions so far :)
AW
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message news:u3****************@TK2MSFTNGP10.phx.gbl... "ms" <andrew_webby@hotmail> wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... > Hi Willy > > Thanks for the suggestions. However, I tried adding Domain Admins in
where > you suggest and it didn't help. >
Hi Andrew,
Sorry, should have read your post more carefully. The problem you have is the famous multiple hop issue when using NTLM authentication. The remote process is impersonating "me" (the token obtained is a impersonation token - no user/password was obtained by this process), that means you don't have network credentials, and anonymous (I'm not sure this is the case on W2K3) will be used to access the shared network
resource. One thing you could try is to force Kerberos authentication, and set ImpersonationLevel.Delegate (so you will have to set ConnectionOption.Authority = "Kerberos:<principalname>). But, even that is not guaranteed to work, as WMI is free to reject Kerberos and fall back to NTLM authentication.
I suggest you enabled auditing on the remote share, that way you can check which account is used to access the share?
Willy.
I reviewed most of the thread. Did you enable the computer account that is
the WMI Server in Active Directory to be enabled for delegation? Also is
the file share mentioned a part of this Active Directory or one if it's
member servers?
The other steps are also required, enabling kerberos authority and
specifying the delegation on the Impersonation Level.
--
[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
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Andrew, I've done some tests myself, and as far I see this can't work, simply because WMI (actually wmiprvse.exe) launches the command shell (cmd) in
the security context of the impersonated domain account, but it's logon type
is 3 (NETWORK), that means its token is obtained by a network logon, so it
runs without network privileges! Note that Kerberos was used to authenticate the client, but the ticket obtained by WMI is dropped on the floor when he starts another process.
PS. I'm not clear as why you see machine$ is used to access the share, are you sure it's not the Logon session event written when wmiprvse.exe is spawned by svchost.exe?
Willy.
"andrew_webby at hotmail" <andrew_webby@hotmail> wrote in message news:Or**************@tk2msftngp13.phx.gbl... Hmm.
I see it's trying to connect to my share as remotepcname$ which is of course the machine's 'user' account in the domain. So for fun and larks, I gave access to the PC inquestion at the share/ntfs level but it still won't work.
This would even do for anonymous readonly access to the world if I could get that to work. I'll see what I can find on the Kerberos side, but so far this doesn't sound very encouraging....
http://msdn.microsoft.com/library/de...delegation.asp That seems to be suggesting I would need to mark every client computer
in my domain as Trusted For Delegation - which I'm not really willing to do.
There must be an easier way, surely? A colleague here suggested mapping
a network drive remotely with a username/password and maybe that would
clear up the ID issue - what do you reckon?
Thanks for the top suggestions so far :)
AW
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message news:u3****************@TK2MSFTNGP10.phx.gbl... "ms" <andrew_webby@hotmail> wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... > Hi Willy > > Thanks for the suggestions. However, I tried adding Domain Admins in
where > you suggest and it didn't help. >
Hi Andrew,
Sorry, should have read your post more carefully. The problem you have is the famous multiple hop issue when using NTLM authentication. The remote process is impersonating "me" (the token obtained is a impersonation token - no user/password was obtained by this process), that means you don't have network credentials, and anonymous (I'm not sure this is the case on W2K3) will be used to access the shared network
resource. One thing you could try is to force Kerberos authentication, and set ImpersonationLevel.Delegate (so you will have to set ConnectionOption.Authority = "Kerberos:<principalname>). But, even that is not guaranteed to work, as WMI is free to reject Kerberos and fall back to NTLM authentication.
I suggest you enabled auditing on the remote share, that way you can check which account is used to access the share?
Willy.
Morning guys :)
Thanks for all the great assistance with this. I didn't try making the
computer account (that's my 'control' computer yeah, and not the ones that
are being told to install the patch?) enabled for delegation so I'll give
that a go just now.
Scott, yeah all the pieces in the jigsaw are part of the same domain. I have
two domain's I'm trying in, one is Native and the other is Mixed. XP -> XP
and 2k3 -> XP are the platforms I'm trying on at the moment.
Anyway, after a nights sleep, I came up with a workaround, but it's one of
those "well, only if I must deals". Kind of hoped I was past kludges like
this, but hey-ho.
I just drop a batch file on the client's computer, and then spawn my process
with a password passed to it (in clear text over the LAN, but as it's a
lowly non-logonable account that shouldn't matter too much. The patch$ share
is world-readable.).
The batch file looks like this:
@echo off
net use \\server\patch$ /user:DOMAIN\lowly_user %1
dir \\server\patch$>> c:\log.log 2>&1
net use \\server\patch$ /d
echo done>> c:\log.log 2>&1
And that's the job done. I then start my process as "install <password>".
A bit fakey and I cringe at the thought of passing passwords around, but I
should be able to lock it down a bit.
I'll persist on the kerberos option for a while as I can't get my process to
start with the current code and see what comes up.
Out of interest, here's my problem with that:
Dim options = New ConnectionOptions
options.EnablePrivileges = True
options.Authentication = AuthenticationLevel.Call ' (tried them all)
options.Impersonation = ImpersonationLevel.Delegate ' (tried them all, too
:))
options.authority = "Kerberos:DOMAIN\andreww"
options.username = "DOMAIN\andreww" (tried with/without this line)
options.password = txtPassword.Text
Dim scope = New ManagementScope("\\" + pc + "\root\cimv2", options)
scope.Connect() **** FAILS HERE with TARGET INVOCATION EXCEPTION
Dim processClass = New ManagementClass("Win32_Process")
processClass.Scope = scope
Dim inParams = processClass.GetMethodParameters("Create")
Dim startup = New ManagementClass("WIN32_ProcessStartup")
startup.Scope = scopeinParams("CommandLine") = "c:\check.cmd " &
txtPassword.Text
inParams("ProcessStartupInformation") = startup
Dim outParams = processClass.InvokeMethod("Create", inParams, Nothing)
Debug.WriteLine("CreateProcess returned :" +
outParams("ReturnValue").ToString())
The above bit works fine with ImpersonationLevel.Impersonate - it just gets
screwed up when changed to delegate so I'm not sure what's going on there.
Back to the books I think :)
Thanks again for the help guys.
Cheers
AW
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message
news:40********@news.microsoft.com... I reviewed most of the thread. Did you enable the computer account that
is the WMI Server in Active Directory to be enabled for delegation? Also is the file share mentioned a part of this Active Directory or one if it's member servers?
The other steps are also required, enabling kerberos authority and specifying the delegation on the Impersonation Level.
-- [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
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... Andrew, I've done some tests myself, and as far I see this can't work, simply because WMI (actually wmiprvse.exe) launches the command shell (cmd) in the security context of the impersonated domain account, but it's logon type is 3 (NETWORK), that means its token is obtained by a network logon, so it runs without network privileges! Note that Kerberos was used to authenticate the client, but the ticket obtained by WMI is dropped on the floor when he starts another process.
PS. I'm not clear as why you see machine$ is used to access the share,
are you sure it's not the Logon session event written when wmiprvse.exe is spawned by svchost.exe?
Willy.
Morning guys :)
Thanks for all the great assistance with this. I didn't try making the
computer account (that's my 'control' computer yeah, and not the ones that
are being told to install the patch?) enabled for delegation so I'll give
that a go just now.
Scott, yeah all the pieces in the jigsaw are part of the same domain. I have
two domain's I'm trying in, one is Native and the other is Mixed. XP -> XP
and 2k3 -> XP are the platforms I'm trying on at the moment.
Anyway, after a nights sleep, I came up with a workaround, but it's one of
those "well, only if I must deals". Kind of hoped I was past kludges like
this, but hey-ho.
I just drop a batch file on the client's computer, and then spawn my process
with a password passed to it (in clear text over the LAN, but as it's a
lowly non-logonable account that shouldn't matter too much. The patch$ share
is world-readable.).
The batch file looks like this:
@echo off
net use \\server\patch$ /user:DOMAIN\lowly_user %1
dir \\server\patch$>> c:\log.log 2>&1
net use \\server\patch$ /d
echo done>> c:\log.log 2>&1
And that's the job done. I then start my process as "install <password>".
A bit fakey and I cringe at the thought of passing passwords around, but I
should be able to lock it down a bit.
I'll persist on the kerberos option for a while as I can't get my process to
start with the current code and see what comes up.
Out of interest, here's my problem with that:
Dim options = New ConnectionOptions
options.EnablePrivileges = True
options.Authentication = AuthenticationLevel.Call ' (tried them all)
options.Impersonation = ImpersonationLevel.Delegate ' (tried them all, too
:))
options.authority = "Kerberos:DOMAIN\andreww"
options.username = "DOMAIN\andreww" (tried with/without this line)
options.password = txtPassword.Text
Dim scope = New ManagementScope("\\" + pc + "\root\cimv2", options)
scope.Connect() **** FAILS HERE with TARGET INVOCATION EXCEPTION
Dim processClass = New ManagementClass("Win32_Process")
processClass.Scope = scope
Dim inParams = processClass.GetMethodParameters("Create")
Dim startup = New ManagementClass("WIN32_ProcessStartup")
startup.Scope = scopeinParams("CommandLine") = "c:\check.cmd " &
txtPassword.Text
inParams("ProcessStartupInformation") = startup
Dim outParams = processClass.InvokeMethod("Create", inParams, Nothing)
Debug.WriteLine("CreateProcess returned :" +
outParams("ReturnValue").ToString())
The above bit works fine with ImpersonationLevel.Impersonate - it just gets
screwed up when changed to delegate so I'm not sure what's going on there.
Back to the books I think :)
Thanks again for the help guys.
Cheers
AW
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message
news:40********@news.microsoft.com... I reviewed most of the thread. Did you enable the computer account that
is the WMI Server in Active Directory to be enabled for delegation? Also is the file share mentioned a part of this Active Directory or one if it's member servers?
The other steps are also required, enabling kerberos authority and specifying the delegation on the Impersonation Level.
-- [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
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... Andrew, I've done some tests myself, and as far I see this can't work, simply because WMI (actually wmiprvse.exe) launches the command shell (cmd) in the security context of the impersonated domain account, but it's logon type is 3 (NETWORK), that means its token is obtained by a network logon, so it runs without network privileges! Note that Kerberos was used to authenticate the client, but the ticket obtained by WMI is dropped on the floor when he starts another process.
PS. I'm not clear as why you see machine$ is used to access the share,
are you sure it's not the Logon session event written when wmiprvse.exe is spawned by svchost.exe?
Willy.
Hi Scott,
Thanks, got it working (as expected) using delegation of credentials.
My problem was that the Workstation service was excluded for delegation on
the server running WMI.
Note that you need to set ImpersonationLevel.Delegate but I didn't need to
set the Kerberos authority, isn't that enabled per default in a "pure"
Kerberos realm?
Willy.
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message
news:40********@news.microsoft.com... I reviewed most of the thread. Did you enable the computer account that is the WMI Server in Active Directory to be enabled for delegation? Also is the file share mentioned a part of this Active Directory or one if it's member servers?
The other steps are also required, enabling kerberos authority and specifying the delegation on the Impersonation Level.
-- [MS] Scott McNairy WMI Test Engineer
Hi Scott,
Thanks, got it working (as expected) using delegation of credentials.
My problem was that the Workstation service was excluded for delegation on
the server running WMI.
Note that you need to set ImpersonationLevel.Delegate but I didn't need to
set the Kerberos authority, isn't that enabled per default in a "pure"
Kerberos realm?
Willy.
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message
news:40********@news.microsoft.com... I reviewed most of the thread. Did you enable the computer account that is the WMI Server in Active Directory to be enabled for delegation? Also is the file share mentioned a part of this Active Directory or one if it's member servers?
The other steps are also required, enabling kerberos authority and specifying the delegation on the Impersonation Level.
-- [MS] Scott McNairy WMI Test Engineer
Andrew,
See my my reply to Scott's posting, so I guess you have it working by now.
Willy.
"andrew_webby at hotmail" <andrew_webby@hotmail> wrote in message
news:%2***************@tk2msftngp13.phx.gbl... Morning guys :)
Thanks for all the great assistance with this. I didn't try making the computer account (that's my 'control' computer yeah, and not the ones that are being told to install the patch?) enabled for delegation so I'll give that a go just now.
Scott, yeah all the pieces in the jigsaw are part of the same domain. I have two domain's I'm trying in, one is Native and the other is Mixed. XP -> XP and 2k3 -> XP are the platforms I'm trying on at the moment.
Anyway, after a nights sleep, I came up with a workaround, but it's one of those "well, only if I must deals". Kind of hoped I was past kludges like this, but hey-ho.
I just drop a batch file on the client's computer, and then spawn my process with a password passed to it (in clear text over the LAN, but as it's a lowly non-logonable account that shouldn't matter too much. The patch$ share is world-readable.).
The batch file looks like this: @echo off net use \\server\patch$ /user:DOMAIN\lowly_user %1 dir \\server\patch$>> c:\log.log 2>&1 net use \\server\patch$ /d echo done>> c:\log.log 2>&1
And that's the job done. I then start my process as "install <password>".
A bit fakey and I cringe at the thought of passing passwords around, but I should be able to lock it down a bit.
I'll persist on the kerberos option for a while as I can't get my process to start with the current code and see what comes up.
Out of interest, here's my problem with that:
Dim options = New ConnectionOptions options.EnablePrivileges = True options.Authentication = AuthenticationLevel.Call ' (tried them all) options.Impersonation = ImpersonationLevel.Delegate ' (tried them all, too :)) options.authority = "Kerberos:DOMAIN\andreww" options.username = "DOMAIN\andreww" (tried with/without this line) options.password = txtPassword.Text Dim scope = New ManagementScope("\\" + pc + "\root\cimv2", options) scope.Connect() **** FAILS HERE with TARGET INVOCATION EXCEPTION
Dim processClass = New ManagementClass("Win32_Process") processClass.Scope = scope Dim inParams = processClass.GetMethodParameters("Create") Dim startup = New ManagementClass("WIN32_ProcessStartup") startup.Scope = scopeinParams("CommandLine") = "c:\check.cmd " & txtPassword.Text inParams("ProcessStartupInformation") = startup Dim outParams = processClass.InvokeMethod("Create", inParams, Nothing) Debug.WriteLine("CreateProcess returned :" + outParams("ReturnValue").ToString())
The above bit works fine with ImpersonationLevel.Impersonate - it just gets screwed up when changed to delegate so I'm not sure what's going on there. Back to the books I think :)
Thanks again for the help guys.
Cheers
AW
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message news:40********@news.microsoft.com... I reviewed most of the thread. Did you enable the computer account that is the WMI Server in Active Directory to be enabled for delegation? Also is the file share mentioned a part of this Active Directory or one if it's member servers?
The other steps are also required, enabling kerberos authority and specifying the delegation on the Impersonation Level.
-- [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
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... > Andrew, > I've done some tests myself, and as far I see this can't work, simply > because WMI (actually wmiprvse.exe) launches the command shell (cmd) in the > security context of the impersonated domain account, but it's logon > type is > 3 (NETWORK), that means its token is obtained by a network logon, so it runs > without network privileges! > Note that Kerberos was used to authenticate the client, but the ticket > obtained by WMI is dropped on the floor when he starts another process. > > PS. I'm not clear as why you see machine$ is used to access the share, are > you sure it's not the Logon session event written when wmiprvse.exe is > spawned by svchost.exe? > > Willy.
Andrew,
See my my reply to Scott's posting, so I guess you have it working by now.
Willy.
"andrew_webby at hotmail" <andrew_webby@hotmail> wrote in message
news:%2***************@tk2msftngp13.phx.gbl... Morning guys :)
Thanks for all the great assistance with this. I didn't try making the computer account (that's my 'control' computer yeah, and not the ones that are being told to install the patch?) enabled for delegation so I'll give that a go just now.
Scott, yeah all the pieces in the jigsaw are part of the same domain. I have two domain's I'm trying in, one is Native and the other is Mixed. XP -> XP and 2k3 -> XP are the platforms I'm trying on at the moment.
Anyway, after a nights sleep, I came up with a workaround, but it's one of those "well, only if I must deals". Kind of hoped I was past kludges like this, but hey-ho.
I just drop a batch file on the client's computer, and then spawn my process with a password passed to it (in clear text over the LAN, but as it's a lowly non-logonable account that shouldn't matter too much. The patch$ share is world-readable.).
The batch file looks like this: @echo off net use \\server\patch$ /user:DOMAIN\lowly_user %1 dir \\server\patch$>> c:\log.log 2>&1 net use \\server\patch$ /d echo done>> c:\log.log 2>&1
And that's the job done. I then start my process as "install <password>".
A bit fakey and I cringe at the thought of passing passwords around, but I should be able to lock it down a bit.
I'll persist on the kerberos option for a while as I can't get my process to start with the current code and see what comes up.
Out of interest, here's my problem with that:
Dim options = New ConnectionOptions options.EnablePrivileges = True options.Authentication = AuthenticationLevel.Call ' (tried them all) options.Impersonation = ImpersonationLevel.Delegate ' (tried them all, too :)) options.authority = "Kerberos:DOMAIN\andreww" options.username = "DOMAIN\andreww" (tried with/without this line) options.password = txtPassword.Text Dim scope = New ManagementScope("\\" + pc + "\root\cimv2", options) scope.Connect() **** FAILS HERE with TARGET INVOCATION EXCEPTION
Dim processClass = New ManagementClass("Win32_Process") processClass.Scope = scope Dim inParams = processClass.GetMethodParameters("Create") Dim startup = New ManagementClass("WIN32_ProcessStartup") startup.Scope = scopeinParams("CommandLine") = "c:\check.cmd " & txtPassword.Text inParams("ProcessStartupInformation") = startup Dim outParams = processClass.InvokeMethod("Create", inParams, Nothing) Debug.WriteLine("CreateProcess returned :" + outParams("ReturnValue").ToString())
The above bit works fine with ImpersonationLevel.Impersonate - it just gets screwed up when changed to delegate so I'm not sure what's going on there. Back to the books I think :)
Thanks again for the help guys.
Cheers
AW
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message news:40********@news.microsoft.com... I reviewed most of the thread. Did you enable the computer account that is the WMI Server in Active Directory to be enabled for delegation? Also is the file share mentioned a part of this Active Directory or one if it's member servers?
The other steps are also required, enabling kerberos authority and specifying the delegation on the Impersonation Level.
-- [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
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... > Andrew, > I've done some tests myself, and as far I see this can't work, simply > because WMI (actually wmiprvse.exe) launches the command shell (cmd) in the > security context of the impersonated domain account, but it's logon > type is > 3 (NETWORK), that means its token is obtained by a network logon, so it runs > without network privileges! > Note that Kerberos was used to authenticate the client, but the ticket > obtained by WMI is dropped on the floor when he starts another process. > > PS. I'm not clear as why you see machine$ is used to access the share, are > you sure it's not the Logon session event written when wmiprvse.exe is > spawned by svchost.exe? > > Willy.
Not sure - I think it needs to be specified somewhere otherwise it will
default to NTLM.
--
[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
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:uB**************@tk2msftngp13.phx.gbl... Hi Scott, Thanks, got it working (as expected) using delegation of credentials. My problem was that the Workstation service was excluded for delegation on the server running WMI. Note that you need to set ImpersonationLevel.Delegate but I didn't need to set the Kerberos authority, isn't that enabled per default in a "pure" Kerberos realm?
Willy.
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message news:40********@news.microsoft.com...I reviewed most of the thread. Did you enable the computer account that
is the WMI Server in Active Directory to be enabled for delegation? Also
is the file share mentioned a part of this Active Directory or one if it's member servers?
The other steps are also required, enabling kerberos authority and specifying the delegation on the Impersonation Level.
-- [MS] Scott McNairy WMI Test Engineer
Not sure - I think it needs to be specified somewhere otherwise it will
default to NTLM.
--
[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
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:uB**************@tk2msftngp13.phx.gbl... Hi Scott, Thanks, got it working (as expected) using delegation of credentials. My problem was that the Workstation service was excluded for delegation on the server running WMI. Note that you need to set ImpersonationLevel.Delegate but I didn't need to set the Kerberos authority, isn't that enabled per default in a "pure" Kerberos realm?
Willy.
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message news:40********@news.microsoft.com...I reviewed most of the thread. Did you enable the computer account that
is the WMI Server in Active Directory to be enabled for delegation? Also
is the file share mentioned a part of this Active Directory or one if it's member servers?
The other steps are also required, enabling kerberos authority and specifying the delegation on the Impersonation Level.
-- [MS] Scott McNairy WMI Test Engineer
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message
news:40********@news.microsoft.com... Not sure - I think it needs to be specified somewhere otherwise it will default to NTLM.
--
Scott,
Well I didn't set the Kerberos authority, what I'm seeing is that the
Negotiate SSP selects Kerberos and succeeds when delegation stuff is
correctly set-up.
That makes me think that setting the authority (to Kerberos or NTLM) is to
force the SSP to use one and only one of the protocols.
I will further investigate this and come back later.
Willy.
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message
news:40********@news.microsoft.com... Not sure - I think it needs to be specified somewhere otherwise it will default to NTLM.
--
Scott,
Well I didn't set the Kerberos authority, what I'm seeing is that the
Negotiate SSP selects Kerberos and succeeds when delegation stuff is
correctly set-up.
That makes me think that setting the authority (to Kerberos or NTLM) is to
force the SSP to use one and only one of the protocols.
I will further investigate this and come back later.
Willy.
Turns out that if the domain controller is configured or setup to run in
compatibility mode that can host Pre-Win2k Windows versions like NT4 and
Win9x, then the default is NTLM. If it is not, the default is kerberos
authority.
--
[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
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:OX**************@TK2MSFTNGP12.phx.gbl...
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message news:40********@news.microsoft.com... Not sure - I think it needs to be specified somewhere otherwise it will default to NTLM.
--
Scott,
Well I didn't set the Kerberos authority, what I'm seeing is that the Negotiate SSP selects Kerberos and succeeds when delegation stuff is correctly set-up. That makes me think that setting the authority (to Kerberos or NTLM) is to force the SSP to use one and only one of the protocols. I will further investigate this and come back later.
Willy.
Turns out that if the domain controller is configured or setup to run in
compatibility mode that can host Pre-Win2k Windows versions like NT4 and
Win9x, then the default is NTLM. If it is not, the default is kerberos
authority.
--
[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
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:OX**************@TK2MSFTNGP12.phx.gbl...
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message news:40********@news.microsoft.com... Not sure - I think it needs to be specified somewhere otherwise it will default to NTLM.
--
Scott,
Well I didn't set the Kerberos authority, what I'm seeing is that the Negotiate SSP selects Kerberos and succeeds when delegation stuff is correctly set-up. That makes me think that setting the authority (to Kerberos or NTLM) is to force the SSP to use one and only one of the protocols. I will further investigate this and come back later.
Willy.
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message
news:40********@news.microsoft.com... Turns out that if the domain controller is configured or setup to run in compatibility mode that can host Pre-Win2k Windows versions like NT4 and Win9x, then the default is NTLM. If it is not, the default is kerberos authority.
Scott,
Well, that's what I meant with .... enabled per default in a "pure" Kerberos
realm?
So if you need to be sure Kerberos is used you better set it explicitely.
Willy.
"[MS] Scott McNairy" <sc****@online.microsoft.com> wrote in message
news:40********@news.microsoft.com... Turns out that if the domain controller is configured or setup to run in compatibility mode that can host Pre-Win2k Windows versions like NT4 and Win9x, then the default is NTLM. If it is not, the default is kerberos authority.
Scott,
Well, that's what I meant with .... enabled per default in a "pure" Kerberos
realm?
So if you need to be sure Kerberos is used you better set it explicitely.
Willy. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: techfuzz |
last post by:
I'm posting my problem experience and solution I found here for other
ASP.NET developers.
I have a web application that uses Forms Authentication with Active
Directory to control access. In...
|
by: Tom B |
last post by:
In my web.config file I've specified Windows for the authentication, in IIS
I've set it to Integrated Authentication.
But my SQL connection is still showing Anonymous.
Is there somewhere else I...
|
by: Eric Veltman |
last post by:
Hello everyone,
Till now, I've always used IIS integrated authentication
and impersonation, such that the ASP.NET code on the server
is executed with the permissions of the user who is...
|
by: Mark |
last post by:
Is there a way to use ASP.NET's windows authentication so that the user that
is using our web page is the user that is connected to our SQL Server? This
will allow us to leverage our domain...
|
by: Erez Shor |
last post by:
Hi,
I need to build and asp page which access a remote windows server's
registry and create a registry key.
In order for the ASP page to be able to access the registry on the
remote server I need...
|
by: Kristof Despiere |
last post by:
Suppose you have one domain, filled with a couple of users. What needs to be
done now is I need to start a windows application from a webform by pressing
a button on the webform (for example).
...
|
by: andrew_webby at hotmail |
last post by:
Hi
Am having a problem with an app I wrote to test patch delivery. I
contact a remote PC, and get it to run a patch which is installed on a
server. It works fine if I use psexec for example and...
|
by: Daniel Knöpfel |
last post by:
Hello
On our asp.net 2.0 website we impersonate every request to the identity of
the user logged in. This works this way:
1. user logs in, providing username, password
2. user is authenticated...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |