Si utiliser le dn complet est trop contraignant pour tes utilisateurs, je me demande avec quel client LDAP tu comptes leur permettre d'afficher les données fournies par ton serveur. En effet, s'il s'agit d'un annuaire d'entreprise dans lequel on peut trouver les coordonnées des différents collaborateurs, celui-ci n'a pas besoin d'être accessible qu'avec identification préalable d'un utilisateur. En général, on permet l'accès anonyme aux données non critiques (comme userPassword). Un contrôle d'accès à ce type d'attributs et personne, à part l'administrateur et l'utilisateur correspondant au dn ne pourra lire cet attribut :
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
access to attrs=userPassword
by dn="cn=manager,dc=example,dc=com" write
by anonymous auth
by self write
by * none
Pour SASL, il est possible d'obtenir une identification pour OpenLDAP qui ne se base pas sur le seul dn et permette un couple « classique » d'uid et mot de passe. Il y a toutefois plusieurs mécanismes disponibles avec SASL et je vais en citer quelques-un :
- GSSAPI ;
- DIGEST-MD5 ou CRAM-MD5 ;
- EXTERNAL.
La commande suivante te permettra de savoir quels sont les mécanismes supportés par ton serveur :
Le premier (GSSAPI) évoque Kerberos est nécessite donc d'avoir déjà un royaume disponible. L'avantage, en entreprise, c'est que tes utilisateurs n'auraient plus besoin de s'identifier auprès du serveur LDAP pour y accéder tout en étant identifiés.
Le deuxième s'appuie sur une base locale, sasldb, pour stocker les utilisateurs. Il faudrait donc créer autant d'utilisateurs dans cette base que d'utilisateurs dans le serveur LDAP. S'ils sont nombreux, cela peut s'avérer très rébarbatif.
Le troisième fait appel à un processus externe.
Cependant, le projet Cyrus-SASL fournit un service nommé saslauthd qui peut être utilisé pour exploiter l'un ou l'autre mécanisme et c'est là où le serpent peut finir par se mordre la queue car il est possible d'interroger un serveur ...LDAP. C'est exactement ce que je fais pour postfix.
# OpenLDAP et SASL
Posté par Raphaël SurcouF (site web personnel) . En réponse au message Couple login/password pour accèder à OpenLDAP. Évalué à 1.
Pour SASL, il est possible d'obtenir une identification pour OpenLDAP qui ne se base pas sur le seul dn et permette un couple « classique » d'uid et mot de passe. Il y a toutefois plusieurs mécanismes disponibles avec SASL et je vais en citer quelques-un :
- GSSAPI ;
- DIGEST-MD5 ou CRAM-MD5 ;
- EXTERNAL.
La commande suivante te permettra de savoir quels sont les mécanismes supportés par ton serveur :
Le premier (GSSAPI) évoque Kerberos est nécessite donc d'avoir déjà un royaume disponible. L'avantage, en entreprise, c'est que tes utilisateurs n'auraient plus besoin de s'identifier auprès du serveur LDAP pour y accéder tout en étant identifiés.
Le deuxième s'appuie sur une base locale, sasldb, pour stocker les utilisateurs. Il faudrait donc créer autant d'utilisateurs dans cette base que d'utilisateurs dans le serveur LDAP. S'ils sont nombreux, cela peut s'avérer très rébarbatif.
Le troisième fait appel à un processus externe.
Cependant, le projet Cyrus-SASL fournit un service nommé saslauthd qui peut être utilisé pour exploiter l'un ou l'autre mécanisme et c'est là où le serpent peut finir par se mordre la queue car il est possible d'interroger un serveur ...LDAP. C'est exactement ce que je fais pour postfix.
J'avoue cependant ne pas avoir poussé plus que cela la recherche quant OpenLDAP et SASL mais voici ce que j'ai trouvé sur Google pour t'aider :
http://www-lor.int-evry.fr/~michel/LDAP/SASL/ActivationSASL.(...)
http://www-lor.int-evry.fr/~michel/LDAP/SASL/Scenarios/diges(...)
Pour diriger ta recherche, la directive sasl-regexp semble pouvoir répondre à ton besoin.