Forum Linux.général Problème LDAP (enfin plutot réseau)

Posté par  (site web personnel) .
Étiquettes : aucune
-1
16
nov.
2011

Bonjour,

j'ai un serveur qui fait de l'authentification LDAP via libnss-ldap. La conf est déployé via puppet, elle est identique à l'ensemble des serveurs Linux (une 15aine).

Pourtant, sur le serveur en question, la resolution d'uid/gid prend trois plombe et je ne comprend vraiment par pourquoi.

gnumdk@terrance:~$ id cbellega
uid=30430(cbellega) gid=513(Domain_Users) groupes=513(Domain_Users)

Par contre, si je tape:

gnumdk@terrance:~$ getent passwd cbellega
cbellega:x:30430:513:'BELLEGARDE Cedric':/home/cbellega:/bin/tcsh

C'est instantanée.

Mon serveur LDAP ne sert que de relai vers un serveur externe, si je met l'ip du LDAP maitre dans la conf libnss-ldap, alors la première commande s'execute instantanément.

Si je met ma machine dans la conf, que je fait une redirection de port vers mon serveur LDAP, alors cela fonctionne correctement.

Si je fait un ldapsearch depuis terrance vers mon serveur LDAP, aucun problème non plus.

Bref, je comprend RIEN, ca fait deux jours que je tourne en rond sans succès...

Niveau tcpdump, je vois des trucs comme ca sur mon serveur LDAP:

15:01:58.107460 IP 194.254.144.3.37813 > 194.254.144.28.389: . ack 137849 win 489 <nop,>
15:02:06.503900 IP 194.254.144.3.37814 > 194.254.144.28.389: S 1457606330:1457606330(0)>

Un gros lague donc dans la communication, je comprend pas... :-/

Si quelqu'un a une idée...

  • # La réponse classique/bateau dans les cas de latence …

    Posté par  . Évalué à 1.

    Un problème de DNS/reverse DNS ?

    • [^] # Re: La réponse classique/bateau dans les cas de latence …

      Posté par  (site web personnel) . Évalué à 2.

      Ben, j'ai essayé d'utiliser l'ip du serveur ldap ;)

      • [^] # Re: La réponse classique/bateau dans les cas de latence …

        Posté par  . Évalué à 2.

        utiliser l'IP de ton serveur DNS ne resoud pas un probleme possible de reverse DNS.

        ta machine "terrance" n'existe peut-etre pas dans le DNS

        ton serveur recoit bien la demande, mais pour chaque echange essaie de voir le rapport entre l'IP et un nom DNS pour mettre dans les logs.
        ca prend un peu de temps puisque les DNS ne trouve pas terrance dans leur base.

        tu as par exemple le meme probleme avec SSH qui parait lent à se connecter quand le client n'as pas d'existence DNS.

  • # config nsswitch.conf, libnss.ldap,...

    Posté par  (site web personnel) . Évalué à 2.

    Nscd ?

    Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

  • # Classique

    Posté par  . Évalué à 2.

    Contrairement à getent passwd, id(1) affiche la liste des groupes auxquels tu appartiens via getgroups(3) ou similaire.

    Si tu utilises ldap pour les groupes, ça veut dire recherche de tous les groupes auxquels ton utilisateur appartient. La même recherche a lieu à l'ouverture de session (initgroups(3) ou identique qui fait appel à tous les backends définis pour group dans nsswitch.conf).

    Vérifie comment la requête est configurée, et que ton serveur dispose d'index adaptés.

    • [^] # Re: Classique

      Posté par  (site web personnel) . Évalué à 2.

      J'ai bien précisé que cela fonctionne parfaitement sur 15 autres serveurs (et une 60 autres dans les autres écoles) ;)

  • # tcpdump

    Posté par  (site web personnel) . Évalué à 3.

    Les deux lignes de tcpdump que tu donnes ne donnent pas beaucoup d'information. On voit juste une machine qui envoi un ACK sur une certaine connexion puis un SYN pour ouvrir une autre connexion.

    Faudrait une séquence un peu complète pour pouvoir espérer diagnostiquer quoi que ce soit.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: tcpdump

      Posté par  (site web personnel) . Évalué à 2.

      Ca ressemble quand meme à un probleme LDAP.

      Si pendant que la commande "id identifiant" reste bloquée je rédémarre le service LDAP, alors la commande "id" rend la main directe et me donne la bonne réponse !!!!

      Mais c quoi ce bordel :-/

      • [^] # Re: tcpdump

        Posté par  (site web personnel) . Évalué à 2.

        Elle attends quelque chose probablement.
        Le fait d'arreter le service interrompt la requete.

        Strace / wireshark pour plus d'infos.

        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

    • [^] # Re: tcpdump

      Posté par  (site web personnel) . Évalué à 2.

      http://adishatz.1s.fr/~gnumdk/ldap.dump

      Dump pour wireshark, au cas ou ca t'inspires :)

      • [^] # Re: tcpdump

        Posté par  (site web personnel) . Évalué à 2.

        En fait, je pense que ca vient de là:

        177 08:44:09.514368 194.254.144.28 194.254.144.3 LDAP 80 searchResDone(11) sizeLimitExceeded [1 result]

        Mais je vois pas pourquoi il me répond ca :-/

        • [^] # Re: tcpdump

          Posté par  (site web personnel) . Évalué à 2.

          Il y a une limite à la taille des resultats des requetes.

          Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

        • [^] # Re: tcpdump

          Posté par  (site web personnel) . Évalué à 2.

          paquet 437, un truc pas net : Malformed packet ldap et Found more than 200 elements giving up

          Les bases sont les mêmes , les configurations / versions de paquets identiques scôtes clients ?

          Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

      • [^] # Re: tcpdump

        Posté par  (site web personnel) . Évalué à 2.

        404
        Si tu repostes il est possible que je regarde sous 7 jours.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # sssd

    Posté par  (site web personnel) . Évalué à 2.

    Sur debian squeeze, j'ai basculé tous mes serveurs sous sssd. C'est sssd qui est connecté au LDAP. La configuration est au final bien plus simple et le tout est robuste au petit problème réseau. Bref, même sans réseau, cela fonctionne tout seul en autonomie...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.