Search code examples
windowsazureserviceazure-active-directory

Unable to access UNC path via windows service even when using same user for service

I have a windows vm and have created an Admin user, let's say - AdminUser. I have mounted an azure file share to that user to Z: drive. The share can be accessed by unc path or the drive path. I also have a c# utility that checks if path exists and it returns true when I run it. This is all good. Now when I created a windows service with that utility and with same user credential, it throws an error that the path doesn't exist. Things to note -

  • The service user or the user I used to login is a local adminstrator user and while creating the service, I had provided as "./AdminUser" to CreateService. Also provided password to config.
  • The VM is also connected to a domain. So I have users from default-domain\* and connected-domain\*. The connected-domain linked to an azure active directory.

Is there any other type of user I need to set as log on to service?

I can see here it says the local user can't access network resources but I am wondering since I mounted the path with proper credentials, does this matter?

Update: Got the same issue when using running as with the exe.

runas /user:USER­NAME “C:\full\path\of\Program.exe”
Solution

  • We have to use cmdkey to store the credentials that can be used by SMB later. Launch a cmd.exe with the user that you want to use for the service using either context menu or command e.g.

    runas /user:default-domain\domainServiceUser cmd

    Then in the new command shell use cmdkey

    cmdkey /add:<storagteAccountName>.file.core.windows.net\<shareName> /user:AZURE\<storageAccountName> /pass:<storageAccountKey>

    Rerun the service and it should work.

    If you want to also mount this as a persistent drive, you can use

    Command Prompt

    net use z: \\<storagteAccountName>.file.core.windows.net\<shareName> /persistent:yes

    Powershell

    New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storagteAccountName>.file.core.windows.net\<shareName>" -Persist

    Make sure that the user is exactly the same that would be used for the windows service including the domain i.e. use default-domain\domainServiceUser or ./AdminUser for running the cmdkey.