Что могло бы заставлять LDAP отказываться от соединений от некоторых, но не всех источников? (не брандмауэр)

Я перемещаю серверы в новую инфраструктуру и должен настроить LDAP снова. Это не используется для доступа к серверу, скорее как репозиторий пользователей с нашего веб-сайта, к которому получит доступ наша платформа BI.

LDAP в порядке, и я могу соединить и связать использование Администратор LDAP от моего компьютера в офисе, никаких заботах.

То, что я не могу сделать, заставляют Drupal (на том же сервере) или YellowFin (JAVA-приложение на другом сервере тот же кластер) связывать. Я вполне уверен, они соединяются, но не связывают, и я использую точно те же учетные данные во всех трех местах.

Единственная ошибка, которую я получаю от Drupal:

Failed to bind to server. ldap error #82 Success

От Yellowfin существует немного больше информации (я думаю; идентификация отредактированных данных):

  YF:2015-05-08 01:54:26:DEBUG (LDAPUtil:createConnection) - Opening connection to xx.xx.xx.xx on port 636
  YF:2015-05-08 01:54:26:DEBUG (JNDILDAPProvider:authenticate) - Connecting: ldaps://xx.xx.xx.xx:636
  YF:2015-05-08 01:54:26:DEBUG (JNDILDAPProvider:authenticate) - User: cn=admin,dc=xxxxxxxxxxx,dc=com,dc=au
  YF:2015-05-08 01:54:26:ERROR (LDAPUtil:createConnection) - LDAP authentication failed
  YF:2015-05-08 01:54:26:ERROR (LDAPUtil:createConnection) - LDAP authentication failed
  YF:2015-05-08 01:54:26:ERROR (LDAPUtil:testConnection) - LDAP connection failed
  YF:2015-05-08 01:54:26:DEBUG (DSTCache:getJavaTimeZoneID) - Invalid TimeZoneCode passed. Value was ASIA/ABU_DHABI
  YF:2015-05-08 01:54:27:DEBUG (MIImageAction:execute) - MIImageAction entered

Я задаюсь вопросом, является ли ошибка часового пояса проблемой, возможно?

slapd сервис прислушивается ко всему дюйм/с на порте 636, релевантный netstat результаты:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:636             0.0.0.0:*               LISTEN      9150/slapd
tcp6       0      0 :::636                  :::*                    LISTEN      9150/slapd

Мы используем AWS, и я попытался открыть группу безопасности (брандмауэр) полностью на порте 636 без результатов.

ldap.conf похож на это:

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE    dc=intermedium,dc=com,dc=au
#URI    ldap://ldap.example.com ldap://ldap-master.example.com:666
URI ldap://127.0.0.1 ldaps://xxxxxxxxxxxxxxxxx

#SIZELIMIT  12
#TIMELIMIT  15
#DEREF      never

TLS_CACERTDIR   /etc/openldap/certs
  TLSCACertificateFile /etc/pki/tls/certs/xxxxxxxxxxxxxxxxx.ca-bundle
  TLSCertificateFile /etc/pki/tls/certs/xxxxxxxxxxxxxxxxx.crt
  TLSCertificateKeyFile /etc/pki/tls/certs/xxxxxxxxxxxxxxxxx.key
TLS_REQCERT allow
REFERRALS off

# Turning this off breaks GSSAPI used with krb5 when rdns = false
#SASL_NOCANON   on

slapd.conf похож на это:

# OpenLDAP server configuration
# see 'man slapd' for additional information

# Where the server will run (-h option)
# - ldapi:/// is required for on-the-fly configuration using client tools
#   (use SASL with EXTERNAL mechanism for authentication)
# - default: ldapi:/// ldap:///
# - example: ldapi:/// ldap://127.0.0.1/ ldap://10.0.0.1:1389/ ldaps:///
SLAPD_URLS="ldapi:/// ldaps:///"

# Any custom options
#SLAPD_OPTIONS=""

# Keytab location for GSSAPI Kerberos authentication
#KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab"

Я был бы очень благодарен за любой совет.