none
Remote process started through WMI has trouble accessing a network drive RRS feed

  • 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).aspx

    When, 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
    Thursday, February 18, 2010 12:06 PM

Answers

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
    Thursday, February 18, 2010 2:06 PM
  • 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>myprocess

    I tried using a UNC path (\\mydrive\myfolder) but it didn't work either, same issue ...

    I don't really know what to do ...
    Thursday, February 18, 2010 3:31 PM
  • 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
    Thursday, February 18, 2010 3:57 PM
  • 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 sid

    I 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 ...
    )
    Thursday, February 18, 2010 4:18 PM
  • "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
    Thursday, February 18, 2010 4:58 PM
  • 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;



    Thursday, February 18, 2010 5:08 PM
  • 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
    Thursday, February 18, 2010 5:33 PM
  • 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
    Friday, February 19, 2010 3:25 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
    Monday, February 22, 2010 9:53 AM
  • Any solution yet?
    Thursday, May 17, 2012 3:58 AM