Journal S'initier à LDAP

Posté par (page perso) .
Tags : aucun
1
5
avr.
2008
Bonjour,

Cela fait longtemps que j'entends parler de LDAP mais sans jamais vraiment bien comprendre.

J'aimerais une fois pour toute me simplifier la vie et que mon mail (bongo), mon blog (dotclear) et mon jabber (ejabberd) partage le même login/password sur mon serveur Ubuntu.

Je pense que pour ce genre de choses, LDAP est le plus approprié mais peut-être que je me trompe.

Avez-vous des ressources genre "LDAP pour les nuls" à me conseiller ?

Histoire que les choses soient encore plus facile pour moi, je me demandais s'il existait de bons front-ends graphiques pour administrer un serveur LDAP distant (soit un front-end web, soit une appli qui se connecte via internet donc).

Dernière question que je me pose : j'ai l'impression que dans cet usage relativement simple, LDAP ne gêrera donc que l'authentification. Tout ce qui est des privilèges et du compte lui-même sera gêrée par l'application elle-même. (en gros, si je n'ai pas créé le compte "ploum" dans dotclear, même si l'utilisateur ploum existe dans LDAP, je ne pourrais pas me logguer). Mais j'avoue que ça me semble très fumeux, je n'ai pas les idées précises. Est-ce que c'est bien ça ? Est-ce que c'est un choix ? Si c'est un choix, quelles sont les avantages/désavantages des différentes solutions ?

