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.
[^] # Re: Ce n'est pas une bonne idée
Posté par Nap . En réponse au journal S'initier à LDAP. É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é :)