O que pode estar causando o LDAP a recusar conexões de algumas, mas não de todas as fontes? (não firewall)

Question

Estou migrando servidores para uma nova infraestrutura e preciso configurar o LDAP novamente. Ele não está sendo usado para acessar o servidor, e sim como um repositório de usuários do nosso site para ser acessado pela nossa plataforma de BI.

O LDAP está ativo e em execução e eu posso conectar e ligar usando o LDAP Administrator do meu computador no escritório, não se preocupe.

O que não posso fazer é obter o Drupal (no mesmo servidor) ou o YellowFin (aplicativo java no servidor diferente do mesmo cluster) para vincular. Tenho certeza de que eles estão se conectando, mas não vinculados, e estou usando exatamente as mesmas credenciais em todos os três lugares.

O único erro que recebo do Drupal é:

Failed to bind to server. ldap error #82 Success

De Yellowfin há um pouco mais de informação (eu acho; dados de identificação redigidos):

  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

Eu estou querendo saber se o erro de fuso horário é um problema, talvez?

O serviço slapd está escutando todos os IPs na porta 636, resultados relevantes de 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

Estamos usando a AWS e tentei abrir o grupo de segurança (firewall) completamente na porta 636 sem resultados.

ldap.conf tem esta aparência:

# 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 tem esta aparência:

# 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"

Eu ficaria muito grato por qualquer conselho.

    

Answer 1

Muito obrigado a @strongline e @Craig Miskell por me apontar em uma direção, no final foram dois erros diferentes que eu irei colocar aqui caso alguém ache isso útil.

Drupal:

A ligação estava falhando porque o site de origem tinha a criptografia Blowfish ativada e o servidor de destino não tinha o mod php-mcrypt instalado, embora eu tenha atualizado a senha que ainda estava tentando usar a criptografia Blowfish para a senha de conexão. A instalação do php-mcrypt corrigiu isso.

YellowFin (Java):

O YellowFin precisava do certificado e da cadeia do servidor LDAP em um Keystore Java. Para corrigir, encontre ou faça um certificado para o servidor LDAP e siga as instruções em esta resposta de estouro de pilha .

    

Answer 2

Com relação ao problema de fuso horário com o aplicativo Java, não deixe que o Kava determine seu próprio fuso horário no Linux. Use TZ em vez disso. Eu escrevi sobre isso ainda em link