Dans notre annuaire LDAP (slapd, OpenLDAP), nous avons créé une classe auxiliaire (oui, il y existe différents types de classe LDAP). Avec ldapvi, on ajoute des attributs de cette classe sur des objets qui existent déjà. Cela fonctionne. On modifie la valeur d'un attribut sur ce même objet : cela fonctionne. On tente de supprimer les attributs ajoutés (sans supprimer l'attribut « objectClass »), ça échoue pour l'un d'eux:
ldap_modify: Inappropriate matching (18)
additional info: modify/delete: monAttribut: no equality matching rule
Dans la définition d'un attribut, il est possible de définir des règles de comparaison. Un peu comme la surcharge des opérateurs de comparaison permettant de comparer des objets maison dans les langages de programmation orienté objet. Par exemple, pour une chaîne de caractères, on utilise souvent la règle « caseIgnoreMatch » (mais on peut aussi utiliser « telephoneNumberMatch », « caseExactMatch », etc., toutes définies dans le RFC 4517).
Dans mon cas, l'attribut est de type booléen (si, c'est possible, le RFC 4517 en normalise la définition) :
attributetype ( 1.3.6.1.4.1.7135.1.3.39.2.1.23
NAME 'monAttribut'
DESC 'Attribut de test'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7)
Et, en effet, comme il s'agit d'un booléen, je n'ai pas précisé de règle de comparaison, en pensant que c'est évident (alors que cet exemple illustre qu'il n'y a pas de règle de comparaison par défaut). Il existe la règle de comparaison « booleanMatch », qu'il suffit d'ajouter à la définition de notre attribut pour résoudre le problème :
attributetype ( 1.3.6.1.4.1.7135.1.3.39.2.1.23
NAME 'monAttribut'
DESC 'Attribut de test'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7)