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.

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.

This link is helpful because it acknowledhes that UTM AD SSO is highly dependent on SMB1.  However it insufficiently reviews the implications of running without SMB1.  Here is what I posted in reply.

This needs elaboration.   AD is also used for (at least) vpn client WAF, and User Portal,  including the linked local accounts for OTP.  AD SSO could be replaced by LDAP SSO using sAMAccountName as the attribute, but AD groups would need to be replaced with LDAP groups as well.  But I doubt that the link between local usernames and backend users would transfer at all to the LDAP backend server.  Without that, all OTP configurations are broken.

This link is helpful because it acknowledhes that UTM AD SSO is highly dependent on SMB1.  However it insufficiently reviews the implications of running without SMB1.  Here is what I posted in reply.

This needs elaboration.   AD is also used for (at least) vpn client WAF, and User Portal,  including the linked local accounts for OTP.  AD SSO could be replaced by LDAP SSO using sAMAccountName as the attribute, but AD groups would need to be replaced with LDAP groups as well.  But I doubt that the link between local usernames and backend users would transfer at all to the LDAP backend server.  Without that, all OTP configurations are broken.