[LDAP] Probleme de connexion
RésoluJ'ai fait la config de mon serveur OPEN LDAP et tout marchait bien j'usqu'a ces deux jours.
A la commande :
ldapsearch -b « dc=cnce, dc=ci» « dc=cnce »
Il me repond :
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
Pouvez vous m'aider ??
Configuration: LINUX CENTOS
26 réponses
Le problème porte sur une impossibilité de contacter le serveur LDAP après une configuration OpenLDAP sur CentOS, avec l’erreur ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) et des tentatives de ldapsearch. Des pistes sont explorées: vérification des ports 389 et 636, tests réseau et firewall, ajustements ldap.conf et hosts, et conseils sur ldapsearch avec -x. Finalement, la cause signalée est une erreur de syntaxe dans slapd.conf: un espace séparant rootpw de sa valeur remplacé par une tabulation et une recréation du répertoire /var/lib/ldap. Après rectification des espaces, redémarrage et vérifications, le diagnostic montre une amélioration et les logs indiquent des échanges LDAP plus cohérents, avec une reprise possible des opérations d’authentification et de recherche.
-
ContributeurC'est très bizarre que tu n'obtiennes pas une réponse avec telnet.
Et :
netstat -ltnp | grep :389
netstat -ltnp | grep :636
Celà donne quoi ?
Sinon, tu peux aussi essayer celà :
- commente tout le contenu de ton ldap.conf
- dans /etc/hosts (ton fichier hosts me semble mélanger localhost et l'adresse de ton interface réseau) mets :
127.0.0.1 localhost.localdomain localhost
10.1.50.244 dedev.cnce.ci dedev
Après retente :
telnet localhost 389
et retente un ldapsearch
ldapsearch -x -b 'dc=cnce, dc=ci' '(dc=cnce)'
Si celà ne marche toujours pas, remet ton ldap.conf en place, mais mets une directive URI la place de HOST
URI ldap://adresse.renvoyée.par.netstat-en-port-389
Sinon, là.. je suis un peu à court d'idées :)
Dal -
Ajout au post précédent :
- après la modif du fichier il faut redémarrer le service slapd -
Bonjour
je viens d'avoir un problème similaire :
- ubuntu server 9.10
- openLDAP 2.4.15
description :
- le serveur ldap fonctionne en local (je peux me connecter à la base, et en particulier m'authentifier au systeme par ldap)
- pas de firewall sur le port 389
- mais lors d'une connexion distante, la connexion est refusée
diagnostique
- J'ai d'abord utilisé tshark pour voir les paquets
=> connexion TCP [SYN], reponse du serveur [RST, ACK]
J'ai utilisé les tests de ce post :
- telnet <ip du serveur> 389
=> connection refused
- netstat -lntp | grep 389
=> une seule ligne :
tcp 0 0 127.0.0.1:389 0.0.0.0:* LISTEN 2805/slapd
Solution
- J'ai du modifier le fichier
/etc/default/slapd
- la directive "SLAPD_SERVICES="
Avant :
SLAPD_SERVICES="ldap://127.0.0.1:389/"
Après :
SLAPD_SERVICES="ldap://127.0.0.1:389/ ldap://192.168.4.254:389/"
Où "192.168.4.254" est l'adresse de mon serveur par laquelle le client ldap se connecte.
Résultats
- la connexion est réussie
- sur tshark je vois le handhshake TCP complet
- le telnet sur l'adresse du serveur et le port 389 est réussit
- la commande "netstat -lntp | grep 389" donne maintenant deux lignes
tcp 0 0 127.0.0.1:389 0.0.0.0:* LISTEN 2805/slapd
tcp 0 0 192.168.4.254:389 0.0.0.0:* LISTEN 2805/slapd -
bonjour,
je voudrais faire un script pour vérifier que les utilisateurs présent dans l'annuaire ladp exitent dans Active directory.merci. -
Bonjour tout le monde,
je suis entrain de mettre en place un annuiare LDAP sous FreeBSD. j'ai configurer les fichier nécessaire pour cet effet : ladp.conf et slapd.conf
en fait , j'arrive pas a inclure le fichier (test.ldif qui contient la racine) dans l'annuaire
en tappant la commande suivante : ldapadd -f test.ldif -D "cn=Manager,dc=exemple,dc=com" -w secert
sa me donne kom message d'erreur :
ldap_bind: can't contact server (-1)
voici le detait de mes fichier de configuration
slapd.conf
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
modulepath /usr/local/libexec/openldap
moduleload back_bdb
# moduleload back_ldap
# moduleload back_ldbm
# moduleload back_passwd
# moduleload back_shell
access to attr=userPassword
by dn="cn=Manager,dc=exemple,dc=com" write
by dn="cn=proxyuser,dc=exemple,dc=com" read
by self write
by anonymous auth
by * none
access to attrs=uidNumber,gidNumber
by dn="cn=Manager,dc=exemple,dc=com" write
by dn="cn=proxyuser,dc=exemple,dc=com" read
by * read
access to *
by dn="cn=Manager,dc=exemple,dc=com" write
by self write
by * read
#####################################################################
# BDB database definitions
#######################################################################
database bdb
suffix "dc=exemple,dc=com"
rootdn "cn=Manager,dc=exmple,dc=com"
rootpw secret
directory /var/db/openldap-data
# indice to maintain
index objectClass eq
index sn pres,eq,sub
index ou,cn,mail,surname,givenname eq,pres,sub
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
ldap.conf :
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example, dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
BASE dc=exemple, dc=com
URI ldap://127.0.0.1/
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
Merci d'avance pour vos idées -
bonjour,
je ne comprends pas pourquoi, régulierement mon ordinateur passe en mode hors connexion!!
d'avance merci -
bonjour, je n'arrive pas me connecter a kaspersky il me dit toujours erreur de connection 1:2
merci de m'aider car je suis envahie evirus -
lol pour moi fonctionne la commande search mais toujour a la meme reponse
-
j'ai rencontré ce probléme hier le syntaxe est
ldapsearch -x -b « dc=cnce, dc=ci» « dc=cnce » -
ContributeurBravo :)
Le coup de l'espace m'était arrivé également il y a longtemps, mais je ne rappelais pas que celà donnait ce type de message d'erreur (et il me semblait que le problème survenait quand l'espace se situe avant la directive).
Par curiosité, j'aurai bien voulu savoir si le démarrage manuel slapd -d donnait un message d'erreur plus explicite.
Sinon, tu devrais sans doutes changer le mot de passe (qui est le mot de passe par défaut) et le crypter avec slappasswd, comme celà :
slappasswd -s monnouveaumotdepassetresdur
... et tu copies le résultat dans ton slapd.conf.
Bonne continuation !
Dal-
Non, en lançant le mode debug, il n'y a pas de message d'erreur qui s'affiche. Le serveur montre les initialisations, ... et dit que la BD est démarrée et initialisée.
C'est vrai qu'on aurrait pu s'attendre à un truc genre "invalid credential..." pour le mot de passe......mais boff.. Peut être aussi que la BD a été corrompue.
Pour le pwd, je le changerai, t'inkiète cè plus simple pke je teste l'annuaire. Il me sera utile pour mes developpements (système SSO) en interrogeant l'annuaire.
Merci pour tout DAL -
Salut Dal, Si t'es encore la, j'ai eu le même problème par deux fois encore. J'ai juste regénéré l'annuaire à l'aide de copies du fichier LDIF.
ldapadd -D "cn=admin,dc=cnce,dc=ci" -x -W -f /home/wamoikon/Ldif_complet.txt
En fait cela se passe chaque fois que la machine est arrêtée brutalement. La base de données est immédiatement corrompue.
Voila, encore merci pr l'autre fois -
@WillyBonsoir Willy,
Tu devrais peut-être changer de disque ;-) simple joke... désolé
Maintenant, sans blaque (d'autant qu'elle était mauvaise):
- Quel SF as-tu sur /var , journalisé ou pas?
- Y a-t-il de la place sur la partie associée à /var
j'ai eu le sale tour de bourrer le disque ou était /var à cause d'un log aérophagique, du coup lorsque j'ai ajouté des comptes, la base de donnée ldap était un peu moisie (carrément niquée quoi...). Remède, poser soigneusement l'annuaire dans un coin peinard avec plein d'espace et pas de risque, et faire quand même qqs "df" régulièrement ou encore mieux ajouter un outils de contrôle de charge des disques.
Christian
PS.
Côté espace, le caractère ' ' cette fois, c'est aussi dans le LDIF qu'ils sont rigolos, en fin de ligne, ils impliquent de continuer l'affectation du champ avec le contenu de la ligne suivante, un truc de bleu of course, mais après de un peu de temps de speed, ça tue!!!
Pour ma part j'en veux à plus finir aux développeurs qui ont spécifiés LDIF ... là encore je blague ;-)), mais quand même, quèque chose qui s'voit, c'est ben mieux qu'un :
grep " $" toto.ldif
!!!
-
-
Très cher Dal !
Je viens à l'instant même de trouver la faille.
J'ai viré l'ancienne base de données en effaçant carément le rep /var/lib/ldap.
J'ai recréé le rep /var/lib/ldap , proprietaire (ldap mode 777). 755 devrait suffire.
J'ai lu dans les docs sur le net k'1 caractère espace " " peut entrainer des dysfonctinnements graves. C'est ainsi que j'ai parcourru le /etc/openldap/slapd.conf en vérifiant tous les caractères à la recherche d'espace.
j'ai constaté que le paramètre rootpw étè séparé de sa valeur(secret) par un espace au lieu d'une tabulation.
J'ai corrigé en effaçant l'espace et insérant une tabulation, reconstruit la base de données avec les fichiers LDIF que j'avais pris soin de sauvegarder .
Tout marche pour le mieux maintenant. Voici mes logs que j'ai dirigé dans un fichier:
Oct 12 10:52:36 dedev slapd[6149]: conn=45 op=35 SRCH attr=dn Oct 12 10:52:36 dedev slapd[6149]: conn=45 op=35 SEARCH RESULT tag=101 err=0 nentries
0 text
Oct 12 10:52:36 dedev slapd[6149]: conn=45 op=36 UNBIND Oct 12 10:52:36 dedev slapd[6149]: conn=45 fd=11 closed </pre>
En tout cas merci pour l'aide, tu m'a jamais lâché. J'essayerai d'aider d'autres utilisateurs à mon tour. -
ContributeurEssaye de démarrer en slapd -d 9 et poste le résultat ici.
Celà devrait réduire le volume d'informations de débogage à des informations plus pertinentes. Il y a peut être une erreur signalée quelque part que tu n'as pas vue.
Sinon, au cas où, en dehors de ton ldap.conf, tu n'as pas de .ldaprc dans ton répertoire home ?
Dal -
Le réinstallation me donne le meme problème. Sais pas d'ou l'erreur peut venir. Je cherche toujours.
A bientôt -
[root@dedev ~]# netstat -ltnp | grep :389
[root@dedev ~]#
J'ai modifié les fichiers comme ta demandé.
Netsat ne me donne rien du tout . Sait pas; cè com si impossible d'ouvrir ce port. Je pense que si d'ici demain je trouve rien, je vais tout recomencer à 0
Merci pour l'aide en tt cas
Si j'avance je te le dirai -
Non impossible je cherche toujours le pb
-
ContributeurArrives-tu à te connecter au serveur LDAP depuis une autre machine que le serveur lui-même ?
Dal -
Merci pour le suivi
Vérifié le pare feu, il est désactivé.
Le fichier de lancement en fait /etc/init.d/ldap (sur la CENTOS 4 ke j'utilise) lance le serveur avec la commande :
${slapd} -u ldap -h '"ldap:/// ldaps:///"'
D'apres le man (voir man slapd) , l'option -h '"ldap:/// ldaps:///"' doit lancer le serveur sur les ports par defaut que sont 389 et 636 .
Bien sure, la variable slapd est définie auparavant avec slapd=/usr/sbin/slapd
Le fichier de configuration qui va rechercher est le bon, j'ai vérifié.
Le plus triste dans tout cela, le serveur marchait avant. Je sais pas ce qui a bien pu se passer.
J'ai vu sur une page Web http://www.bo.infn.it/alice/introgrd/edg1-4/node8.html
Certains éléments que j'utilise actu pour mes recherches. Bon je continue de chercher. Si t'a quelque chose n'hesites pas car la, suis ds la m.... -
Contributeurhmm :)
Si on se résume, le démon semble bien lancé, il ouvre apparemment la base que tu as paramétrée, et il attend des connexions qui semblent ne jamais lui parvenir.
Les connexions vers l'hôte sont permises (en fait elles paraissent locales selon le contexte de ton /etc/hosts) et tu penses que tu n'as pas de firewall (vérifie quand même).
Tu n'as pas indiqué si tu avais vérifié le port sur lequel slapd démarre.
Vois celà dans les scripts de démarrage de ta machine (dans /etc/init.d/slapd je suppose sur CentOS).
Peut-être démarres-tu sur le port SSL/TLS de LDAP (qui serait 636) ou un autre port, alors que ldapsearch s'obstine à essayer d'utiliser le port par défaut 389.
Dal -
Mon ps :
ldap 21549 0.0 0.6 8776 3192 ? Ss 13:33 0:00 /usr/sbin/slapd -u ldap -h ldap:///
Je vois bien le PID (21549)
J'ai remarqué quelque chose, D'après le fichier slapd.conf, les fichiers/var/run/slapd.pid et /var/run/slapd.args devraient exister au lancement. Ce n'est pas le cas en pratique.
Le mode debug me donne plein d'infos, mais pas de message d'erreur en particulier. Je pense qu'il m'indique qu'il a ouvert la base:bdb_db_open: dc=cnce,dc=ci bdb_db_open: dbenv_open(/var/lib/ldap)
Mon fichier /etc/openldap/slapd.conf :include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/samba.schema allow bind_v2 pidfile /var/run/slapd.pid argsfile /var/run/slapd.args by anonymous auth by dn="cn=admin,dc=cnce,dc=ci" write by * none access to * by dn="cn=admin,dc=cnce,dc=ci" write by * read ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database bdb suffix "dc=cnce,dc=ci" rootdn "cn=admin,dc=cnce,dc=ci" #rootpw JqNpwdSaoVPQnOSBuvfa1rAHTMyVd3b9 rootpw secret #rootpw {SSHA}+pdZNlNjb3NxgXfe8Ov0d0fQWrUJh/GA directory /var/lib/ldap index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub
Mon fichier /etc/hosts.allow :127.0.0.1 10.1.50.244 ldapd: ALL slapd: ALL
Mon fichier /etc/hosts10.1.50.244 dedev.cnce.ci dedev localhost.localdomain localhost
Franchement j'aurais désinstallé et réinstallé ce truc, mais sais pas si ça va aider. Je creuse un peu encore. -
ContributeurLe démon est-il bien lancé ?
ps aux | grep slapd
Si c'est le cas, que tu es sur la même machine que le serveur et que tu as inclus les lignes indiquées à /etc/hosts.allow, et que ton firewall ne te joue pas des tours, peut-être est-il lancé sur un autre port que le port par défaut ?
Quelles sont les options de lancement de slapd (je ne suis pas sûr que celà soit géré par slapd.conf, car il y a des arguments de ligne de commande pour affecter le port d'écoute - vois donc aussi le script de lancement).
Sinon, ton message n'est pas clair sur ce que restitue exactement l'usage de l'option de débogage.
Chez moi, un démarrage de slapd avec cette option affiche plusieurs pages d'informations de débogage avant même que le serveur n'indique être démarré et qu'il soit à l'écoute des connexions.
Si tu n'as *aucune* information de débogage *du tout* qui s'affiche, il se peut que tu aies un problème avec l'exécutable slapd lui-même, ou une librairie qu'il utilise. Mais c'est étonnant que tu n'aies pas de message d'erreur.
Pour commencer, tu pourrais faire :
whereis sladp
ls -al /le/resultat/de/la/commande/whereis
ldd /le/resultat/de/la/commande/whereis
Dal
- 1
- 2