Ubuntu-fr

mouraddj

OpenLDAP case sensitivity

Salut,

Je suis novice avec OpenLDAP , Je désire créer des entité en respectant la casse (ex créer une personne ou une organisation « TOTO » et une autre « toto ».
J’ai bon essayé mais sans succès (j’ai tjrs l’erreur LDAP « already exist »).

J’ai edité tous le fichiers schema LDAP (core, cosine, nis, …) et j’ai remplacer toute occurrence caseIgnoreMatch par caseExactMatch et toute  occurrence  caseIgnoreSubstringsMatch par caseExactSubstringsMatch.

Sauf que, cela n’a rien donné !!
Le résultat de la commande ldapsearch ignore tjrs cette modification :

////////////////////////////
lival253,root,root > ./ldapsearch -x -s sub -W -D cn=Admin "cn=toto" -LLL
Enter LDAP Password:
dn: cn=toto
objectClass: top
objectClass: person
sn: toto
cn: toto

lival253,root,root > ./ldapsearch -x -s sub -W -D cn=Admin "cn=TOTO" -LLL
Enter LDAP Password:
dn: cn=toto
objectClass: top
objectClass: person
sn: toto
cn: toto

lival253,root,root >
/////////////////////////////////////////////////

Si j’ai bien compris, la deuxième recherche ne devrait pas aboutir, non ?
S’agit il d’un bug LDAP connu ?

Merci, pour toute idée,

Mourad

mouraddj

Re : OpenLDAP case sensitivity

Visiblement, il n'ya personne qui a sa petite idée sur le sujet, ou bien jiai ma exprimé le problème ?

Es ce que OpenLDAP est case sesitive?

Merci,

nap

Re : OpenLDAP case sensitivity

Bonjour,

je crois que le type d'attribut cn n'est pas défini dans un fichier de schéma mais inclu directement dans le code d'OpenLDAP. Tu ne peux donc pas modifier sa syntaxe par un fichier, il te faudrait patcher OpenLDAP.

la seule solution autre que le patch semble donc l'utilisation d'autres objets que personne, avec d'autres attributs que cn.

François

JoelS

Re : OpenLDAP case sensitivity

Es ce que OpenLDAP est case sesitive?

C'est pas OpenLDAP qui est en cause, mais la norme LDAP.

Attention, la norme LDAP (les normes en fait) recouvre à la fois un langage d'interrogation d'annuaire, un protocole de connexion/communication, mais aussi des schémas pré-établis, etc etc.

Parmi ces schémas (une bonne tripotée), il y en a un qui défini ce qu'est un CN (alias de commonName) et comment ça se comporte, au sens LDAP. Donc la norme a décidé qu'un CN, c'est case-insensitive. Point. T'amuses pas à changer ça dans ton cas pour forcer la gestion de la casse sur cet attribut, car tu tomberas un jour ou l'autre sur un outil qui plantera car il ne s'y attendra pas.

Par ailleurs, le fait que CN soit en majuscule ou non, c'est pas important. Il faut éviter d'utiliser le CN comme un élément du Distinguished Name (DN) d'une entrée LDAP. Le CN n'est alors plus qu'un attribut comme un autre, multi-valué d'ailleurs, donc tu peut avoir plusieurs entrées ayant le même CN ou un CN commun, car la distinction se fait par le DN (d'ou son nom). Dans le DN, tu utilises un attribut sûr, unique, et pérenne vis à vis de ce que tu veut faire. Par exemple un UID généré à partir du CN et d'un compteur incrémental si besoin.

mouraddj

Re : OpenLDAP case sensitivity

Bonjour Joels,

Merci pour ta réponse et tes explications précieuses.
En faite, mon problème à l’origine n’est pas avec OpenLDAP. Je travaille sur une application qui utilise OpenLDAP pour stocker les données.
L’application est intégrée avec LDAP via un fichier schema (au sein duquel on déclare toute les entité à gérer).
Au début toutes les déclarations au sein de ce fichier schema  utilisaient la valeur caseIgnoreMatch pour  « EQUALITY ».
Seulement, récemment, un de nos clients vient d’exiger que notre application dois gérer la casse (afin de pouvoir créer un entité TOTO et une autre du même genre mais s’appelant toto).

D’après les gens d’OpenLDAP, le jeux doit se faire au sein de notre fichier schema (celui de notre application) et non pas coté LDAP.

J’ai bon essayé, mais sans succès.

Voici un extrait de mon fichier schema avant modification :

////////////////////////////
attributetype ( 1.3.12.2.1006.63.0.6.0.108 NAME 'secFadName'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

attributetype ( 1.3.12.2.1006.63.0.6.0.109 NAME 'secOadName'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

# FAD
objectclass ( 1.3.12.2.1006.63.0.6.0.4
        NAME 'secFad'
        SUP top
        STRUCTURAL
        MUST ( name $ secAccessRight ) )

# OAD
objectclass ( 1.3.12.2.1006.63.0.6.0.5
        NAME 'secOad'
        SUP top
        STRUCTURAL
        MUST ( name $ secAccessRight ) )
…............

/////////////////////////////////////////

Merci pour toute idée.

Mourad