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

  • Hi,

    Run adsiedit.msc in the command prompt for AD, to review the schema of Active Directory.Check that the Bind DN configuration is proper. Do you discover any error in the aua.log. Make sure the time and date difference between UTM and AD is not greater than 5 minutes. 

    Hope that helps.

  • In reply to sachingurung:

    As I said: when re-entering the password the test completes successfully. This wouldn't happen if the DN was wrong. This only happens on devices with the latest update, not with the previous update. Domain and UTM have no time difference. Also the bind DN is correct and aua.log only shows the obvious:

    [saved password]
    2016:11:22-15:00:59 br00m64euf-1 aua[18666]: id="3006" severity="info" sys="System" sub="auth" name="Bind test request: adirectory"
    2016:11:22-15:01:00 br00m64euf-1 aua[18666]: id="3006" severity="info" sys="System" sub="auth" name="Bind test failed. Method: adirectory, error: DENIED
    2016:11:22-15:01:00 br00m64euf-1 aua[18666]: Server exists and accepts connections, but bind to ldap://172.22.0.72:389 failed with this Bind DN and Password"
    2016:11:22-15:01:03 br00m64euf-1 aua[18689]: id="3006" severity="info" sys="System" sub="auth" name="Spawned child for authentication test"
    [manually re-entered password]
    2016:11:22-15:01:03 br00m64euf-1 aua[18689]: id="3006" severity="info" sys="System" sub="auth" name="Bind test request: adirectory"
    2016:11:22-15:01:03 br00m64euf-1 aua[18689]: id="3006" severity="info" sys="System" sub="auth" name="Bind test successfull. Method: adirectory"
     
  • In reply to J.Janssens:

    Hi,

    Thanks for the log lines. In the logs aua id:3006 means information message from the aua demon.

    2016:11:22-15:01:00 br00m64euf-1 aua[18666]: Server exists and accepts connections, but bind to ldap://172.22.0.72:389 failed with this Bind DN and Password"
     
    For the error shown, the Domain Controller/LDAP Server does not support the 'LDAP_Simple_ Bind' request that the UTM uses to connect to it. The UTM uses 'LDAP_Simple_ Bind' requests to connect to it and pull user/group information. You'll need to modify the Domain Controller security settings to support this type of authentication:
     
    On the AD, 
    1. Run  gpedit.msc

    2. In the Group Policy Object Editor, select the following:
      'Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options'

    3. In this section, search for the following entries:
    • Domain Controller: LDAP Server signing requirements
    • Network security: LDAP Client signing requirements
    1. To enable simple binds, set the above as follows:
    • Domain controller: LDAP server signing requirements = None
    • Network security: LDAP client signing requirements = Negotiate

    If your security policies require that the LDAP server signing requirements remain enabled, then please ensure that SMB signing is also enabled in Active Directory. This allows the UTM to connect using SSL.

    Once SMB Signing is enabled in Active Directory, ensure that SSL is enabled and that you are connecting to the Global Catalog Server over port 3269 in the UTM authentication server configuration settings.

    Hope that helps.

     
  • In reply to sachingurung:

    Please explain to me why it works when manually re-entering the password if it was an issue on the AD side, let alone if a handful of other UTMs with an older firmware do not have this problem, even though they connect to exactly the same DCs. Also this problem happens in an AD site that has been running with Sophos for years without issues until the last update.

     

    As this is a business environment and not a home scenario, I will escalate this with our Sophos reseller.

  • I too have the same problem with 9.408-4.

    Step to reproduce.

    1. Enter the AD details (Don't Save yet)

    2. Click Test. Reply will be "Server test passed"

    3. Click Save

    4. Edit the profile again

    5. Click Test (An error will appear)

    6. Type again the bind password

    7. Click Test (Server test passed)

    Something in Sophos is definitely broken.

    Please fix asap.

  • In reply to John Homer Alvero:

    Thank you. I hope this thread will get some more attention now.

  • In reply to J.Janssens:

    Hi,

    In that case, please report this to the Support Team and provide me the case#. Meanwhile, did you tried my suggestion and does that help?

    Thanks

  • In reply to sachingurung:

    Same Problem here on all UTM's with new Firmware. DC's are from 2008-2012R2 - all causing the same problem.

     

    Edit: - the values are already set.

  • I too am experiencing the same issue with firmware 9.408-4.

     

  • The same problems with firmware 9.408-4

  • In reply to ISASKSTT:

    I can confirm that this problem exists on several UTM's after 9.408-4 update.

    Opened a support case.

  • Hi All,

    The issue is fixed in the next firmware release. The JIRA ID for this bug is NUTM-5888.

    Thanks

  • In reply to sachingurung:

    Thanks

     

    Do we have a date for this?

  • I was beginning to think I was losing my mind.  Glad to know this is not just me!

    Do we have a date for the fix yet?

    Thanks!

  • In reply to J.Rivett:

    I'm happy to see it's finally acknowledged that this is a bug.