Customers might be unable to connect with us via the Sophos Malaysia Support Hotline number. Our teams are actively working on a fix. In the interim, we request customers to use the backup hotline number - +65 3157 5922 (Singapore) or raise a support request at https://support.sophos.com/.

Help us enhance your Sophos Community experience. Share your thoughts in our Sophos Community survey.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 4 subscribers
  • Views 6280 views
  • Users 0 members are here
Options
Suggested
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

Recipient verification fails with ldaps

hagman_01
When my UTM tries to verify inbound mail recipients against Active Directory, I find this in smtp.log:

Warning: ACL "warn" statement skipped: condition test deferred: failed to bind the LDAP connection to server 10.0.0.5:3269 - ldap_bind() returned -1



This is weird because both connectivity tests for the auth server return "OK". What can be the problem?


This thread was automatically locked due to age.
Parents
  • 0
    It a know issue i think :


    ID24065 9.004 Regression from V8: Recipient Verification against AD not working with LDAP-SSL
    ------------------------------------------------------------------------
    Description:  SMTP recipient verification against AD is not working with
                  LDAP-SSL.
    Workaround:   Option 1: Switch to non encrypted LDAP connections or
                  recipient verification with callout.
                  
                  Option 2: Add the following line to
                  /var/chroot-smtp/etc/openldap/ldap.conf
                  
                  TLS_REQCERT allow
                  
                  According to ldap.conf(5) - Linux man page :
                  
                  TLS_REQCERT 
                                Specifies what checks to perform on server
                  certificates in a TLS session, if any. The  can be
                  specified as one of the following keywords:
                  ...
                  allow
                    The server certificate is requested. If no certificate
                  is provided, the session proceeds normally. If a bad
                  certificate is provided, it will be ignored and the
                  session proceeds normally.
    Fixed in:
  • 0 in reply to brassardv

    Why isn't this fixed until now? Same bug in 9.510-5

Reply Children
Unfiltered HTML