Microsoft disables SMBv1 on domain controller

Topic

New Reply

It seems kind of official: applying any of the following patches to a Windows Server 2012 R2 domain controller appears to disable SMBv1. Patching a member server does not cause any problem.

2022-12 Security Monthly Quality Rollup for Windows Server 2012 R2 for x64-based Systems (KB5021294)

2022-12 Security Only Quality Update for Windows Server 2012 R2 for x64-based Systems (KB5021296)

2023-01 Security Monthly Quality Rollup for Windows Server 2012 R2 for x64-based Systems (KB5022352)

To be fair, Microsoft did announce (April, 2022) that they would be removing SMBv1 going forward. I did not expect that updates would cause a problem in existing systems, nor am I able to find any relevant information about this in the documentation for the updates.

I created a sandboxed network consisting of a Windows 2012 R2 server (domain controller) and a Windows XP SP3 client (domain member). Both computers are VMs running on Hyper-V.

Create and share a folder on the Windows XP client. Browse to the shared folder from the Windows 2012 R2 server. Works fine.

Install any one of the above listed updates on the Windows 2012 R2 server. Browse to the shared folder from the Windows 2012 R2 server. Fails.

Remove the installed update from the Windows 2012 R2 server. Browse to the shared folder from the Windows 2012 R2 server. Works fine.

I’m not sure of the precise root cause for the failure. I’m curious, but don’t really have the bandwidth to keep digging. Moving forward, I will test any domain controller patches on my sandboxed network before applying them to a production network.

Cheers

Reply | Quote

Replies

Let me ask around because normally anything like this is documented.  It could be an unintentional bug.  We had a Rdgateway got thrashed bug for months that finally got fixed in 2022.

Susan Bradley Patch Lady

Reply | Quote

So if you can browse from the XP TO the 2012 R2 it doesn’t seem to me that SMBv1 is broken.

When you browse FROM the 2012 r2 to the XP (which is not typical direction btw) what error messages or events do you get?

Susan Bradley Patch Lady

Reply | Quote

Using the Windows 2012 R2 domain controller on the sandboxed network:

1. Able to access shared folder on Windows XP domain member

2.Powershell: “Get-SMBServerConfiguration” returns “EnableSMB1Protocol” set to True

3.Install KB5022352 and reboot

4.Unable to access shared folder on Windows XP domain member

5.Error message “Windows cannot access \\Try-Client-WXP”

Details: Error code 0x80070035 / The network path was not found.

Powershell: “Get-SMBServerConfiguration” returns “EnableSMB1Protocol” set to True

6.Remove KB5022352 and reboot

7.Able to access shared folder on Windows XP domain member

8.Powershell: “Get-SMBServerConfiguration” returns “EnableSMB1Protocol” set to True

Authentication:

The sandboxed network uses the Windows 2012 R2 defaults for authentication. Domain hosts will accept LM, NTLMv1, and NTLMv2.

The production network domain hosts do not allow LM or NTLMv1. Getting rid of NTLMv2 is on the list, but is a bit trickier. If it turns out that (part of) the solution is to remove the Windows XP clients from the domain, then Kerberos authentication may not be available.

BTW, since network browsing still works on the sandboxed network, it seems likely that SMBv1/CIFS is still somewhat functional. I still think changes to crypto suites might explain the problem, but I’m not sure where to start investigating that. I can use Wireshark for basic things, but I feel like we’re moving out of that realm.

At any rate, thanks for your continued assistance and suggestions. I’ve been a fan for many years, ever since the early SBS days.

Reply | Quote

I had written a reply to this, but got interrupted, and lost the text.

Some of the SMBv1/CIFS functionality is there. I can browse the network, but I cannot access shared resources. I don’t know whether I can browse from the Windows XP client to the Windows 2012 R2 server. It’s not part of my use case. Browsing from up-level (Windows 2012 R2, Windows 10) clients to down-level (Windows XP) clients is indispensable.

