0

I have an Azure file storage account which I created a share on. I have 2 Azure VMs, one running SQL server and one running IIS and a Windows service (written in c# .net 4.5.1). I need them both to access the share to share files. I have read several articles and have tried to persist credentials using cmdkey and map the drive with net use. I am running into 2 problems.

On the SQL VM, everything seems to work fine. It is writing files to the share and I haven't had much trouble there. On the other VM I'm having problems. First, the persist bit doesn't seem to actually work. I run it, verify it's stored (shows up when I do cmdkey /list, and in the credentials manager), and I can map the drive using net use. It appears to work. I can browse to the drive in Explorer, but if I log off the machine it doesn't reconnect when I log back in. The connection seems to be lost as soon as I log out of the VM until I run net use again. Second, even when I can browse to the folder, the Windows service can't find it at all. I've verified the path is correct that it's looking for. I copied and pasted it into an Explorer window and it goes right to the folder. I tried running the service as Local System, as the account I log into the VM with... All give the path not found error. As far as I've been able to find, the only 2 things I'm supposed to need are the cmdkey command and the net use command and the drive should be usable and reconnect automatically. Am I missing something?

Edit: I forgot to mention, if I run the service as a console app on the same machine, it does find the folder and runs properly. Run as a service, it does not. It is configured to be able to run as either using the method found at http://www.dontpaniclabs.com/blog/post/2011/10/20/running-a-service-as-an-application/

user2517183
  • 126
  • 5

1 Answers1

0

I have had this exact same problem myself and I posted on Stack Exchange but got no answer.

The issue is that a Mapped Network drive or a Network Share UNC is only persistent for the user who created it, and the credentials stored by cmdkey are also only persistent for the user who created it.

This is why when you log onto the VM and access persist the credentials, you are able to navigate to the share or use it as a mapped network drive. However, an application installed as a Windows Service will not be able to use the share as it will not have the credentials to be able to do this.

The way I have worked around this is, I have created a Local User on my VM which has the username set as that required for access to my StorageAccount FileShare and set the password to be the StorageAccount Access Key. I then set my Windows Service to run as this user instead of as the Local System Account.

I imagine this is also the same issue for your IIS instance. As your IIS by default will use an ApplicationPool with the default "ApplicationPoolIdentity" user. You can change this user to also run as your newly created Local User.

EDIT: The Windows User solution above will only work when your StorageAccount Name is under 20 Characters in length as this is the limit for a Windows Username

There is another way around this. You can change your code so that when it makes calls to the UNC or the Mapped Network Drive, it can pass through the credentials required to authenticate.

I have just tried the example in the link below, and it works great.

How do you do Impersonation in .NET?

Community
  • 1
  • 1
jonhoare
  • 1,279
  • 7
  • 15
  • I went to give this a try. The storage account name is longer than 20 characters, which is what Windows is limiting the user name to. It just truncates it. – user2517183 May 23 '16 at 14:12
  • Ahh! That is indeed rather annoying. I was obviously quite lucky then with mine only being 7 characters. Would be worth trying out the impersonation method though? – jonhoare May 23 '16 at 14:47