This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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



This thread was automatically locked due to age.
Parents Reply Children
  • 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?

    Regards,

    Thorsten

    ---------------------------------------------------------------------

    Using Sophos XG or UTM with Wifi Hotspot and Password of the Day?
    Try our FREE Password of the Day APP!

    For Sophos UTM
    Apple iOS: https://apple.co/1YzD2vU
    Google Android: https://bit.ly/23ELyRq
    For Sophos XG
    Apple iOS: https://appsto.re/de/aZjTdb.i
    Google Android: https://bit.ly/2bbimf1
  • 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.

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

    Regards,

    Thorsten

    ---------------------------------------------------------------------

    Using Sophos XG or UTM with Wifi Hotspot and Password of the Day?
    Try our FREE Password of the Day APP!

    For Sophos UTM
    Apple iOS: https://apple.co/1YzD2vU
    Google Android: https://bit.ly/23ELyRq
    For Sophos XG
    Apple iOS: https://appsto.re/de/aZjTdb.i
    Google Android: https://bit.ly/2bbimf1
  • 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"

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

    -------------------------------

    Interesting [in-ter-uh-sting, -truh-sting, -tuh-res-ting]

    A word typically used by IT technicians to describe an issue they didn't expect, or never encountered, and don't know how to fix.

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

  • 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

    -------------------------------

    Interesting [in-ter-uh-sting, -truh-sting, -tuh-res-ting]

    A word typically used by IT technicians to describe an issue they didn't expect, or never encountered, and don't know how to fix.

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

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

  • 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

    -------------------------------

    Interesting [in-ter-uh-sting, -truh-sting, -tuh-res-ting]

    A word typically used by IT technicians to describe an issue they didn't expect, or never encountered, and don't know how to fix.