Working on an Azure implementation I ran into an interesting issue. The client wanted to use the Azure File Storage feature (currently in preview) which allows Azure Storage to presented as an SMB 2.1 compatible share to VMs located in the same region. I created the storage account and file share, then tried to mount it using "net use" on one of their VMs. The error I got back was "System error 53 has occurred. The network path was not found." Not a very helpful message and also not technically true! Read past the break for the full explanation why this is occurring and how you can fix it.
Like any savvy tech person, the first thing I did was Google the error. I immediately noticed that a lot of people don't necessarily understand the Azure File Storage and how it differs from their blob, table, and queue offerings. It is not enough to simply enable the preview feature, create a storage account and then try to access it via SMB. You actually need to create a file share using either the new Azure portal or Azure PowerShell. You can find directions on that right here.
Once you have all that sorted, you in theory should be able to mount that share as a drive using the command:
net use Z: \\<storageaccount>.file.core.windows.net\sharename /u:<storageaccount> <storagepassword>
When I tried that, I got the System error 53 message and not a whole lot else. I knew the share was there b/c I could access it via PowerShell commands and even create directories and copy over files. The VM was in the same region as the storage account, so what was the issue? After a little more Googling I found this post from Morgan Simonsen's blog. He ran into the same issue with a Domain Controller in Azure, but not on regular VMs. It turns out that I was doing all my testing on a Domain Controller as well! I tried the net use command on a member server, and it worked like a champ! It looked like Morgan and I were in the same boat, so I opened a ticket with Microsoft to try and get this issue resolved.
After a bit of troubleshooting using the new version of Network Monitor, confusingly called Message Analyzer, we determined the issue. As you may have guessed by the post's title, it all came down to NTLM. The Azure File Storage only supports NTLMv2 and the Domain Controller was trying to use NTLM version 1, whereas the member server was not. A little digging using rsop.msc showed me that the setting "Network Security: LAN Manager authentication level" was set to "Send NTLM response only" by the Default Domain Controller Policy GPO. The member server however was set to "Not defined" so it would negotiate whatever level the other end wanted, which in this case was NTLMv2. The fix for this problem is simple. Either set the Default Domain Controller Policy to "Not defined" or set it to "Send LM & NTLM – use NTLMv2 session security if negotiated". If you don't have any servers or clients running something older than Windows 7/Server 2008 then you can set it to "Send NTLMv2 response only" or higher and enjoy the increased security.
In case you are wondering why the Default Domain Controller Policy was set that way, it wasn't the action of some random Sysadmin. Instead it turns out that this was the default setting for Windows Server 2003 domain controllers. If you've never revisited your Default Domain Controller Policy since you upgraded from Windows Server 2003, it is probably still set that way. This TechNet article lays it all out pretty clearly.
And thus the mystery of Azure File Storage with Domain Controllers is solved! Thanks to Morgan for pointing me in the right direction.Labels: Azure, File, IaaS, Microsoft, powershell