none
Making connections to Azure File Shares from system accounts

    Question

  • I have a couple of related questions about the Azure Storage File Share capability.

    I have an ASP.Net application hosted in Azure VMs.  One of the requirements of the application is that it be possible to exchange file data with external integration partners using SFTP.  To that end, we have set up a dedicated file server VM, and installed an SFTP Server product to provide support for file exchange.  There is a need for the VMs in the application environment to access the files on the file server.  The application has to create outbound files for transfer to the integration partners, and it also has to process inbound files.   

    My initial approach to this requirements was to create an Azure File Share, and make the share available to the file server and application VMs.  I’d assign a directory within the file share as the home directory for a logged-in SFTP client user.  The problem I’m trying solve is that SFTP Server runs under the SYSTEM account, as far as I can tell.  This means that, when a remote SFTP client logs in, it can’t see its home directory, because there’s no connection to the share from the context being used by the SFTP server.  Is there a way for me to persist the storage account credentials in the SYSTEM account’s context, and then to mount the file share using these persisted credentisls?

    The second question is parallel to the first one, but from the application perspective, rather than the file server perspective.   I need to make sure that my ASP.Net application can see the file share.  I see from the comments to the post here    that ASP.Net pages run under the NETWORK SERVICE account, and that it’s necessary to create the persistent connection to the file share in that context.  I wasn’t entirely clear how that would be done, and I wonder if you could clarify for me,

    Thanks,

    Pete Hornby


    • Edited by PeterHornby Monday, October 26, 2015 11:00 PM
    Monday, October 26, 2015 6:28 PM

Answers

  • Thanks for the replies.

    I recently found a reference (Andrew Edwards's comment in this post) which led me to realize that both these problems could be solved by use of the SysInternals PsExec utility.  The -s switch allows PsExec to create a process running in the SYSTEM context.  If this process is CMD.EXE, the 'cmdkey' and 'net use' commands, which persist the storage account credentials into the user context and make the persistent connection to the share, can be executed from there, and this works just fine.

    psexec --i -d -s CMD.EXE

    It also appears, although the need to try this in my situation has gone away, that PsExec's -u switch will allow the creation of a process running under the NETWORK SERVICE account.  

    psexec -i -d -u "nt authority\network service" CMD.EXE

    -Pete

    Wednesday, October 28, 2015 5:51 PM

All replies

  • Hi,

    Thanks for posting here.

    For the 1st question you asked, to my knowledge it is not possible.

    For the 2nd question, this can be done using command prompt from the VM and by following the article as mentioned.

    You can also check the below link using powershell.

    http://blogs.technet.com/b/canitpro/archive/2014/09/23/step-by-step-create-a-file-share-in-azure.aspx

    http://blogs.msdn.com/b/windowsazurestorage/archive/2014/05/12/introducing-microsoft-azure-file-service.aspx

    Hope this helps.

    Girish Prajwal

    Tuesday, October 27, 2015 3:53 PM
    Moderator
  • One possible workaround for 1st question is run SFTP Server under a user account, and when create this user account use your storage account name as user name, account key as password.

    That way the SFTP server will be able to mount the file share with its own user context. 

    - Jason

    Tuesday, October 27, 2015 11:07 PM
  • Thanks for the replies.

    I recently found a reference (Andrew Edwards's comment in this post) which led me to realize that both these problems could be solved by use of the SysInternals PsExec utility.  The -s switch allows PsExec to create a process running in the SYSTEM context.  If this process is CMD.EXE, the 'cmdkey' and 'net use' commands, which persist the storage account credentials into the user context and make the persistent connection to the share, can be executed from there, and this works just fine.

    psexec --i -d -s CMD.EXE

    It also appears, although the need to try this in my situation has gone away, that PsExec's -u switch will allow the creation of a process running under the NETWORK SERVICE account.  

    psexec -i -d -u "nt authority\network service" CMD.EXE

    -Pete

    Wednesday, October 28, 2015 5:51 PM