Não é possível contactar remotamente o servidor LDAP a partir do Mac

Question

Estou tentando configurar um servidor LDAP com alguns parâmetros básicos de segurança, incluindo o TLS e a ligação autenticada obrigatória.

Eu iniciei o servidor e posso acessá-lo a partir do localhost com o comando:

ldapsearch -x -b 'dc=server,dc=com' 'objectclass=*' -W -D 'cn=manager,dc=server,dc=com' -H ldaps://server.com:389

Quando eu tento o mesmo comando remotamente, do meu computador, recebo a seguinte mensagem de erro:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Não sei por que isso acontece, posso fazer ping no meu servidor e, no momento, não há firewall.

slapd é lançado com -h ldaps://server.com:389/

O servidor DNS é configurado de maneira básica no mesmo servidor, com apenas um registro A.

Você tem alguma ideia?

EDITAR

Eu testei de outra estação de trabalho, no arch-linux, e funciona! Em ambos os computadores eu tenho TLS_REQCERT allow em /etc/openldap/ldap.conf , então isso não deveria ser um problema de certificado não?

A estação de trabalho na qual a consulta ldap não funciona está no Mac OS X, se isso tiver alguma importância.

Alguma saída:

Telnet:

telnet server.com 389

Trying w.x.y.z...
Connected to server.com.
Escape character is '^]'.

Iptables:

sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Netstat:

sudo netstat -lnt | grep 389

tcp        0      0 0.0.0.0:389             0.0.0.0:*               LISTEN     
tcp6       0      0 :::389                  :::*                    LISTEN  

Eu testei sem nenhum parâmetro de segurança e tenho o mesmo resultado.

    

Answer 1

Eu consideraria usar a porta padrão. Comece com -h ldap:/// . O LDAP suporta startTLS e pode ser facilmente configurado para exigir o TLS antes de passar informações confidenciais.

Telnet pode ser usado para determinar se você pode acessar o servidor. Experimente o comando telnet server.com ldap . Isso deve se conectar se o endereço do servidor estiver correto.

No servidor, você pode verificar se o LDAP está vinculado ao endereço externo usando o comando netstat -lnt | grep 389 . Isso mostrará em qual endereço você está ouvindo.

Quando o LDAP estiver funcionando sem o TLS, ative o startTLS e / ou adicione ldaps:/// à sua inicialização.

Você pode usar a opção security update_ssf=16 simple_bind=16 para exigir o TLS para essas operações. Os clientes podem se conectar à porta LDAP e passar para TLS usando a operação startTLS.

EDIT: Usando a depuração no cliente e / ou servidor pode ser útil para determinar onde a conexão está falhando. Adicione -d -1 à linha de comando para depurar tudo. O switch de depuração aceita um bitmap de sinalizadores de depuração para vários subsistemas. -d ? irá listá-los e seus valores. Uma vez que você sabe que um subsistema está funcionando, você pode parar a depuração e focar em outros subsistemas.

Iniciar a depuração com o cliente é mais fácil, mas pode ser necessário fazer alguma depuração no servidor. Se você está registrando via syslog, é útil ter um arquivo de log de depuração onde você pode examinar a saída de depuração.

    

Answer 2

Quando você usa um URL LDAP no formato ldaps://server.com:389 , o servidor espera que A negociação SSL terá lugar quando um cliente se conecta na porta %código%. StartTLS não pode ser usado em uma conexão SSL existente: StartTLS 'converte' (talvez promova seja uma palavra melhor) conexão insegura a uma conexão segura, portanto, já que 389 já está uma conexão segura, o StartTLS não pode ser usado. Seu servidor deve aceitar conexões de clientes de texto claro em ldaps://server.com:389 e rejeitar quaisquer conexões de cliente que não promova imediatamente o uso do StartTLS - se o seu produto de servidor não puder rejeitar imediatamente não seguro conexões do cliente, você deve escolher o produto que o gato. Se um terminal SSL também for necessário, o servidor deve escutar conexões seguras do cliente em ldap://server.com:389 .