Can you Enable SMBv1 on Azure VMs?

Occasionally an enterprise environment will have a requirement to retain legacy authentication systems that may need to use SMBv1. What are the options when you move your services and infrastructure to Azure?

When first looking at this challenge we really (really!) need to acknowledge the dangers and risks that when dealing with SMBv1 we should use firewalls and network security groups to tightly restrict how accessible any system that runs this protocol is. A nice contribution from a well respected security expert I’ve worked with advises that anytime we need to enable a high-risk communication system we should also assign an end-date to the risk. Meaning we simply say that this will be resolved or removed on the end-date. I really like this suggestion.

Well, how can I enable this on Azure virtual machines? Isn’t that blocked?

Well….yes and no. It’s not so much blocked as it is removed.

assumption:

You have the correct WIM image of your used Windows Server Operating System that you have deployed on Azure.

1. Create C:\tempwim and C:\tempwim\mount folder on your virtual machine
2. Copy install.wim to the folder C:\tempwim
3. Run Command Prompt as administrator
   1. Type: dism /mount-wim /wimfile:c:\tempwim\install.wim /index:4 /mountdir:c:\tempwim\mount /readonly
   2. Given that the operating system index:4 is running Datacenter edition.
      1. 1 = Standard CORE
      2. 2 = Standard
      3. 3 = Datacenter CORE
      4. 4 = Datacenter
4. Type: dism /online /Enable-Feature /FeatureName:SMB1Protocol /All /source:c:\tempwim\mount\windows\winsxs /limitaccess
5. Reboot the machine
6. Then perform configuration of SMBv1 as needed
7. Unmount the install.wim from the mount folder
8. Run Command Prompt as administrator
9. Type: dism /unmount-wim /mountdir:c:\tempwim\mount /discard
10. Close the Command Prompt

Make sure that you secure your configuration through all available means; which includes removing SMBv1 at the end-date for your project. You should do all you can to move away from legacy protocols and systems as they are less secure and attackers are really smart teams of people who will find a way to exploit any weaknesses like this.

One scenario where this may be lower risk is if your network has no external access or routes and the vnet in question is not peered to another vnet or network. This would mean that your implementation of SMBv1 is fully isolated within the deployed vnet. Not ideal; but lowering risk whenever you can does matter. Ensure that any access is done via remote desktop and users are forced to use two-factor authentication. That is a start; but the best way is to not scale backwards for compatibility to existing systems and to upgrade into modern standards whenever it is possible.