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 :-)
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 :-)
> Lire le journal (35 commentaires, moyenne: 3,3).
Vous avez demandé le commentaire #920300.
Run by 
Cette page a été générée par Templeet en 0.0629s (dont 0.0072 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Ce n'est pas une bonne idée
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
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
toi mon bébert tu me plais !
[^]Re: Ce n'est pas une bonne idée
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
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
Je me trompe où c'est exactement ce qui est proposé ici ?
http://forum.dotclear.net/viewtopic.php?id=21902
(note : olivier, l'auteur du post, est le dev principal de dotclear)
[^]Re: Ce n'est pas une bonne idée
Oui c'est à ça que je pensais. Ici le lien avec LDAP est donc le login, ce qui est la manière la plus simple de faire (pas besoin de changer le schéma SQL de dotclear pour rajouter une valeur d'attribut LDAP servant à identifier l'utilisateur) et dans ton cas ne pose pas de pb de sécurité je pense.
[^]Re: Ce n'est pas une bonne idée
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
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
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
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
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
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.