After updating to 9.501-5 SSO for HTTP authentication failed and domain join not working.

UTM 9.501-5

Windows server 2012 domain controller.

I installed the 9.5 update on June 2, did not see any issues with this for the client, updated to 9.501-5 on June 12 midnight, and Internet access is failing on multiple sites.

Can get to Google.ca

Cannot get to canada411.com - Too many http redirects message.

Turned off web filtering and the websites were available - but the client requires filtering.

Re-enabled and turned off AD SSO authentication and websites are available again with correct content being blocked.

Attempted to remove from and rejoin domain, but domain join failed.

 

Currently, I have the client functioning, but, I need to rejoin AD and resume SSO authentication.

 

  • In reply to Rodrigo:

    I've installed 9.502 yesterday and rejoined domain. SSO authentication was still working this morning...

    ...but only in proxy mode, transparent mode with SSO is broken.

  • In reply to Gabriele Martino:

    So far all good here. I installed 9.502 last night. Rejoined with wrong password and then rejoined AD with correct password. No messing with object in ADUC. Then re-enabled Active Directory SSO on the networks in Tranparent Mode.

    When the problem started all I ended up doing was set the Default Authentication method to "none" and then change my "Unlimited internet access" policy to include all users. Now all users was getting used to having unlimited internet access and they were disappointed to have limited access this morning, but no auth problems :)

    All my networks are in Transparent Mode.

    Only Session Host Servers have proxy set in Internet Settings via GPO

    Haven't had any issues today on any machines so all seem to be working just fine.

    I did however reboot all servers including DCs last night.

  • In reply to Dennis Potenberg:

    In HA, changes at the command line must be made to both devices.  Apparently, you're now working on what was the Slave when you changed /etc/crontab-static.  Just do the same thing on the current Master and you'll be good to go on either device.

    Cheers - Bob

  • In reply to Gabriele Martino:

    We have been told there is an issue with complex passwords which will be fixed in 9.503 (and now I'm awaiting release date information.)

  • In reply to Stevoon:

    Do you know what the definition of "complex" is related to this error? Just special characters or problems with upper/lower/numbers/length?

  • In reply to TimBoggs:

    The email I got suggests using just an alphabetic password.  Certainly a mixed case alphanumeric password fails in our testing.

  • In reply to Stevoon:

    With basic AD complexity enabled, almost everyone's accounts should be failing. I would think this would be huge if it affected everyone.

    I have 9.500 running on one UTM and have had no apparent issues. It was never offered to my other two UTM's and I actually need some of the new 9.5 functionality to complete a project. I am not imbued with confidence.

  • I can confirm, that https-request with AD-Auth still failing with 9.502, http-request are working correctly with AD-Auth

    Proxy runs in standard mode with AD-Auth.

    Tried SSO re-join (+deleting of Sophos AD-Object), Rebooting and also using older UTM Backupfile...

     

    Sophos support case is open...

     

    regards

  • In reply to SWeissflog:

    That sounds semi familiar to me.  Are your passwords complex?

  • In reply to SWeissflog:

    Hi SWeissflog,

     

    does a https request even fail, when you make a "http only" request before/first? I do not now how far the information also applies to standard mode AD SSO: https://community.sophos.com/kb/en-us/120791 (But as Sophos is pretty careless sometimes when it comes to documentation, I don´t know, if this limitations still exist)

     

    But I think the behaviour now is different as it was before...?!

     

    Regards

    Sebastian

  • In reply to roesch4alc:

    http is working -> you can see the username in webfilter log

    https on the same machine with the same user is not working -> error code 407 and no authdata for the user

     

    Your linked information only applies for transparent mode...(I did already know this fact)

     

    regards

  • In reply to SWeissflog:

    Interesting, this should impact many users with your version number....

  • In reply to roesch4alc:

    Either that or a lot of people are holding off waiting for the all clear. I must say this is disappointing to hear and I will definitely hold off. However it does seem there might be a combination of settings/environment that could be causing the problem.

  • In reply to SWeissflog:

    Hello,

    http and https with AD SSO authentication are working for me after upgrading to 9.502.

    I'm using standard mode.

    "Block access on authentication failure" is also checked.

    In webFilter, I see that some requests are getting 407 response with no authentication data, then immediately resent from the client with authentication data and get 200 response. This was always the case for me and it happens for http and https requests.

    My understanding is that the browser on the client side always tries to pass without authentication first, then retries with the authentication when he gets 407.

    Again, as far as I can remember, this was always the case for me, so after upgrading to 9.502, things returned to "normal".

  • In reply to SIBTEL:

    Hello Sibtel,

     

    SIBTEL
    In webFilter, I see that some requests are getting 407 response with no authentication data, then immediately resent from the client with authentication data and get 200 response. This was always the case for me and it happens for http and https requests.

     

    I can confirm what you say, this behaviour is normal. I can remember, that somewhere (either I read it or somebody told it to me) , that the logging behaviour of the 407 messages in http.log was changed, maybe in v9.2. or 9.3... They changed it, for auth. troubleshooting purposes (afaik).

     

    BR