Is anyone else seeing issues with proxy authentication and SMB v1 disabled on servers?

For some insane reason UTM has a dependency on SMB v1 for AD SSO - see Here

I'm not aware of any workaround other than leaving SMB v1 enabled on the DCs, which is frankly unacceptable.

Disable it on your global servers, then create a RO DC and leave it enabled there.  Cuts your risk down some but still allows the functionality needed for UTM.

Disable it on your global servers, then create a RO DC and leave it enabled there.  Cuts your risk down some but still allows the functionality needed for UTM.

With all due respect DarrellR, I'm not sure that would work. You need a writeable DC for a device to join the domain.  What I saw was that even on domains that the UTM had previously been joined to, SSO stopped worked as soon as SMBv1 was disabled. It doesn't seem to be a one-time need, but constant communication over SMBv1 to authenticate users.

Depending on exactly what they're doing with their SSO the RODC should just handle (or proxy) the auth requests once the join is sorted but it's still not exactly a great solution if you have a run a special DC just for UTM.

I agree - it's definitely not a good long-term solution, but it is better than leaving your global catalogs hanging in the breeze until Sophos addresses the issue.

But in the SSO config, there's no way to specify which DC to talk to. With multiple DCs, but only one RODC with SMBv1 enabled, wouldn't authentication be hit or miss depending on which DC it decided to contact?

I suppose you could only specify the RODC in the request routing for DNS, but then you would lose any redundancy for internal resolution.

I'm worried that they won't address it. The SMBv1 SSO configuration goes back to the ASG days. Sophos has had years, and multiple versions to fix this. Even the newest release, 9.5, still uses SMB1.

Put it and the UTM into their own AD site; that would (assuming UTM correctly uses the DC locator service) restrict the UTM to only using that DC as long as it's up and responding.

Like I said, not a great solution.

Guys, Sophos published a KnowledgeBase article on this yesterday: What to do if you decide to disable SMBv1 as a response to Wanna ransomware.

Cheers - Bob

Amazing, so their solution to a necessary and recommend security precaution breaking their products is to not use the bits that are broken.

I just noticed that you're new here, Adam - welcome to the UTM Community!

I heard something a bit different...

If you've applied security patches regularly, there is no exposure to leaving SMBv1 running.  I agree that they should have made fixing that in remote logging and AD-SSO a priority, and they admit as much in that article.  What they should also have mentioned in that article is that UTM also protects networks from similar exploits with five new Snort rules, two of which were added Friday and the others in the last two days (see V9 IPS Rules).

Cheers - Bob

Sure, there's no exposure to *this* vulnerability but SMB v1 is, at this point, ancient (like nearly 30 years old ancient), not very well-designed and likely to have more serious exploits found in the future. As it's only needed - from a Windows point of view - to support XP/2003 and older platforms it's an unnecessary risk to leave it enabled.

Microsoft have been recommending disabling SMB v1 for some time now and it's disappointing that a number of vendors (not just Sophos) still have dependencies on it.