Forum Linux.général ldap + tls

Posté par  .
Étiquettes : aucune
0
1
juil.
2008

bonjour a tous :)

alors voila j'ai mis en place un serveur ldap pour authentification pour des connexions ssh

selon son compte on a droit a ce connecter sur tel ou tel serveur.

Ca marchait bien jusqu'a ce que j'essaye de tout faire fonctionner en tls donc toujours sur le port 389 d'apres ce que j'ai pu voir a droit a gauche.

quand je lance mon serveur ldap (log ldap):

[code]May 26 16:51:00 srvtest3 slapd[11794]: @(#) $OpenLDAP: slapd 2.3.27 (Jun 27 2007 08:48:26) $ brewbuilder@ls20-bc1-13.build.redhat.com:/builddir/bui

ld/BUILD/openldap-2.3.27/openldap-2.3.27/build-servers/servers/slapd

May 26 16:51:00 srvtest3 slapd[11794]: nss_ldap: failed to bind to LDAP server ldap://srvtest3.test.org: Can't contact LDAP server

May 26 16:51:00 srvtest3 slapd[11794]: nss_ldap: could not search LDAP server - Server is unavailable

May 26 16:51:00 srvtest3 slapd[11794]: nss_ldap: failed to bind to LDAP server ldap://srvtest3.test.org: Can't contact LDAP server

May 26 16:51:00 srvtest3 slapd[11794]: nss_ldap: could not search LDAP server - Server is unavailable

May 26 16:51:00 srvtest3 slapd[11794]: /etc/openldap/slapd.conf: line 34: rootdn is always granted unlimited privileges.

May 26 16:51:00 srvtest3 slapd[11794]: /etc/openldap/slapd.conf: line 40: rootdn is always granted unlimited privileges.

May 26 16:51:01 srvtest3 slapd[11795]: bdb_db_open: dc=mh,dc=org

May 26 16:51:01 srvtest3 slapd[11795]: slapd starting[/code]

/etc/openldap/ldap.conf :

[code]host 127.0.0.1

port 389

base dc=mh,dc=org

uri ldap://srvtest3.test.org

ldap_version 3

TLS_REQCERT allow[/code]

/etc/ldap.conf

[code]# TLS

ssl start_tls

ssl on

Afin que le client puisse valider l'identitéu serveur, on doit le fournir la cléublique

du CA avec laquelle il pourra éblir que le certificat du serveur a bien é signéar

la clérivéde cette mê CA.

TLS_CACERT /usr/local/ssl/certs/ldap.crt

On demande élement au client de toujours valider l'identitéu serveur.

TLS_REQCERT demand

IP du serveur ldap

host srvtest3.test.org

Le DN de base pour effectuer les recherche

base dc=mh,dc=org

Optimisation de recherche dans la base

scope=one

Pour que le poste demarre meme si le server ldap ne repond pas

bind_policy soft

Version du protocole utilise

ldap_version 3

Port ecoute serveur

port 389

Filtres de validation dun utilisateur

pam_filter objectclass=account

pam_filter host=srvtest3.test.org

Attribut compare avec lindentifiant de connexion de lutilisateur

pam_login_attribute uid

Verification attribut host

pam_check_host_attr yes

DN groupe auquel il faut appartenir pour acces machine locale

pam_groupdn ou=group,dc=mh,dc=org

Definit lattribut dappartenance au groupe

pam_member_attribute member

password envoi serveur

pam_password crypt

Parametres nss-ldap de recherche

nss_base_passwd ou=user,dc=mh,dc=org?sub

nss_base_shadow ou=user,dc=mh,dc=org?sub

nss_base_group ou=group,dc=mh,dc=org?sub

nss_base_hosts ou=machines,dc=mh,dc=org?sub[/code]

quand j'essaye de me connecter en ssh avec un user ldap qui a bien les droit dans l'annuaire il reste bloqué ici :

[code]ssh videl@192.168.2.217

videl@192.168.2.217's password:[/code]

et les log du serveur 192.168.2.217 :

[code]May 26 16:53:40 srvtest3 sshd[11808]: nss_ldap: failed to bind to LDAP server ldap://srvtest3.test.org: Can't contact LDAP server

May 26 16:53:40 srvtest3 sshd[11808]: nss_ldap: could not search LDAP server - Server is unavailable

May 26 16:53:40 srvtest3 sshd[11808]: Invalid user videl from 192.168.1.111

May 26 16:53:40 srvtest3 sshd[11809]: input_userauth_request: invalid user videl

May 26 16:53:46 srvtest3 sshd[11808]: nss_ldap: failed to bind to LDAP server ldap://srvtest3.test.org: Can't contact LDAP server

May 26 16:53:46 srvtest3 sshd[11808]: nss_ldap: could not search LDAP server - Server is unavailable

May 26 16:53:46 srvtest3 sshd[11808]: pam_unix(sshd:auth): check pass; user unknown

May 26 16:53:46 srvtest3 sshd[11808]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.111[/code]

si qqu a deja fait ce genre de chose je veux bien un ptit coup de main :)

