Migrate a production environment from SMBv1 to SMBv2/v3

[Bernard_Buyle06]

Hi everyone,

I would like to get your help and advice in order to migrate successfully my production environment from SMBv1 to SMBv2/v3. In test, I'm able to implement this change but in production this change is more tricky...

Let me describes what I've done and what my production looks like:

In test:

- Implementing a GPO with the following registry changes on a test server and on the unique test domain controller I have

- Restart these servers

- Wireshark shows that SMBv1 is well disabled and that all SMB communications are in SMBv2 between my test server and my test DC.

- I’m still working on the SMBv3 implementation or switch from SMBv2 to SMBv3 (not done yet).

- I need to configure a Linux server in SMBv2/v3 and test too (not done yet).

GPO details:

1°) Disable SMBv1 in LanmanServer:
Action: Create
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value name: SMB1
Value type: REG_DWORD
Value data: 0

2°) Disable SMBv1 in LanmanWorkstation:
Action: Update
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\services\mrxsmb10
Value name: Start
Value type: REG_DWORD
Value data: 4 (=disable)

3°) Delete SMBv1 dependancy of the LanmanWorkstation service:
Action: Replace
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\LanmanWorkstation
Value name: DependOnService
Value type REG_MULTI_SZ
Value data:
Bowser
MRxSmb20
NSI

4°) Require signing SMBv2/v3 for LanmanServer service:
Action: Update
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value name: RequireSecuritySignature
Value type: REG_DWORD
Value data: 1

5°) Require signing SMBv2/v3 for LanmanWorkstation server:
Action: Update
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
Value name: RequireSecuritySignature
Value type: REG_DWORD
Value data: 1

In production, I have a lot of servers in different AWS regions with different DC, a mix of linux servers and Windows servers. 

My challenge is to migrate without production impact. 

- Does someone has already performed this kind of migration ?

- Modifications are at the packet level, do you already experienced issue when migrating from SMBv1 to SMBv2/v3 ?

All advices are welcome! 

Regards,

Bernard.

[#2]

Hello,

Keep in mind recent releases of Windows clients/servers do not have SMB1 enabled by default (and I hope you didn't enable it). Thus you do not need this kind of Group Policy parameters (which may really messed up OSes and are quite difficult to rollback).
What you need to look out for is :
- Very old Windows OS (Windows XP/2003) : those are a security nightmare. Get rid of them.
- Very old Unix/Linux OS : see above
- Printers and scanners still relying on SMBv1 : this is quite painful to check. You must inventory everything, then check compatibility per model and per firmware. You may need to update (or even replace entirely) printers before moving your file servers away from SMBv1.
- Apps. Test, test, test. Hope you still have editor's support for them.

Best tip : browse SMB Product Team here : https://techcommunity.microsoft.com/t5/storage-at-microsoft/stop-using-smb1/ba-p/425858

You'll get detailed how-to and ton of tips directly from Microsoft.

[#3]

Hello Alban,
Thanks for your reply, I use Windows Server 2016 and I've never enabled the SMBv1 on them. This is odd, when checking via powershell SMBv1 seems enabled on my servers, I will continue to find why...
My goal was initialy to remediate a vulnerability founded which told me that smb signing wasn't enabled. But SMBv2/v3 don't use "enablesiging" registry keys, they use "RequireSecuritySignature" key instead. My main issue is to find the way to enable it without get impact on all my domain controller and member servers... If my DC require siging but my member servers don't have this setting set yet, what is the result ? network issue ? Hard to deploy it smoothly, I'm going to listen your link too. Thanks, your help is appreciated ;)

[#4]

Hi Bernard,

It’s always best go with the phase wise approach by scoping few servers from each site in the GPO which disables outdated protocols.

For example if we have 10 sites and each site has got 5 servers then we can scope at least 3 servers in the GPO which disables the vulnerable protocol, this way we will have other 2 servers to serve the requests if in case if anything breaks.

In my experience even after following this approach I ran into issues with printers and file servers.

Hence I would suggest you to list all the print servers n file servers to quickly turn on this protocols if anyone raises complaints.

Keep the rollback plan ready and share it with the concerned technical teams for a quick fix.

The most important lesson I learnt from this migration is:
In my case I used GPO preferences to delete registries on servers as a rollback plan but I realised the the quick workaround (in critical sites ) to bring back the service would be to login locally on the Server or use Powershell to delete the registries real quick before the GPO deletes it.

If you are using GP preferences for creation or deletion of registries take a special care of GPO tattooing issue to avoid delays in roll back if in case anything breaks.

Regards,
Manoj

[#5]

Hello Manoj94,
Thank to have take time to update my topic.
My environment doesn't have printers and file servers. it remains to me basically 2 questions:
=> Can we include domain controllers as file server if they only manage users/groups/Computer and GPO ? In conclusion can my domain communication be impacted ?
=> My servers communicate principaly through sftp/ssh or https/https, can these protocols be impacted too if I disable SMBv1 and enable requiresigning feature?
Thank you very much in advance for your support !