The Windows XP clients exist because they support unique hardware. Some of them started out as Windows 2000 clients; I was able to upgrade to Windows XP, but no further (mostly driver issues). Replacing the hardware with exact functional equivalents is not possible.

When attempting to access the Windows XP client, I get a dialog box:

Windows cannot access \\TRY-Client-WXP

Details: Error code: 0x80070035 /The network path was not found.

Thanks for your help. I really do appreciate your time.

Reply | Quote

https://www.drivereasy.com/knowledge/error-code-0x80070035-the-network-path-was-not-found-solved/

Can you check the NTLM settings?

Susan Bradley Patch Lady

Reply | Quote

Aha moment!

I installed KB5022352 prior to following the troubleshooting steps at the link from your post. Step 2 suggests substituting IP address for name. It turns out that works!  It seems that (under some cases) name resolution fails. I added another client to the sandboxed network (Windows 7), since it prefers SMBv2 over SMBv1, and I wanted another data point for testing.

I can successfully ping the Windows XP client by IP address (with -a to check reverse DNS), Netbios name, and FQDN in cmd.exe from both Windows Server 2012 R2 and Windows 7.

I can successfully ping the Windows 7 client by IP address (with -a to check reverse DNS), Netbios name, and FQDN in cmd.exe from both Windows Server 2012 R2 and Windows XP.

I can successfully ping the Windows 2012 R2 server by IP address (with -a to check reverse DNS), Netbios name, and FQDN in cmd.exe from both Windows 7 and Windows XP.

Launching File Explorer on Windows 7 and browsing by IP address allows access to the shared network resource on the Windows XP client.

Launching File Explorer on Windows 7 and browsing by name fails to access the shared network resource on the Windows XP client.

Launching File Explorer on Windows Server 2012 R2 and browsing by IP address allows access to the shared network resource on the Windows XP client.

Launching File Explorer on Windows Server 2012 R2 and browsing by name fails to access the shared network resource on the Windows XP client.

Just for completeness, launching File Explorer on Windows XP successfully allows access to shared network resources on the Windows XP client, the Windows 7 client, and the Windows Server 2012 R2. Unfortunately, this does not align with my use case.

I have searched for discussions of this behavior. The most cited causes seem to be corrupt credentials databases, domain time sync failures, and DNS failures. The Windows 2012 R2 server and Windows 7 client show empty credential databases. The Windows XP client does not appear to have a credential database. There are no time sync issues. Netbios names are registered correctly, according to nbtstat. DNS issues would cause ping by name to fail or ping by IP with -a to show an incorrect name.

Conclusion: It appears that under fairly narrow circumstances, name resolution for SMBv1 resources fails. I will need to think about the operational changes needed to accept these updates in my environment.

In the meantime, further suggestions or thoughts are always welcome. Thanks!

Reply | Quote

“It’s always DNS” as they say.

Have you tried ensuring that the network location service is static/turned on?

Susan Bradley Patch Lady

Reply | Quote

On an XP that would be browser service/browse master service I think? (too many years away from an XP)

Susan Bradley Patch Lady

Reply | Quote

On Windows XP, the Computer Browser service is set to automatic, and started. Network Location Awareness is also set to automatic and started (if memory serves it’s needed for Kerberos).

 

Reply | Quote

Sigh…

I wish it were so – Windows DNS is pretty simple to configure and troubleshoot, at least for a three node network. I’ve reviewed the Directory Service and DNS server logs; double checked DHCP (dynamic DNS updates); and spent some quality time with nslookup on each of the three nodes. DNS is configured and working correctly. This update breaks something – not the first time.

Thanks

Reply | Quote

https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server

Can you run that powershell on the server and see what SMB is running? Also check ntlm?  https://dirteam.com/sander/2022/06/15/howto-detect-ntlmv1-authentication/

Susan Bradley Patch Lady

Reply | Quote