Un grand merci pour vos retours. Je dois avouer que je suis un peu paumé car je pense que mon use-case est très simple (centraliser l'identification et rien de plus) mais ce que je trouve comme doc me parle directement de racine, root machin chouette avec notation cryptique, identification sur 15 réseaux distribués, etc...

Je considérerais une solution comme un succès si changer mon password dans Jabber le change aussi dans dotclear et Bongo. Tout simplement :-)
  • # mds

    Posté par (page perso) . Évalué à 6.

    Je te conseille de regarder mds (Mandriva Directory Server), c'est simple à installer et ça te donne à mon sens une bonne idée du bon usage d'un annuaire.

    Pour commencer je pense que c'est intéressant de regarder un truc bien intégré.

    En plus y-a l'ajax :) et un dépôt apt.

    C'est là :
    http://mds.mandriva.org/

    Exemple d'utilisation :
    http://www.vogelweith.com/debian_server/07_postfix.php
    • [^] # Re: mds

      Posté par . Évalué à 5.

      Ploum qui passerait à Mandriva ?
      Si ça se fait, je te paie une pinte de guinness dans le quartier mouffetard
      • [^] # Re: mds

        Posté par . Évalué à 4.

        ben non, regarde le lien donné et relis son message : cela semble pouvoir tourner sur n'importe quelle distribution et il y a un dépôt apt pour l'installer facilement.

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # O'Reilly comme d'hab...

    Posté par (page perso) . Évalué à 5.

    Désolé, pas de "LDAP pour les nuls", mais un excellent ouvrage de Gerald Carter intitulé LDAP Administration Système. Par contre je ne connais pas tes softs et j'ignore s'ils supportent l'authentif via LDAP.
    Mais c'est de toutes façons un très bon bouquin que je te recommande.
  • # Ce n'est pas une bonne idée

    Posté par . Évalué à 5.

    Il faut savoir que ldap c'est chiant mais je vais essayer d'être plus précis.

    Ldap est un moyen de stocker des annuaires mais il n'y a pas
    de schéma stricte défini, donc chaque application utilise son
    schéma en fonction de l'humeur des dev.

    Quand tu as deux applis qui sont capables de gérer l'authenfication
    par ldap y'en a une qui va aller chercher le nom de l'utilisateur dans
    group/truc/uid et l'autre dans mongroupe/dutilsateur/name.

    Bon ça à la limite tu peux arriver plus ou moin à le configurer mais
    après manque de bol t'aurai une appli qui ne supporte que les
    password en sha et l'autre en texte.

    C'est un petit résumé des galères qui t'attendent et de mon point de
    vue faire du ldap sans être payé pour c'est une grosse perte de temps.

    Par exemple tu parles de dotclear, une rapide recherche sur le net
    m'a donnée cette page qui n'est peut être plus d'actualité mais qui
    n'est pas encourageante:

    http://www.weblogmatrix.org/show/DotClear

    dans la section User Access Features y'a ldap support: no
    • [^] # Re: Ce n'est pas une bonne idée

      Posté par . Évalué à 6.

      C'est ma fois assez vrai ...
      Les applications sont en général paramètrables pour leur expliquer ou chercher les informations dans l'annuaire. Le stockage du mot de passe est quelques fois contourné par les applications qui tentent tout simplement de s'authentifier sur l'annuaire lui même (et qui ne dépendent donc pas du format de stockage du mot de passe).

      Le truc c'est de bien différencier SSO (single sign on) et ldap.
      La question du mot de passe centralisé c'est plutot ldap, SSO c'est le fait de se logguer une seule fois pour toutes les applications. Souvent les 2 sont mélangées dans les solutions et dans les têtes.

      Pour ce qui est de la création des comptes dans les applications, en général on crée un schema ldap avec un user et un mot de passe, puis on place ce user dans des groupes d'utilisateurs de chaque application (ou on leur affecte des attributs equivalents ...). Bref, l'application cherche d'abord l'appartenance a un groupe dans l'annuaire pour vérifier que ce user a bien le droit d'utiliser cette application, puis elle tente un logon sur l'annuaire avec le password de l'utilisateur. Normalement ce logon ne donne AUCUN droit de modification de l'annuaire, voire meme pas la consultation, c'est juste pour valider le password.

      en pratique je suis d'accord, il faut etre payé pour aller vers LDAP, et ce genre d'annuaire est une bénédiction dans une grande entreprise, a la maison c'est plus pour apprendre a quoi cela ressemble :-)

      Interêt du ldap en entreprise ?
      - le provisionning: quand un type est embauché on crée de facto son compte mail, windows (pardon linux), ...
      - quand un type est viré ou arrive en fin de contrat, sa suppression de l'annuaire invalide d'un seul coup tous les logons dans toutes les applications.
      - ...

      interet pour l'utilisateur: mot de passe unique
      desavantage: mot de passe unique (il suffit d'une application mal foutue pour leaker le mot de passe qui donne l'entrée sur une autre appli beaucoup plus sensible). Pour cela preferer les methodes a la tokenID qui permettent de centraliser *aussi* la partie sensible qui manipule les mots de passe... mais c'est aussi un SSO :-)

      bon j'espère que je t'ai pas saoulé :-)
      • [^] # Re: Ce n'est pas une bonne idée

        Posté par . Évalué à 0.

        toi mon bébert tu me plais !
      • [^] # Re: Ce n'est pas une bonne idée

        Posté par (page perso) . Évalué à 2.

        Un grand merci pour ta réponse.

        Je tiens à préciser que je me fous éperdument du SSO. Je devrai rentrer mon mot de passe dans dotclear, Jabber, mail,.. à chaque fois. Je n'ai aucun problème avec ça.

        Mon but c'est uniquement que le mot de passe soit le même et qu'un mot de passe changé dans une appli soit également changé dans les autres.

        Je pense que ça simplifie fortement le problème non ?
      • [^] # Re: Ce n'est pas une bonne idée

        Posté par . Évalué à 4.

        Pour ce qui est de la création des comptes dans les applications, en général on crée un schema ldap avec un user et un mot de passe

        Je ne suis pas d'accord avec le réflexe de créer systématiquement un schéma. Le mieux est plutôt d'utiliser au maximum les schémas standard. En l'occurrence pour un login/mdp, la classe inetOrgPerson propose déjà tout.

        De cette manière, toutes les applications partagent les même données, ce qui est l'objectif de Ploum. Je recommande donc de créer les utilisateurs comme des instances de inetOrgPerson, sauf bien sûr si les applis que tu utilises ne supportent pas cette classe d'objet (ce qui m'étonnerait quand même).

        généralement, une application qui n'a besoin que d'un couple login mot de passe te demandera la classe des objets utilisateurs à chercher dans l'annuaire (ici: inetOrgPerson), la branche de l'annuaire ou chercher l'utilisateur (tu n'as qu'à mettre la racine de l'annuaire, qui est typiquement de la forme dc=domaine,dc=com dans le cas où ton domaine DNS est domaine.com).

        Lors d'une authentification l'application va chercher dans l'annuaire sous dc=domaine,dc=com, un objet de classe inetOrgPerson et de login le login fournit. Cela se traduit par le filtre LDAP suivant : (&(objectClass=inetOrgPerson)(uid=ploum)).

        La recherche est faite soit en tant qu'anonyme soit en utilisant un compte fournit dans un fichier de config. Elle va renvoyé soit aucun objet (l'utilisateur n'existe pas ou ne peut être lu avec le compte de l'application à cause de droits d'accès), soit un objet, soit plusieurs (gros problème qui ne devrait pas arriver, qui signifie que plusieurs entrées utilisateurs sont stockées avec le même uid, dans des branches différentes de l'annuaire). L'application va récupérer comme résultat de la recherche le Distinguished Name (DN) de l'objet, qui est du type uid=ploum,ou=utilisateurs,dc=domaine,dc=com
        (l'objet ou=utilisateurs,dc=domaine,dc=com est un objet de classe organizationalUnit que tu peut créer pour ne pas mettre tous tes objets sous la racine, et pour réaliser l'arborescence LDAP)

        Avec ce DN, et le mot de passe fournit, l'application va effectuer une opération de bind LDAP, c'est-à-dire d'authentification, qui va ainsi vérifier le mot de passe.

        Pour ta question concernant dotclear, supposant que dotclear a besoin d'un compte associé au compte LDAP, on peut parfaitement imaginer (je ne connais pas le design de dotclear) que dotclear crée "à la volée" le compte lors d'une authentification LDAP réussie, si ce compte n'existe pas déjà. Pour associer le compte dotclear au compte LDAP, dotclear pourrait stocker le login, ou le DN, ou encore l'attribut entryUUID de l'utilisateur LDAP, qui est une valeur qui ne changera jamais même si l'utilisateur est renommé ou déplacé dans l'annuaire.

        J'espère aussi ne pas t'avoir saoulé :)
    • [^] # Re: Ce n'est pas une bonne idée

      Posté par . Évalué à 5.

      D'où PAM qui gère l'authentification pour l'application donc plus de problème de format de pass différents etc...

      Par contre y'a toujours le problème du support, je ne connais pas les applis cité dans ce journal, mais le support de PAM me semble improbable sauf peut-être pour ejabberd.
    • [^] # Re: Ce n'est pas une bonne idée

      Posté par . Évalué à 4.

      Ldap est un moyen de stocker des annuaires

      J'ai toujours compris que LDAP ( [[Lightweight Directory Access Protocol]] ) n'était que le protocole ("langage") d'interrogation et d'écriture de l'annuaire et permet ainsi l'abstraction de la base de donnée qui le stocke.

      On m'aurait menti ?
      Si oui courrez corriger Wikipédia ( http://fr.wikipedia.org/wiki/Lightweight_directory_access_pr(...) )

      PS : la syntaxe wiki pour les liens vers wikipédia ne fonctionne que pour 1 mot :-(
      • [^] # Re: Ce n'est pas une bonne idée

        Posté par (page perso) . Évalué à 4.

        Non, non, c'est tout à fait cela.
        En fait quand tu interroges un serveur LDAP, rien ne te permet de savoir si les données que tu remontes ne sont pas :
        - stockées dans la base BDB locale du serveur OpenLDAP ;
        - stockées dans la base SQL que le serveur OpenLDAP interroge ;
        - stockées dans l'AD de ton entreprise que le serveur OpenLDAP interroge ;
        - sans parler du fait qu'il peut remanier les données à l'aide de règles de ré-écriture.

        Le client LDAP n'a pas à savoir ni se préoccuper de la manière dont les données sont stockées.
    • [^] # Re: Ce n'est pas une bonne idée

      Posté par . Évalué à 2.

      Outre la précision faite sur ce qu'est LDAP, ton argument sur l'absence de schéma strict n'est pas vraiment pertinent. Disons que l'on peut en dire autant à propos de SQL.
      Une application qui utilise LDAP, ou un backend SQL d'ailleurs, pour les données d'authentification, se doit de proposer un paramètre de configuration pour définir la ou les requêtes permettant de faire correspondre le nom d'utilisateur, le mot de passe ou autre, à des attributs LDAP (ou des champs SQL).
      Si un application en particulier ne supporte qu'un type de stockage de mot de passe (plain text, hashage etc), ce n'est quand même pas la faute à LDAP.
    • [^] # Re: Ce n'est pas une bonne idée

      Posté par . Évalué à 2.

      manque de bol t'aurai une appli qui ne supporte que les
      password en sha et l'autre en texte.


      C'est que ces applis sont très mal faites et n'ont pas compris l'authentification LDAP.

      Si elles étaient bien faites elles feraient un bind (authentification) LDAP pour vérifier le mot de passe, ce qui fonctionne dans tous les cas, quelle que soit la manière dont est stocké le mot de passe.

      Donc ce n'est pas vraiment un problème venant d'LDAP. Ou alors si, mais du même genre que "Linux c'est pas bien car ça ne prends pas en charge mon imprimante". C'est de la faute du constructeur de l'imprimante qui ne fait pas de driver/ne fournit pas les specs, mais du coup on est embêté en utilisant linux.
      • [^] # Re: Ce n'est pas une bonne idée

        Posté par . Évalué à 1.

        Pas forcément.

        Les applications qui ne font pas de bind mais un compare veulent simplement éviter que le mot de passe transite en clair sur le réseaux.

        D'ailleurs, le compare du hash du mot de passe est la facon la plus sure et également la plus rapide d'effectuer une authentification.
  • # Le meilleur moyen de comprendre LDAP

    Posté par . Évalué à 2.

    Le meilleur moyen, c'est d'installer un serveur OpenLDAP à la mano. Et de le configurer pour plusieurs services différents (login, mail...).

    Par contre, l'idée de disposer d'un frontend graphique est une mauvaise idée. Le mieux est d'utiliser la ligne de commande, car comme cela, tu comprendras vraiment ce que tu fais, alors qu'un frontend te fera peut-être des choses dans le dos qui t'empêcherons de bien comprendre les concepts.

    Je n'ai jamais lu de livre sur OpenLDAP. J'ai simplement installé OpenLDAP un jour, et chercher au fils de mes besoins. Je n'aime pas les front-ends graphique car pour moi la ligne de commande est une puissance qui fait la différence.

    Désolé pour l'analogie des voitures, mais la meilleure façon de comprendre une voiture, c'est de la démonter. Ce n'est pas de lire la revue technique.
  • # c'est une idée qui me trotte aussi dans la tête

    Posté par (page perso) . Évalué à 2.

    Comme dit en titre, je me suis déjà dit que je devrait faire ça.
    Mes motivations tournent principalement sur le partage du carnet d'adresse avec ma copine. Nos deux ordi sont sous ubuntu, mais elle utilise Kmail et moi Thunderbird.
    La difficulté, c'est que tout ce que je trouve sur LDAP tourne autour de l'authentification, du SSO et tuti quanti dont je n'ai rien à battre.
    Et LDAP a l'air d'être quand même un joyeux bordel tout au moins vu ce qu'on lit sur le web sur le sujet.
    Avez vous des pistes sur le sujet ?
    • [^] # Re: c'est une idée qui me trotte aussi dans la tête

      Posté par (page perso) . Évalué à 2.

      Pas plus que pour d'autres normes.
      Le problème est que les éditeurs et développeurs d'applications connaissent très souvent bien asssez mal les protocoles comme LDAP, ce qui donne des supports très disparates. En général, il s'agit surtout d'une fonctionnalité, demandée par des clients qui disposent d'un AD, qui a donc été rajouté en plus.
      • [^] # Re: c'est une idée qui me trotte aussi dans la tête

        Posté par . Évalué à 2.

        Bien d'accord.

        En fait, LDAP présente énormément d'avantages (à mon avis) sur bien d'autres protocoles, c'est que beaucoup d'aspects en dehors du simple protocole sont définis par les spec. Par exemple, une partie des schémas (qui vont structurer et organiser les données) sont définis. De même, il dispose d'un mécanisme d'auto découverte qui n'existe pas dans le monde des SGBD, par exemple. Ce dernier rend possible l'utilisation de la plupart des clients LDAP de "haut niveau" (voir autre post ci dessous) sans rien connaitre a priori d'un annuaire.

        Pour aider Ploum, je suggère de :
        - vérifier que les applications ciblées supportent LDAP
        - installer OpenLDAP
        - se contenter des schémas standards avec lesquels il est installé, car ils devraient être suffisant (sinon, les manuels des applications listées devraient le préciser)
        - consulter le "guide rapide" avec lequel il est fourni, qui est assez bien écrit
        - choisir un client graphique de suffisamment haut niveau pour ne pas se prendre la tête, et conserver le CLI pour l'administration.

        Bon courage, LDAP, c'est bien.
    • [^] # Partage du carnet d'adresse...

      Posté par (page perso) . Évalué à 2.

      Bonjour

      Un truc simple:

      Tu installes Fuse (inclus dans les noyaux récents),
      Entre les deux comptes, sur un des postes (celui tout le temps allumé), tu crées un lien symbolique du carnet d'adresse.

      Si vous partagez le même ordinateur, ce n'est pas très compliqué (il faut gérer les droits d'accès quand même)

      Sinon, c'est un chouilla plus compliqué, mais avec sshfs et des liens symboliques vous devriez vous en sortir.

      Je le fais sur mon ordinateur portable, je monte mon dossier home distant (celui du poste de mon bureau) dans un dossier dans mon home, et il y a des liens symboliques:
      - pour un des profils de Iceweasel (Firefox)
      - pour Psi
      - Pour Gajim
      Pas pour l'ensemble du profil de Icedove (Thunderbird) parce que c'est trop lent la lecture de l'ensemble des comptes de messageries, et que je peux passer par du imap. Pour le carnet d'adresse, je ne l'ai pas encore fait.

      Concernant Jabber, si je partage la totalité des fichiers de préférences, il y aura conflit parce que la ressource sera identique si le même client tourne sur les deux postes (et comme c'est configuré pour se reconnecter automatiquement...).

      A bientôt
      Grégoire
      • [^] # Re: Partage du carnet d'adresse...

        Posté par (page perso) . Évalué à 2.

        Enfin pour ce genre d'utilisation (synchronisation), y'a quand même unisson qui me semble nettement plus adapté (il faut juste penser à le lancer régulièrement, mais un cron peut faire ça très bien).
  • # Mon expérience

    Posté par . Évalué à 3.

    J'ai configuré mon serveur ftp pour qu'il utilise un annuaire LDAP. (normalement c'était pour utiliser le mail sur le même annuaire, mais le temps m'a manqué). L'avantage c'est que Proftpd utilise les classes posixAccount qui m'ont l'air assez standard puisqu'elles peuvent servir aussi au login local (via un module pam_ldap )
    La configuration de openldap ne pose pas de réel problème, il suffit de suivre la documentation. C'est sûr que toutes les notions abordées dans la documentation sont un peu étranges au premier abord, mais pour moi ça a été inévitable au début (au moins pour être sûr que tout marche ensemble, il faut bien veiller au différences mêmes minimes entre chaque notion). J'ai utilisé quand même un bouquin sur ldap, ou alors sur les applications réseaux en général (qui m'a beaucoup aidé d'ailleurs), mais je n'ai pas la référence ici.

    Ce qu'on trouve sur internet est effectivement tordu (cf message d'avant) et ne marche pas partout.

    J'ajouterai que tout l'avantage que je tire de cet annuaire LDAP est sans aucun doute la facilité d'administration. J'utilise l'application (java) Ldap Browser disponible ici : http://www-unix.mcs.anl.gov/~gawor/ldap/
    C'est drôlement pratique : on voit tous les user d'un coup, on en ajoute un en trois clic on modifier le mot de passe en deux : en un mot c'est pratique. (Il existe sans doute mieux, mais je n'ai pas cherché plus loin).
    Un autre avantage que je vois à ldap : en cas de transfert de machine, il suffit de transférer les bases et tout repart normalement, de plus une fois que tous le système est configuré il n'y a plus rien à faire : je n'ai pas retouché à un fichier de configuration ldap depuis l'installation ; durable donc.

    Sur ce, bonne nuit à vous.
  • # LDAP, SNMP, et caetera.

    Posté par (page perso) . Évalué à 6.

    Il ne faut pas perdre de vue que LDAP (et SNMP aussi) est avant tout un protocole d'accès à des données présentées de manière hiérarchique et de façon totalement indépendante de la manière dont les dites données peuvent être réellement « stockées ».
    La nature des données, leurs inter-dépendances entre elles, leurs contraintes sont définies par des schémas (des MIB pour SNMP). Il existe des schémas dits standards par opposition aux schémas propriétaires dont les OID font partie d'une branche nommée « entreprise » et attribués à une entreprise ou une associétation par l'IANA. Les schémas dits standards font donc généralement l'objet d'une RFC. Ceci permet de s'assurer d'une certaine cohérence quant aux données que l'on doit examiner.
    Toutefois, le support du protocole dans les applications dépend étroitement des connaissances que peuvent en avoir les concepteurs et de la place qu'ils lui accorderont dans leur développement. Soit il s'agit de répondre à un besoin exprimé par les utilisateurs, soit il s'agit de s'inscrire dans la logique de l'application.
    Tout dépend donc du support LDAP dont disposent Bongo, ejabberd et dotclear.

    PS: je parle de SNMP entre parenthèses car les deux protocoles partagent beaucoup de concepts (et surtout les OID).
  • # Réponse pour les clients LDAP

    Posté par (page perso) . Évalué à 4.

    De ce que j'ai pu remarquer, il existe grosso modo 2 types de frontend graphique :
    - les clients plutôt haut niveau, type kaddressbook ou luma, qui te présentent par exemple des formulaires pour ajouter des contacts, utilisateurs, groupes, mais qui sont généralement assez limités car orientés vers un "métier" donné. Du coup, c'est à la fois un avantage et un inconvénient (simplicité vs. souplesse).
    - les clients plus bas niveau, comme gq ou phpldapadmin, qui te montrent ton arborescence LDAP telle quelle, avec les DN, les attributs et leurs valeurs, etc..

    Bon, sinon tu as les bons vieux ldapadd, ldapmodify, ldapsearch, etc. (paquet ldap-utils dans Debian), en ligne de commande, où là tu tapes dans les DN et le format LDIF. En faisant un "apt-cache search ldap" je viens aussi de voir passer cpu, mais jamais utilisé ni eu de retour (mais j'en veux bien).

    Personnellement, ce que je te conseille c'est phpldapadmin (en mode web), car il contient aussi, par exemple, des "assistants" ou "templates" pour créer une nouvelle entrée, en plus du formulaire générique (choix d'objectClass et attributs, du DN...). Par ailleurs, son browser de schéma est très instructif. Phpldapadmin est moins réactif que gq (dans le même genre, mais en mode desktop), mais aussi moins buggé.
  • # Une très bonne ressource

    Posté par . Évalué à 3.

    http://ldapbook.labs.libre-entreprise.org/book/html/

    Une superbe documentation! J'ai lu un peu plus haut qu'il suffisait d'installer OpenLDAP pour se lancer, c'est une bien mauvaise idée. LDAP, c'est pas évident à appréhender, et OpenLDAP tout seul, c'est pas ce qu'il y a de plus simple à administrer quand on ne connait pas.

    Je te recommande aussi le LDAP studio disponible ici: http://directory.apache.org/
  • # LDAP ou SGBDR ?

    Posté par . Évalué à 2.

    Aujourd'hui, j'ai un système d'authentification et de gestion des paramètres de mes applications serveurs qui utilise principalement une base de données relationnelle (PostgreSQL pour ne pas la citer).

    Dans ces applications, j'ai mon serveur SMTP, IMAP, FTP, et je suis en train de regarder pour migrer ce qui est utilisé par Apache pour y mettre dedans aussi (au moins la gestion des comptes). Et puis si c'est la folie, ptêtre l'authentification des comptes locaux (via pam_sql) \o/


    Maintenant que j'ai mis pas mal de choses dans cette BD, je me demande quels avantages j'aurais eu à choisir un serveur LDAP pour stocker ça à la place ?

    J'ai pas vraiment rencontré de limitations avec les *mod_sql que j'ai utilisé jusqu'à présent, à part deux fonctionnalités (mais j'ai pas encore vraiment regardé non plus), à savoir :
    * faire du virtual hosting avec Apache : ya un module LDAP [1] pour ça je crois, je sais pas si il y a l'équivalent en SQL ;
    * gérer des carnets d'adresses : bon, j'avoue que c'est ça au départ qui m'a fait intéressé à LDAP :-)

    Pour les applications serveurs que j'utilise (je dis pas si c'est généralisé), j'ai trouvé à chaque fois un équivalent SQL à LDAP...


    Après, je me doute fort que pour des applications qui utilisent complètement LDAP, ça va coincer. Mais lesquelles ?

    D'une manière générale, ma question reste donc ouverte (recopitage de la question d'au dessus) : "quels avantages j'aurais eu à choisir un serveur LDAP pour stocker ça à la place ?"

    [1] : http://modvhostldap.alioth.debian.org/
    • [^] # Re: LDAP ou SGBDR ?

      Posté par . Évalué à 5.

      quelques avantages :

      1/ sécurité : la plupart du temps, quand tu veux vérifier un login/mdp :
      * en SQL, c'est le même compte utilisateur SQL qui va faire une recherche dans ta table utilisateurs avec le login et le mot de passe. Donc si ton site est compromis, et que quelqu'un arrive à récupérer ce fameux compte ou faire une recherche en l'utilisant, par exemple via une injection SQL, il peut lire tous les mots de passe de ta base
      * en LDAP, ce n'est pas une recherche qui est faite mais une authentification, directement en utilisant le login et le mot de passe (ou le DN et le mot de passe). Donc aucun compte n'a besoin de pourvoir lire les mots de passe. Donc ceux-ci sont mieux protégés.

      2/ performance : les principes de modèle arborescent LDAP permettent d'effectuer des recherches significativement plus rapides. Je ne sais pas pourquoi. Mais on le lit de partout.

      3/ intéropérabilité : même si comme tu dis les modules SQL existent de partout, il est plus facile de faire un module LDAP que SQL : moins de paramétrage nécessaire car des schémas standards d'utilisateurs/groupes/... existent, protocole identique quel que soit le vendeur, etc.
  • # Supports de formation LDAP et SSO en Creative Commons

    Posté par (page perso) . Évalué à 2.

    Bonjour,

    j'ai rédigé plusieurs supports de formations pour LINAGORA qui sont en Creative Commons et publiés sur http://www.linagora.org:
    * Protocole LDAP : http://www.linagora.org/article138.html
    * OpenLDAP : http://www.linagora.org/article137.html
    * Optimisation OpenLDAP : http://www.linagora.org/article143.html
    * SSO avec LemonLDAP::NG : http://www.linagora.org/article166.html

Suivre le flux des commentaires

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