merci d'avance

  • # port TLS LDAP

    Posté par  . Évalué à 1.

    pour moi (enfin sur mes configs) le port pour faire du TLS avec ldap c'est plutot le 636

    mais je me trompe peut-etre
    • [^] # Re: port TLS LDAP

      Posté par  . Évalué à 2.

      mais je me trompe peut-être

      Oui, enfin en partie.

      La man page stipule que l'une des grandes particuliarités du passage de SSL à TLS est l'utilisation (par défaut) du même port de communication.
  • # LDAP puis TLS puis NSS

    Posté par  . Évalué à 2.

    À vue de nez, j'ai l'impression que NSS gère déjà le LDAP alors que ton serveur n'est pas encore lancé, et ça affecte toutes tes applications ... y compris le serveur LDAP lui-même.

    D'autre part, le TLS_CACERT en majuscule est une directive de /etc/openldap/ldap.conf et pas /etc/ldap.conf (une saloperie, ce truc). Ceci dit, on utilise les mêmes directives dans l'autre aussi, mais en minuscules. Je ne sais pas si le parser fait la distinction ou pas.

    Enfin, essaie déjà de désactiver LDAP dans le NSS puis lancer une recherche avec ldapsearch -h tonserveurldap -LLL -x -ZZ dn pour voir si le TLS fonctionne bien du côté d'OpenLDAP et de ses outils.

    Moi, j'en suis à cette étape aussi. OpenLDAP ok, NSS échoue.
    • [^] # Re: LDAP puis TLS puis NSS

      Posté par  . Évalué à 1.

      comment ca desactiver ldap dans nss ?
      dans nsswitch.conf ?
      • [^] # Re: LDAP puis TLS puis NSS

        Posté par  . Évalué à 2.

        Oui.

        Quelle distribution utilises-tu au fait ?
        • [^] # Re: LDAP puis TLS puis NSS

          Posté par  . Évalué à 1.

          redhat 5
          • [^] # Re: LDAP puis TLS puis NSS

            Posté par  . Évalué à 2.

            J'utilise une Fedora 9, donc ce doit être relativement proche. Il faut distinguer d'un côté les vrais fichiers de conf' et de l'autre les GNOMEries qui permettent de les manipuler. Par exemple : Système->Administration->Authentification.
          • [^] # Re: LDAP puis TLS puis NSS

            Posté par  . Évalué à 2.

            Au fait, ça fait quoi si tu commentes host et que dans uri, tu remplaces ldap:// par ldaps:// ?
            • [^] # Re: LDAP puis TLS puis NSS

              Posté par  . Évalué à 1.

              si je tape cette commande du serveur lui meme :

              ldapsearch -x -H ldaps://127.0.0.1 -D "cn=god,dc=mh,dc=org" -w mypassword -b "dc=mh,dc=org"

              tout le contenu de mon annuaire s'affiche

              ssl fonctionne mais pas tls visiblement non ?

              de bidouiller ldap pour ssl & tls ca ma ouvert deux ports en plus par rapport a ldap simple

              22/tcp open ssh
              80/tcp open http
              389/tcp open ldap
              443/tcp open https
              636/tcp open ldapssl
              • [^] # Re: LDAP puis TLS puis NSS

                Posté par  . Évalué à 2.

                Depuis le serveur, ce n'est peut-être pas une bonne idée, puisqu'il peut ouvrir des sockets UNIX plutôt qu'UDP (ils appellent çà le LDAP over IPC :-).

                Essaie d'ajouter l'option -Z à ta commande, pour forcer le TLS, puis -ZZ pour l'obliger à s'arrêter en cas d'échec de l'authentification. Cette étape fonctionne désormais chez moi, mais nsswitch, lui, continue d'échouer sur un timeout.
  • # cn=chezmoicamarche,dc=org

    Posté par  . Évalué à 2.

    Ok, après en avoir sué, l'authentification utilisateur via LDAP-TLS fonctionne chez moi, tcpdump à l'appui pour comparer les flux.

    Il faut d'abord configurer proprement /etc/ldap.conf et /etc/openldap/ldap.conf, puis veiller a ce que les clients aient accès au certificat de l'autorité racine qui à signé celui du serveur (si pas auto-signé), faire attention au format (.PEM,.CRT,...) et surtout se méfier de host et uri, mutuellement exclusifs. Enfin, il faut se souvenir que le TLS écoute le port 177 par défaut (le SSL Netscape utilisait le 636).

    Le piège, c'est que si on spécifie uri ldaps://ldap.serveur.org, le mot-clé est associé au port 636, qui n'est pas ouvert si on fonctionne en start_tls. Moralité, les modules nss_ldap et pam_ldap ne peuvent pas se connecter, alors qu'un ldapsearch -h ldap.serveur.org -ZZ, lui, y arrive très bien parce qu'on ne précise que le nom d'hôte sans le protocole, et que l'on négocie ensuite le TLS manuellement, avec l'option idoine.

    Beaucoup de temps perdu, mais ça servira bien.
    • [^] # Re: cn=chezmoicamarche,dc=org

      Posté par  . Évalué à 1.

      j'ai tout nettoyé vu que ca marchai pas pour reprendre a zero

      tu as quoi dans ton fichier serveur ldap /etc/openldap/ldap.conf ?
      moi :

      host 127.0.0.1
      base dc=mh,dc=org
      uri ldap//127.0.0.1/
      ldap_version 3

      dans mon fichier client : /etc/ldap.conf

      # IP du serveur ldap

      host 127.0.0.1
      #uri ldaps://srvtest3.test.org/

      faut remettre l'uri ou pas ? ldap://192.168.2.217:177 ?

      dans slapd.conf

      #TLSCipherSuite HIGH:MEDIUM:+SSLv2
      #TLSCertificateFile /etc/openldap/cacerts/ldap.crt
      #TLSCertificateKeyFile /etc/openldap/cacerts/ldap.key
      #TLSCACertificateFile /etc/openldap/cacerts/ldap.crt

      # Use the following if client authentication is required
      # TLSVerifyClient demand
      # ... or not desired at all
      # TLSVerifyClient never

      reste a savoir ce qui est util ou pas
    • [^] # Re: cn=chezmoicamarche,dc=org

      Posté par  . Évalué à 1.

      j'ai tout nettoyé vu que ca marchai pas pour reprendre a zero

      tu as quoi dans ton fichier serveur ldap /etc/openldap/ldap.conf ?
      moi :

      host 127.0.0.1
      base dc=mh,dc=org
      uri ldap//127.0.0.1/
      ldap_version 3

      dans mon fichier client : /etc/ldap.conf

      # IP du serveur ldap

      host 127.0.0.1
      #uri ldaps://srvtest3.test.org/

      faut remettre l'uri ou pas ? ldap://192.168.2.217:177 ?

      dans slapd.conf

      #TLSCipherSuite HIGH:MEDIUM:+SSLv2
      #TLSCertificateFile /etc/openldap/cacerts/ldap.crt
      #TLSCertificateKeyFile /etc/openldap/cacerts/ldap.key
      #TLSCACertificateFile /etc/openldap/cacerts/ldap.crt

      # Use the following if client authentication is required
      # TLSVerifyClient demand
      # ... or not desired at all
      # TLSVerifyClient never

      reste a savoir ce qui est util ou pas
      • [^] # Re: cn=chezmoicamarche,dc=org

        Posté par  . Évalué à 1.

        dans la doc ldap sur le site officiel ils parlent pas de 177

        extrait :
        Note that if the TLS-related directives in slapd.conf are properly configured, TLS will be available over port 389 even without specifying '-h ldaps://' on the slapd command line. In fact, this is the way to make TLS available without making ldaps available.
        • [^] # Re: cn=chezmoicamarche,dc=org

          Posté par  . Évalué à 2.

          Olalah ! GROSSE ERREUR de ma part ! Le port 177, c'est le Xdmcp ! Rien à voir, donc (c'était mon problème précédent en fait).

          Bon, alors en gros :

          - Commenter host et garder uri dans /etc/ldap.conf ;
          - Utiliser ldap:// et pas ldaps:// dans cet URI (et ne pas oublier le deux-points, non plus) ;
          - Ne pas préciser le numéro de port dans l'URI ;
          - Passer en mode TLS par le port par défaut (389, donc) avec ssl start_tls;
          - tlscacertfile pour préciser le nom de fichier de la CA qui a signé le certificat de ton serveur, pour que le client puisse l'authentifier. Peut-être pas nécessaire si tls_checkpeer no.

          Ensuite, côté serveur, donc dans slapd.conf

          - il te faut au moins un certificat côté serveur, fût-il autosigné (mais moi j'ai pris le temps de créer une CA puis de créer un certificat propre à LDAP).

          TLSCertificateFile /etc/pki/tls/certs/ldap.pem
          TLSCertificateKeyFile /etc/pki/tls/private/ldap.key


          sans oublier de redémarrer :

          # /etc/init.d/ldap restart

          Ça devrait suffire à faire démarrer le TLS.
          Puis :

          ldapsearch -x -H ldap://srvtest3.test.org -ZZ '*'

          Pour voir si tu peux établir une connexion en TLS avec ton serveur.

          Après, c'est la configuration de PAM et NSS.
          Bon courage.
          • [^] # Re: cn=chezmoicamarche,dc=org

            Posté par  . Évalué à 1.

            j'ai fais les deux trois modif et :(

            ldap_start_tls: Connect error (-11)
            additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
            • [^] # Re: cn=chezmoicamarche,dc=org

              Posté par  . Évalué à 2.

              C'est ce que je pensais (et j'ai buté dessus aussi) : le certificat envoyé par serveur n'est pas reconnu. Avec quoi, l'as-tu généré ? As-tu bien fourni la clé avec ?
              • [^] # Re: cn=chezmoicamarche,dc=org

                Posté par  . Évalué à 2.

                À noter également que ldapsearch lit sa config dans /etc/openldap/ldap.conf

                Il y existe TLS_REQCERT pour contourner ce contrôle, mais le mieux reste encore de générer un certificat valide.
          • [^] # Re: cn=chezmoicamarche,dc=org

            Posté par  . Évalué à 1.

            j'ai fais les deux trois modif et :(

            ldap_start_tls: Connect error (-11)
            additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
            • [^] # Re: cn=chezmoicamarche,dc=org

              Posté par  . Évalué à 1.

              ldapsearch -v -x -H ldap://srvtest3.test.org -ZZ '*'
              ldap_initialize( ldap://srvtest3.test.org )
              ldap_start_tls: Connect error (-11)
              additional info: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

              mon /etc/openldap/ldap.conf

              #host 127.0.0.1
              base dc=mh,dc=org
              uri ldap//srvtest3.test.org/
              ldap_version 3
              TLS_REQCERT allow

              #TLS_CACERT /etc/openldap/cacerts/ldap.crt
              #TLS_CERT /etc/openldap/cacerts/ldap.crt
              #TLS_KEY /etc/openldap/cacerts/ldap.key
              • [^] # Re: cn=chezmoicamarche,dc=org

                Posté par  . Évalué à 1.

              • [^] # Re: cn=chezmoicamarche,dc=org

                Posté par  . Évalué à 2.

                #TLS_CACERT /etc/openldap/cacerts/ldap.crt
                #TLS_CERT /etc/openldap/cacerts/ldap.crt
                #TLS_KEY /etc/openldap/cacerts/ldap.key


                S'il y a des # devant tes lignes, c'est qu'elles sont commentées.

                Sinon, essaie d'appeler ldapsearch avec -Z au lieu de -ZZ (qui force la validation).

                Par contre, je maintiens que le mieux que tu aies à faire est de refaire des certificats au propre.
                • [^] # Re: cn=chezmoicamarche,dc=org

                  Posté par  . Évalué à 1.

                  trop galère :(

                  il faut ces trois lignes dans le /etc/openldap/ldap.conf ?

                  tu as suivi quel tuto pour faire tes certificats ?
                  • [^] # Re: cn=chezmoicamarche,dc=org

                    Posté par  . Évalué à 2.

                    http://www.z0pe.org/howto/securite/pki-openssl/creation-d-un(...)

                    Lire les deux pages (« avec l'usine »).
                    • [^] # Re: cn=chezmoicamarche,dc=org

                      Posté par  . Évalué à 1.

                      tin bloqué a la fin :)

                      il parle d'un fichier mais il donne pas d'exemple

                      server-cert-sign.cnf
                      • [^] # Re: cn=chezmoicamarche,dc=org

                        Posté par  . Évalué à 2.

                        Allez, je te donne la recette :

                        OpenSSL utilise un fichier de configuration pour connaître les valeurs par défaut de tout ce qu'il y a à mettre dans un certificat. Tu peux passer une bonne partie de ces valeurs sur la ligne de commande, mais elle devient alors kilométrique ... Donc : regarde dans /etc/pki/tls/openssl.cnf. C'est le fichier de configuration d'OpenSSL par défaut. Copie-le dans le répertoire config de la CA que tu as dû créer si tu as suivi le tutoriel en entier.

                        Édite cette copie et mets-y tes valeurs par défaut. Lis bien chaque option, y compris celle qui sont commentées. Fais ensuite des copies de ce fichier pour chaque type d'opération que tu as l'intention d'effectuer : requête, signature, création du certificat racine ... (en principe, ces deux ou trois-là devraient être suffisants).

                        Le détail qui change tout : n'oublie pas d'ajouter utf8 = yes dans la section [ req ]. Ou alors passer -utf8 sur la ligne de commande. Autrement, il te génère bien un certif' compatible UTF-8, mais il parse quand même le contenu de ton fichier de conf' en ASCII.

                        Il faudra donc au minimum préciser le pays (Country - C), l'organisation (O), l'unité organisationelle (OU), et le Common Name (CN), soit le p'tit nom de ton certif' ou de ce qu'il représente. Si tu crées ce certificat pour un serveur, le CN doit obligatoirement contenir le nom de serveur pleinement qualifié (avec le domaine).

                        De là, première étape (à n'effectuer qu'une seule fois), la création du certificat racine, que tu conserveras précieusement :

                        1) Génère suffisamment de données aléatoires dans un fichier (ainsi, tu pourras recommencer facilement en cas de pépin). Ça peut être long si tu utilises le générateur de vrais nombres aléatoires. N'oublie pas de provoquer de l'activité disque, réseau, souris et autres pour accélérer cette production.
                        dd if=/dev/random of=private/.rand bs=1 count=16384

                        2) Tu vas créer la clé privée du certificat racine. À conserver en lieu sûr et à ne jamais divulguer ! D'ailleurs, tu vas même la protéger par une passphrase. Choisis-là suffisamment longue pour qu'elle ne soit pas triviale, mais pas trop compliquée non plus car tu la saisiras chaque fois que tu signeras un certificat.
                        openssl genrsa -aes256 -out private/ca.key -rand private/.rand 4096
                        chmod 400 private/ca.key


                        3) Crée le certificat racine. On le fait en faisant une requête et en passant -x509 pour qu'il remplissent directement les champs qui en font un certificat à part entière ... en l'autosignant. « req » dit que l'on veut travailler sur des demandes de signature. « new » dit que l'on souhaite en créer une (et pas travailler sur un fichier existant). « root-ca-cert.cnf » est le nom de ton fichier de config. On va le signer avec la clé que tu viens de créer, il faudra donc saisir ta passphrase pour pouvoir utiliser cette clé.
                        openssl req -new -x509 -days 3650 -config configs/root-ca-cert.cnf -key private/ca.key -out ca.crt

                        Et voila. Tu viens de créer le certificat racine, valable 10 ans, qui signera tous les autres. Il faudra également le communiquer aux différents clients si ce n'est pas automatique. C'est l'équivalent d'un CACert, Thawte ou Verisign. Note que ce certificat est à la racine de ton répertoire CA, et pas dans un de ses sous-répertoires. La clé privée, elle, reste en dessous de private. Sauve bien les deux et ne divulgue jamais la clé, encore une fois.

                        Deuxième étape, à répéter pour chaque certificat que tu vas créer et signer :

                        4) Regénère des données aléatoires (moins long cette fois) :
                        dd if=/dev/random of=private/.rand bs=1 count=4096

                        5) Regénère une clé. Sans passphrase cette fois, parce qu'elle ne protège qu'un seul certificat, et qu'il faudrait resaisir cette passphrase à chaque fois que l'on relancerait le serveur qui utilise le certificat qu'elle protège.
                        openssl genrsa -out private/ldap.key -rand private/.rand 1024
                        chmod 400 private/ldap.key


                        6) Refais une demande de signature en bonne et due forme, sans « -x509 », cette fois. Je te conseille de choisir comme nom de fichier la valeur que tu donneras à ton OU. De plus, on déposera cette demande dans le répertoire prévu à cet effet, « csr ». Le fichier « server-csr.cnf » est ton fichier de config dédié à la demande de certificats, si ce n'est pas le même.
                        openssl req -new -out csr/ldap.csr -config server-csr.cnf -key private/ldap.key

                        7) Tu as maintenant un certificat, protégé par une clé secrète, mais pas encore authentifié. On va demander à la CA de signer ce certificat avec le sien. « sign.cnf » est le ficheir de config dédié à la signature. Si tu l'as bien configuré, il contient déjà les noms et emplacements du certificat racine et de sa clé, ce qui t'évite d'avoir à te les palucher à chaque fois sur la ligne de commande.
                        openssl ca -out certs/ldap.crt -in csr/ldap.csr -config sign.cnf


                        Importe ensuite manuellement le fichier ca.crt dans la liste des autorités de certification de Firefox, par exemple. On ne doit pas te demander de passphrase à ce stade. Il faudra faire de même pour tous les clients sécurisés, style ldapsearch ou autre. Enfin, utilise un certificat signé (pas celui de la CA) par serveur à authentifier.

                        C'est fastidieux, mais c'est une méthode universelle. Avec çà, fini les certifs auto-signés.
                        • [^] # Re: cn=chezmoicamarche,dc=org

                          Posté par  . Évalué à 1.

                          jai l'impression je ca marche :)
                          par contre mes authentification ssh par ldap ne fonctionne plus

                          tail -f /var/log/secure

                          nss_ldap: could not search LDAP server - Server is unavailable

                          et comme je te disai :p

                          /usr/bin/slapd -4 lance bien mon serveur

                          mais service ldap start ne le lance pas error :(

                          May 30 01:13:29 srvtest3 slapd[32529]: nss_ldap: could not search LDAP server - Server is unavailable
                          May 30 01:13:29 srvtest3 slapd[32529]: nss_ldap: could not search LDAP server - Server is unavailable
                          May 30 01:13:29 srvtest3 slapd[32529]: /etc/openldap/slapd.conf: line 39: rootdn is always granted unlimited privileges.
                          May 30 01:13:29 srvtest3 slapd[32529]: /etc/openldap/slapd.conf: line 44: rootdn is always granted unlimited privileges.
                          May 30 01:13:29 srvtest3 slapd[32529]: main: TLS init def ctx failed: -1
                          May 30 01:13:29 srvtest3 slapd[32529]: slapd stopped
                          • [^] # Re: cn=chezmoicamarche,dc=org

                            Posté par  . Évalué à 1.

                            je ne vois pas pourquoi :

                            nss_ldap: could not search LDAP server - Server is unavailable

                            ca vient de mon /etc/ldap.conf ou /etc/openldap/ldap.conf ?
                          • [^] # Re: cn=chezmoicamarche,dc=org

                            Posté par  . Évalué à 1.

                            je ne vois pas pourquoi :

                            nss_ldap: could not search LDAP server - Server is unavailable

                            ca vient de mon /etc/ldap.conf ou /etc/openldap/ldap.conf ?
                            • [^] # Re: cn=chezmoicamarche,dc=org

                              Posté par  . Évalué à 2.

                              Parce que, comme un certain nombre de service et même d'applications, ton service fait appel à la bibliothèque standard C pour lui donner un certain nombre d'informations à propos des utilisateurs, choses qu'elle va en principe chercher dans les fichiers de config.

                              Or, NSSwitch est justement là pour fournir d'autres sources de données, de manière transparente, dont une base LDAP. Donc, ton serveur LDAP se plaint au démarrage parce que le serveur LDAP n'est pas lancé :-)

                              Pour autant, on s'aperçoit également que ce n'est pas ça qui empêche ton serveur de démarrer.
                              • [^] # Re: cn=chezmoicamarche,dc=org

                                Posté par  . Évalué à 1.

                                pas possible que le serveur LDAP se plaint au démarrage parce que le serveur LDAP n'est pas lancé !!! (:p)

                                mon nsswitch.conf

                                passwd: files [SUCCESS=return] ldap
                                shadow: files [SUCCESS=return] ldap
                                group: files [SUCCESS=return] ldap

                                le seul truc dont il a besoin c'est sont user ldap et il est dans "files" et si il trouve son bonheur dans files il va pas voir dans ldap

Suivre le flux des commentaires

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