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 :-)
Journal S'initier à LDAP
5
avr.
2008
# mds
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
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 libre Cuauhtémoc . Évalué à 5.
Si ça se fait, je te paie une pinte de guinness dans le quartier mouffetard
[^] # Re: mds
Posté par B16F4RV4RD1N . Évalué à 4.
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 Raoul Volfoni (site web personnel) . Évalué à 5.
Mais c'est de toutes façons un très bon bouquin que je te recommande.
[^] # Re: O'Reilly comme d'hab...
Posté par Olivier Grisel (site web personnel) . Évalué à 4.
http://www.zytrax.com/books/ldap/
En voici le meilleur client LDAP sur terre (a utiliser comme navigateur ou console d'administration ou pour l'edition de schemas) :
http://directory.apache.org/studio/
# Ce n'est pas une bonne idée
Posté par groumf . Évalué à 5.
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 PLuG . Évalué à 6.
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 groumf . Évalué à 0.
[^] # Re: Ce n'est pas une bonne idée
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
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 ?
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Ce n'est pas une bonne idée
Posté par Nap . Évalué à 4.
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 ploum (site web personnel, Mastodon) . Évalué à 2.
http://forum.dotclear.net/viewtopic.php?id=21902
(note : olivier, l'auteur du post, est le dev principal de dotclear)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Ce n'est pas une bonne idée
Posté par Nap . Évalué à 1.
[^] # Re: Ce n'est pas une bonne idée
Posté par Tonton Benoit . Évalué à 5.
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 Mes Zigues . Évalué à 4.
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 Raphaël SurcouF (site web personnel) . Évalué à 4.
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 matt23 . Évalué à 2.
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 Nap . Évalué à 2.
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 amielp . Évalué à 1.
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 Matthieu . Évalué à 2.
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.
[^] # Re: Le meilleur moyen de comprendre LDAP
Posté par Christophe Chailloleau-Leclerc . Évalué à 9.
[^] # Re: Le meilleur moyen de comprendre LDAP
Posté par Matthieu . Évalué à 3.
Et si vous êtes plusieurs, genre 4 :
make -j 4 install
:-)
[^] # Re: Le meilleur moyen de comprendre LDAP
Posté par Larry Cow . Évalué à 3.
[^] # Re: Le meilleur moyen de comprendre LDAP
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
une interface graphique c'est bien pour naviguer dans l'annuaire LDAP
Mais bon j'utilise GQ pour cela et a postériori je me dit que c'est n'est pas forcement à ce type de frontend que tu faisait reference....
# c'est une idée qui me trotte aussi dans la tête
Posté par bertrand . Évalué à 2.
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 Raphaël SurcouF (site web personnel) . Évalué à 2.
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 Benoît Bailleux (Mastodon) . Évalué à 2.
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 GG (site web personnel) . Évalué à 2.
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
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Partage du carnet d'adresse...
Posté par MrLapinot (site web personnel) . Évalué à 2.
# Mon expérience
Posté par P Chevalier . Évalué à 3.
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 Raphaël SurcouF (site web personnel) . Évalué à 6.
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 davux (site web personnel) . Évalué à 4.
- 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 Stéphane Davy . Évalué à 3.
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 jon . Évalué à 2.
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 Nap . Évalué à 5.
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 KPTN (site web personnel, Mastodon) . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.