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

Since installing the ms17-10 updates yesterday and disabling SMBv1 on domain controllers, I've got 3 customers now with proxy authentication issues. Seems to  much of a coincidence for them to have problems at the same time and not have it related to the SMB protections against the WannaCry ransomware.

  • Hi James,

     

    Im also seeing this happening on our site now.

    Was scratching my head trying to figure out why the proxy would just stop working - but yes we have just installed the MS17-10 updates and also disabled SMB1.0 as per the WannaCry preventions.

     

    Currently ive enabled all users internally - so that internet access is not stopped - however that will grant access to users that wouldnt normally  have it.

    Hoping for a quick fix here - or do we need to re-enabled SMB1.0 again  (which goes against everything MS say).

  • 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.

  • In reply to Adam Beardwood:

    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.

  • In reply to darrellr:

    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.

  • In reply to JamesGolden:

    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.

  • In reply to Adam Beardwood:

    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.

  • In reply to Adam Beardwood:

    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.

  • In reply to darrellr:

    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.

  • In reply to JamesGolden:

    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.

  • In reply to Adam Beardwood:

    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

  • In reply to BAlfson:

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

  • In reply to Adam Beardwood:

    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

  • In reply to BAlfson:

    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.

  • In reply to BAlfson:

    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.

  • In reply to darrellr:

    I just spent some time poring over the Known Issues List (n the Knowledgebase section of this forum).

    Issue NUTML-11979 was first reported against version 9.105, but appears to still be applicable:   UTM cannot talk to a Read Only domain controller.

    Hopefully that will save you some frustrating failed tests.