Answered by:
Remote process started through WMI has trouble accessing a network drive

Question
-
Hello,Here's my problem. I have two machines under windows XP, that I will call server and client.I am remotely starting a process from server (admin account) on client with Administrator rights using WMI.This works well, and the process can write on the client drive.However, when I want this process to access a network drive, it does not work. Although, this drive is reachable from this client machine ...When I say it does not work, I mean that the PathIsDirectory function is failing. http://msdn.microsoft.com/en-us/library/bb773621(VS.85).aspxWhen, I run my process directly on the client (locally, not using wmi), it works. The process can write on the network drive.The only thing I can think of, is that I might have a WMI permission problem ... but everything is running as Administrator ... and I even tried to allow everything using wmimgmt.msc ...I hope I was clear enough ... and that someone can help me.Thanks,Jonathan
Answers
-
Have you tried using scheduled tasks to launch your app instead of WMI? you can call schtask.exe to launch a scheduled task remotely. then the task would run 'locally' on the targeted box. We use it for automated deployments so i know this works.
James Peckham CSM, CSP, CAPM Developer and Agilist http://www.jamespeckham.com- Marked as answer by StormySeaSailor Monday, February 22, 2010 9:53 AM
-
Hum... we're getting further and further out of my area of experience...
I'm still quite sure it's a permission issue of some kind. The WMI process (which is running under "S-1-5-18", right?) kicks off a child process running under "S-1-5-21-16", a rather mysterious account (some kind of non-unique SID).
http://msdn.microsoft.com/en-us/library/aa379649(VS.85).aspx
http://support.microsoft.com/kb/243330
It's attempting to access - via UNC - a share that allows Everyone and Anonymous access.
I believe the problem may be in Impersonate; it probably needs to be Delegate:
http://msdn.microsoft.com/en-us/library/aa389288(VS.85).aspx
It would make sense that WMI is just inventing the non-unique SID to represent an impersonated but not delegated security context.
As far as I know, there's no way to enable Delegate without a Domain.
And the Identify (and lower) settings would probably not allow WMI to start child processes in the first place...
Is psexec an option instead of WMI?
-Steve
Programming blog: http://nitoprograms.blogspot.com/
Including my TCP/IP .NET Sockets FAQ
and How to Implement IDisposable and Finalizers: 3 Easy Rules
Microsoft Certified Professional Developer
How to get to Heaven according to the Bible- Marked as answer by StormySeaSailor Monday, February 22, 2010 9:53 AM
-
PSexec woudln't work for what I want to achieve.schtask.exe might be an option, I'll have to look into it.The only other option I can see, would be to have all the machines on a domain ...Thank you Stephen and James.Jonathan
- Marked as answer by StormySeaSailor Monday, February 22, 2010 9:53 AM
All replies
-
I'm pretty sure that using WMI to start a remote process will execute the process as a child of a svchost.exe process (download Process Explorer to check this for sure).
If that is correct, then your remote process is actually running as a child of a Windows service process, and under the same limitations. Unfortunately, Windows services have several restrictions when it comes to networking, one of which is that they cannot use network drives:
http://nitoprograms.blogspot.com/2009/10/windows-services-and-network.html
You should be able to use UNC paths instead of a network drive, if the permissions are set correctly on the network share and file system (I'm not sure if WMI would pass your login token on to its child process or if it would pass on its own Local System token).
-Steve
Programming blog: http://nitoprograms.blogspot.com/
Including my TCP/IP .NET Sockets FAQ
and How to Implement IDisposable and Finalizers: 3 Easy Rules
Microsoft Certified Professional Developer
How to get to Heaven according to the Bible -
Thanks for your answer Steve.You were right when you said the WMI started process was a child of svchost.Here's the full parent list:System>WinLogon>services>svchost>wmiprvse>myprocessI tried using a UNC path (\\mydrive\myfolder) but it didn't work either, same issue ...I don't really know what to do ...
-
Proceed trying to get it to work using UNC paths. It is probably a permission issue at this point.
First, check the WMI child process and see what account it's running under (Security tab of the Properties window). I'm expecting it'll be "S-1-5-18".
If you are on a domain, then Local System will authenticate using computer credentials. In this case, you can add the computer account to the shared folder permissions.
If you are not on a domain, then Local System will authenticate anonymously. In this case, you can try adding the Anonymous builtin to the shared folder permissions.
-Steve
Programming blog: http://nitoprograms.blogspot.com/
Including my TCP/IP .NET Sockets FAQ
and How to Implement IDisposable and Finalizers: 3 Easy Rules
Microsoft Certified Professional Developer
How to get to Heaven according to the Bible -
I granted full access for everyone for the UNC path.Both machines aren't on a domain ...The WMI child processes are running under "S-1-5-21-16"(Edit: I found S-1-5-21 Global group or user, relative to domain sidI am going to try this for now : "If you are not on a domain, then Local System will authenticate anonymously. In this case, you can try adding the Anonymous builtin to the shared folder permissions."Update: it didn't work ...)
-
"Anonymous" is different than "Everyone". In the world of Windows permissions, Everyone does not include Anonymous. Confusing, eh?
To clarify: you did try adding Anonymous to the permissions and it didn't work?
It's interesting that you're seeing "S-1-5-21-16". This doesn't appear to be a proper SID; the "S-1-5-21x-*" grouping is for domain authentication.
-Steve
Programming blog: http://nitoprograms.blogspot.com/
Including my TCP/IP .NET Sockets FAQ
and How to Implement IDisposable and Finalizers: 3 Easy Rules
Microsoft Certified Professional Developer
How to get to Heaven according to the Bible -
It have added both "anonymous logon" and "Everyone" to the shared folder permission (sharing&security), and it still isn't working.I am not sure yet whether the connection is refused by the machine where the shared folder is or before that by the machine where the process is running.I am not sure why the process is runnnig under "S-1-5-21-*", I would have assumed that because it's started using the Administrator credentials, it would run under the Administrator account ...Here are the WMI connecttion options, I use (so far I tried other ones but I couldn't even start the remote process):
options.Impersonation = ImpersonationLevel.Impersonate; options.Authentication = AuthenticationLevel.Default;
-
Hum... we're getting further and further out of my area of experience...
I'm still quite sure it's a permission issue of some kind. The WMI process (which is running under "S-1-5-18", right?) kicks off a child process running under "S-1-5-21-16", a rather mysterious account (some kind of non-unique SID).
http://msdn.microsoft.com/en-us/library/aa379649(VS.85).aspx
http://support.microsoft.com/kb/243330
It's attempting to access - via UNC - a share that allows Everyone and Anonymous access.
I believe the problem may be in Impersonate; it probably needs to be Delegate:
http://msdn.microsoft.com/en-us/library/aa389288(VS.85).aspx
It would make sense that WMI is just inventing the non-unique SID to represent an impersonated but not delegated security context.
As far as I know, there's no way to enable Delegate without a Domain.
And the Identify (and lower) settings would probably not allow WMI to start child processes in the first place...
Is psexec an option instead of WMI?
-Steve
Programming blog: http://nitoprograms.blogspot.com/
Including my TCP/IP .NET Sockets FAQ
and How to Implement IDisposable and Finalizers: 3 Easy Rules
Microsoft Certified Professional Developer
How to get to Heaven according to the Bible- Marked as answer by StormySeaSailor Monday, February 22, 2010 9:53 AM
-
Have you tried using scheduled tasks to launch your app instead of WMI? you can call schtask.exe to launch a scheduled task remotely. then the task would run 'locally' on the targeted box. We use it for automated deployments so i know this works.
James Peckham CSM, CSP, CAPM Developer and Agilist http://www.jamespeckham.com- Marked as answer by StormySeaSailor Monday, February 22, 2010 9:53 AM
-
PSexec woudln't work for what I want to achieve.schtask.exe might be an option, I'll have to look into it.The only other option I can see, would be to have all the machines on a domain ...Thank you Stephen and James.Jonathan
- Marked as answer by StormySeaSailor Monday, February 22, 2010 9:53 AM
-