Bonjour,
J'ai un soucis de connexion entre un ldap esclave et un maître. Visiblement un soucis TLS, pourtant un openssl s_client passe sans aucun problème.
Dans syslog: slap_client_connect: URI=ldaps://bling.blang.com DN="cn=admin,dc=blang,dc=com" ldap_sasl_bind_s failed (-1)
Après avoir activé la verbosité de slpad: TLS: can't connect: (unknown error code). 5b6c57de slap_client_connect: URI=ldaps://bling.blang.com DN="cn=admin,dc=blang,dc=com" ldap_sasl_bind_s failed (-1) 5b6c57de do_syncrepl: rid=000 rc -1 retrying
Impossible après un long bras de fer avec slapd d'avoir le dessus.
Et un appel à la même URI via ldapsearch fonctionne : ldapsearch -H ldaps://bling.blang.com -D cn=admin,dc=blang,dc=com -w secret
Quelqu'un aurait une idée ?
Merci. François
Bonjour,
Verifie que le RID est bien distinct entre les deux membres. Verifie tes certificats (DN dans le certif matchant le DN remonté par le DNS record Verifie si le hash que tu as employé est supporté (j'ai souvenir que certaines variantes de SHAXXX posaient pb à une époque)
My two ...
On Thu, 9 Aug 2018 17:12:02 +0200 François Poulain fpoulain@metrodore.fr wrote:
Bonjour,
J'ai un soucis de connexion entre un ldap esclave et un maître. Visiblement un soucis TLS, pourtant un openssl s_client passe sans aucun problème.
Dans syslog: slap_client_connect: URI=ldaps://bling.blang.com DN="cn=admin,dc=blang,dc=com" ldap_sasl_bind_s failed (-1)
Après avoir activé la verbosité de slpad: TLS: can't connect: (unknown error code). 5b6c57de slap_client_connect: URI=ldaps://bling.blang.com DN="cn=admin,dc=blang,dc=com" ldap_sasl_bind_s failed (-1) 5b6c57de do_syncrepl: rid=000 rc -1 retrying
Impossible après un long bras de fer avec slapd d'avoir le dessus.
Et un appel à la même URI via ldapsearch fonctionne : ldapsearch -H ldaps://bling.blang.com -D cn=admin,dc=blang,dc=com -w secret
Quelqu'un aurait une idée ?
Merci. François
-- François Poulain fpoulain@metrodore.fr
Liste de diffusion du FRsAG http://www.frsag.org/
ADDENTUM: Verifie si ta version d'OpenLDAP utilise OpenSSL ou GNUTLS. Et teste avec option: tls_cipher_suite=NORMAL (juste pour debug)
On Thu, 9 Aug 2018 17:45:02 +0200 Erik LE VACON erik@levacon.net wrote:
Bonjour,
Verifie que le RID est bien distinct entre les deux membres. Verifie tes certificats (DN dans le certif matchant le DN remonté par le DNS record Verifie si le hash que tu as employé est supporté (j'ai souvenir que certaines variantes de SHAXXX posaient pb à une époque)
My two ...
On Thu, 9 Aug 2018 17:12:02 +0200 François Poulain fpoulain@metrodore.fr wrote:
Bonjour,
J'ai un soucis de connexion entre un ldap esclave et un maître. Visiblement un soucis TLS, pourtant un openssl s_client passe sans aucun problème.
Dans syslog: slap_client_connect: URI=ldaps://bling.blang.com DN="cn=admin,dc=blang,dc=com" ldap_sasl_bind_s failed (-1)
Après avoir activé la verbosité de slpad: TLS: can't connect: (unknown error code). 5b6c57de slap_client_connect: URI=ldaps://bling.blang.com DN="cn=admin,dc=blang,dc=com" ldap_sasl_bind_s failed (-1) 5b6c57de do_syncrepl: rid=000 rc -1 retrying
Impossible après un long bras de fer avec slapd d'avoir le dessus.
Et un appel à la même URI via ldapsearch fonctionne : ldapsearch -H ldaps://bling.blang.com -D cn=admin,dc=blang,dc=com -w secret
Quelqu'un aurait une idée ?
Merci. François
-- François Poulain fpoulain@metrodore.fr
Liste de diffusion du FRsAG http://www.frsag.org/
-- Erik LE VACON erik@levacon.net _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le Thu, 9 Aug 2018 17:12:02 +0200, François Poulain fpoulain@metrodore.fr a écrit :
Quelqu'un aurait une idée ?
Pour info la solution venue par MP.
François
Verifie tes certificats (DN dans le certif matchant le DN remonté par le DNS record
Merci c'était bien ça. Nous avions un wilcard et ça pas marchait.
Le serveur (maître) doit présenter un certificat dont le CN porte explicitement le fqdn du serveur (le wildcard n'étant pas bienvenu). Cf http://www.openldap.org/doc/admin24/tls.html#Server%20Certificates
16.1.1. Server Certificates
The DN of a server certificate must use the CN attribute to name the server, and the CN must carry the server's fully qualified domain name. Additional alias names and wildcards may be present in the subjectAltName certificate extension. More details on server certificate names are in RFC4513.
-
Erik LE VACON -
François Poulain