Problems with authentication/impersonation

[andrew_webby at hotmail]

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

 

[Willy Denoyette [MVP]]

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]

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]]

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_webby at hotmail]

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/d...i/connecting_to_a_3rd_computer-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]]

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.

 

[[MS] Scott McNairy]

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

 

[andrew_webby at hotmail]

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$ /userOMAIN\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 = "KerberosOMAIN\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

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

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.

 

[Willy Denoyette [MVP]]

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.

 

[Willy Denoyette [MVP]]

Andrew,

See my my reply to Scott's posting, so I guess you have it working by now.

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$ /userOMAIN\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 = "KerberosOMAIN\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

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

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.

 

[[MS] Scott McNairy]

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

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.

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.

 

[Willy Denoyette [MVP]]

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]

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

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.

 

[Willy Denoyette [MVP]]

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.