Что может быть причиной того, что 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 прослушивает все IP-адреса на порту 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"

Буду очень признателен за любой совет.