[Bug?] Sophos UTM forgets Bind DN password

Hello. I have the strangest problem with our UTM (9.408-4): it does not save the password to bind to LDAP. If I enter the right password and test, everything is fine; but if I save and come back, I get the message "Error: Server exists and accepts connections, but bind to ldap://1.2.3.4:389 failed with this BindDN and password."

I can reenter the password and it will work again, but not after saving. As I have about 20 server entries, this is very annoying whenever I need to test VPN authentication. Quid?

 

Edit: This does not happen on my older Sophos UTMs (9.407-3), only on those updated to 9.408-4, so I am assuming this is a bug in the latest build.

  • In reply to J.Janssens:

    I am experiencing this bug even though my UTM is running the latest firmware, version 9.409-9.  Hopefully this bug will be fixed with the next firmware update.

  • any updates about this case guys !!

    this really annoying...

  • In reply to Sabry Salem:

    I found the latest update did fix this problem for me, but I had to completely delete the existing AD server first from:

    Definitions & Users > Authentication Services > Servers tab

    Then once I re-added the server all was well.

    Let me know if this helps you.

  • This is still an issue for me on 9.409-9

    Even after deleting and recreating the Active Directory entry in Authentication Services > Servers.

  • In reply to CharlieOsborne:

    Do you use a dedicated AD-User for authentication-requests against the AD?

    Is maybe the User blocked in AD?

    What happens when you use domain-admin credentials?

  • In reply to ThorstenSeiler:

    It is exactly as described in the OP. When editing the adirectory authentication server entry testing ANY account fails until you reenter the bind password then tests with valid accounts are successful until you hit save, after which all tests fail again.
    When the tests fail and when actually trying to authenticate as an AD user in both cases the authentication log says: Bind failed for <Bind DN>.
    The results are the same whether you use UPN or LDAP notation in the Bind DN.

    ThorstenSeiler - Thanks for the response, Yes the Bind DN is a domain admin and the account is not locked out.
    Edit: To be thorough I have tried multiple different accounts in the Bind DN all with the same results.

    In case it's relevant this is a software appliance (as stated above running 9.409-9)
    Edit: I have now also tested this on an SG125 hardware appliance also running 9.409-9 against a different AD with the exact same results. This issue has definitely NOT been resolved in the latest release.

  • In reply to CharlieOsborne:

    Hmm... have serveral Virtual Appliances as well as UTM's and SG's on various customers Sites.

    We had the Issue with .408 but I can say it's gone on every Site with .409...

    Have you deleted the AD-Server and recreated it from scratch? J.Rivett mentioned above, he had to recreate those entries as well...

  • In reply to ThorstenSeiler:

    We've got 2 Sophos UTM 220 in HA mode. I ran into the exact same issue with 9.407-3. After updating to 9.409-9 the issue is still present.

     

    I tried with a dedicated user with just "authenticated users" permission (which normally shoud be sufficient) and also with domain admin. I also deleted the authenticaton server object and recreated from scratch.

     

    Still getting "Error: Server exists and accepts connections, but bind to ldap://xxx.xxx.xxx.xx:389 failed with this Bind DN and Password"

  • In reply to Oliver Yüzer:

    For what it's worth, I was running 9.408-4 (2 UTM's in HA) and was having this exact same problem.  Yesterday I upgraded to 9.409-9 and the problem went away.

  • In reply to candal02:

    Same problem here. Version 9.409-9 and re-adding the server changes nothing.

  • In reply to david behr:

    Firmware version 9.410-6 was very recently released.  In the release notes, one of the bug fixes (see snip below) may resolve this problem.  Maybe someone from Sophos can confirm?

     

    Fix [NUTM-6356]: [WebAdmin] AD User Test fails after first creation of an authentication server

  • In reply to candal02:

    Updated to 9.410-6. Problem is still unsolved.

    It's quite annoying since we have plenty users remotely connecting from outside. Now I had to create a local login inside the UTM for every user instead of using the AD users. Plus guiding every user trough the process of downloading and installing the remote connection tool again.

  • In reply to candal02:

    I can confirm that 9.410-6 has fixed this issue for me on the handful of UTMs I have tested this morning.

    I did not have to recreate the authentication server entry either.

  • In reply to Oliver Yüzer:

    Interestingly enough, the latest release 9.411-3 seems to have the same "fix" that was in release 9.410-6 (see snip below taken from 9.411-3 release notes).  Not sure why that is.  Maybe 9.411-3 is an amalgamation of 9.410-6 and a few other bug fixes.  That would seem likely, as my UTM running 9.409-9 doesn't even see 9.410-6 as an update.  I can only upgrade straight to 9.411-3  Anyway, maybe you can try upgrading to see if this release helps?  Please know I don't work for Sophos.  I'm only reporting what I see in the release notes.  Hope this works out for you soon.

    Fix [NUTM-6356]: [WebAdmin] AD User Test fails after first creation of an authentication server

  • In reply to candal02:

    Now I finally managed to connect to the authentication server. I'm not sure if this was really the issue but however; this is what I've done:

    Our Active Directory Servers are Windows Server 2016 with Security Compliance Manager (SCM) Baselines for Windows Server 2016 Domain Controllers. These baseline policies enforce LDAP server signing (Computer Configuration --> Policies --> Windows Settings --> Security Settings --> Local Policies --> Security Options --> Domain Controller: LDAP server signing requirements - Require signing)

    So I changed the authenticaton server in UTM to use SSL and the port to 636. Now I can connect to the authentication server.