Alguns sistemas não podem se conectar ao ldap via ldaps, mas outros podem, é o certificado curinga?

Ao tentar fazer conexões ldaps com o servidor Novel eDirectory 8.8, às vezes tenho que colocar TLS_REQCERT nevero arquivo ldap.conf dos servidores clientes. Obviamente, essa é uma má ideia.

O comando que eu executo é algo assim com credenciais que realmente funcionam ...

ldapsearch -x -H ldaps://ldapserver -b 'ou=active,ou=people,dc=example,dc=org' -D 'cn=admin,dc=example,dc=org' -W "cn=username"

No Ubuntu 13.10, ele funciona bem.

No SLES, ele funciona bem.

No CentOS 6.5, ele retorna:

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

Agora, o certificado que importei é um certificado curinga adquirido da DigiCert. Meu colega de trabalho encontrou alguns relatórios indicando que alguns sistemas têm problemas com caracteres curinga.

Então, o certificado curinga é o culpado? Se sim, como faço para corrigir isso?

Se não é o certificado curinga, o que é?

Seguindo a sugestão de Andrew Schulman, adicionei -d1ao meu comando ldapsearch. Aqui está o que eu acabei com:

ldap_url_parse_ext(ldaps://ldap.example.org)
ldap_create
ldap_url_parse_ext(ldaps://ldap.example.org:636/??base)
Enter LDAP Password: 
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.example.org:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.225.0.24:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: certdb config: configDir='/etc/openldap' tokenDescription='ldap(0)' certPrefix='cacerts' keyPrefix='cacerts' flags=readOnly
TLS: cannot open certdb '/etc/openldap', error -8018:Unknown PKCS #11 error.
TLS: could not get info about the CA certificate directory /etc/openldap/cacerts - error -5950:File not found.
TLS: certificate [CN=DigiCert High Assurance EV Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US] is not valid - error -8172:Peer's certificate issuer has been marked as not trusted by the user..
TLS: error: connect - force handshake failure: errno 2 - moznss error -8172
TLS: can't connect: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Pelo que diz, o CentOS não confia no DigiCert? Ou o CentOS não possui uma lista de emissores confiáveis?

ssl-certificate ldap edirectory

— David R.
fonte

"Não é possível entrar em contato com o servidor LDAP" parece mais que o servidor simplesmente não está acessível a partir dessa máquina cliente. Você verificou primeiro se realmente pode se conectar a ele? Por exemplo, telnet ldapserver ldapsou openssl s_client -connect ldapserver:636.

— Richard E. Silverman

Sim, confirmei que ele pode se conectar ao servidor. Afinal, nunca funcionaria se não pudesse se conectar.

— David R.

Você mencionou três hosts de clientes diferentes. O que não está funcionando pode ter sido incapaz de se conectar devido a um problema de rede, enquanto os outros poderiam.

— Richard E. Silverman

Eu pensei que meu post era bastante claro que eu estava editando o arquivo ldap.conf em todos os hosts. Como quando adicionei a linha ao arquivo, funcionou, mas sem a linha não funcionou. Portanto, não é um problema de conexão.

— David R.

Isso não ficou claro para mim quando li sua postagem inicialmente, apesar de entender o que você quer dizer agora. De qualquer forma, as informações de depuração do TLS que você adicionou mostram o problema; Adicionei uma resposta para acompanhar.

— Richard E. Silverman

Respostas:

O ldapsearch está procurando em / etc / openldap / cacerts seu repositório de certificados CA confiáveis, e que aparentemente não está configurado e, portanto, está rejeitando o certificado, pois não pode construir uma cadeia de confiança para ele. Se o ldapsearch estivesse usando o OpenSSL, ele precisaria de uma coleção de formatos "hashdir", como produzido por, por exemplo, o programa "authconfig" do Red Hat, ou um único arquivo com uma lista simples de certificados confiáveis. A referência aqui a "moznss" sugere que este ldapsearch é construído no Mozilla NSS; nesse caso, você precisa usar "certutil" para criar o db do certificado (ou melhor, apontar para o armazenamento de certificados NSS do sistema, se houver um) .

Nos sistemas em que está trabalhando, o ldapsearch deve ter um armazenamento de certificados em funcionamento, talvez porque esses pacotes OpenLDAP sejam construídos com o OpenSSL (ou talvez exista um armazenamento no estilo NSS disponível).

— Richard E. Silverman
fonte

Ah /etc/openldap/certsé onde fica a loja de certificados. Não cacerts. No /etc/openldap/ldap.conf, mudei TLS_CACERTDIR /etc/openldap/cacertspara TLS_CACERTDIR /etc/openldap/certse meu comando ldapsearch começou a funcionar. Obrigado!

— David R.

Eu tenho o ldapsearch instalado no Ubuntu 16.04 e não há diretório / etc / openldap.

— Vcardillo # 23/17

O ldapsearch dirá "Não é possível entrar em contato com o servidor LDAP" se não puder verificar o certificado TLS. Adicione -d1ao seu comando ldapsearch e verifique as linhas de saída que começam com "TLS:" para obter mais informações sobre se a conexão TLS está falhando e por quê.

— Andrew Schulman
fonte

Eu editei minha pergunta em resposta à sua sugestão. Obrigado!

— David R.

A solução depende da sua instalação:

Se você estiver usando um certificado inválido , poderá forçar a aceitação da configuração /etc/openldap/ldap.confcom
```
TLS_REQCERT allow
```
ou
```
TLS_REQCERT never
```
Se você estiver usando um certificado válido, provavelmente sua instalação ldap não sabe onde está o armazenamento de certificados CA confiáveis (provavelmente dependendo da instalação do OpenSSL). Depois, você pode tentar definir o local e forçar a verificação configurando /etc/openldap/ldap.confcom
```
TLS_CACERT /etc/openldap/cacert
TLS_REQCERT demand
```
/etc/openldap/cacertpode ser esse ou estar localizado em qualquer caminho. Ele deve conter a cadeia de certificados da sua CA. Pode ser um único arquivo com uma lista simples de certificados confiáveis.

Observe que os caminhos dependem do provedor ldap. Poderia ser /etc/ldapou /etc/openldapmais ou menos.

— Juan Garcia
fonte