OpenLDAP – Classe personnalisée

Bonjour,

J’ai eu l’occasion de travailler sur OpenLDAP pour le boulot. Vu comment j’ai parfois eu du mal à trouver des informations à jour, je me suis dit que j’allais écrire quelques articles là-dessus. Si ça peut éviter à certaines personnes de passer autant de temps que moi, ce sera ça de gagné !

Pour aujourd’hui, j’ai choisi de vous montrer comment ajouter une classe personnalisée à votre LDAP. Pourquoi commencer avec ça ? Parce que je crois que c’est le truc sur lequel j’ai le plus galéré !

Notez juste que j’utiliser la version 2.4 d’OpenLDAP. Je ne peux pas garantir que tout ce que j’écris ici fonctionne avec les versions précédentes, et encore mois celles d’après. La différence entre la 2.4 et les précédentes, c’est que la configuration se fait avec OLC (On-Line Configuration), le cn=config que l’on voit un peu partout, et non plus directement dans des fichiers de configuration. Je vous ferai un article sur la création du LDAP en lui-même, mais en attendant, je prends pour acquis que vous en avez un qui tourne. Ce n’est clairement pas le plus dur !

La théorie

Bin oui, le but c’est quand même de comprendre ce que vous faîtes, et pas juste de suivre des instructions. Parce que je vais expliquer ne sera pas forcément valable à 100 % dans toutes les situations. Mais si vous comprenez le principe, vous vous en sortirez.

En gros, pour configurer OpenLDAP, vous écrivez des fichiers LDIF spécifiant des instructions à exécuter, et ensuite vous le transmettez au service OpenLDAP avec des commandes comme ‘ldap_add’ ou ‘ldap_modify’.

Ce qu’il faut savoir aussi, c’est que les différents objets du LDAP s’organisent de manière hiérarchique. Ils héritent de différentes choses les uns des autres. Pour pouvoir utiliser des attributs supplémentaires dans notre LDAP, vous pourriez tout à fait les ajouter à une classe existante. Mais si un jour vous souhaitez faire une mise à jour du LDAP, il y a un risque de perdre vos ajouts. L’idéal est donc de créer une classe supplémentaire, qui hérite d’une classe existante, et à laquelle vous rattacherez vos nouveaux attributs.

Concrètement, on trouve à la base de tout l’objet « top ». De lui est issu « person », de qui hérite ensuite « organizationalPerson », de qui hérite finalement « inetOrgPerson ». On peut donc ajouter une classe « customPerson » qui va elle-même hériter de « inetOrgPerson ». On peut dire que notre classe va surcharger la classe « inetOrgPerson », ça parlera à ceux qui connaissent la programmation orientée objet.

La pratique

La pratique n’est pas compliquée. Vous devez créer un fichier LDIF qui va contenir les informations nécessaires pour créer votre nouvelle classe et ses attributs :

dn: cn=customPerson,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: customPerson
olcAttributeTypes: ( 2.25.196563589746542389.1
       NAME 'telephoneNumber2'
       DESC 'Secondary telephone number'
       SUP telephoneNumber
       SINGLE-VALUE )
olcAttributeTypes: ( 2.25.196563589746542389.2
       NAME 'isExpert'
       DESC 'Boolean indicating if the person is an expert'
       EQUALITY booleanMatch
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
       SINGLE-VALUE )
olcAttributeTypes: ( 2.25.196563589746542389.3
       NAME 'gender'
       DESC 'Gender of the user (male/female)'
       EQUALITY caseIgnoreMatch
       SUBSTR caseIgnoreSubstringsMatch
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
       SINGLE-VALUE )
olcAttributeTypes: ( 2.25.196563589746542389.5
       NAME 'grade'
       DESC 'Grade'
       EQUALITY caseIgnoreMatch
       SUBSTR caseIgnoreSubstringsMatch
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
       SINGLE-VALUE )
olcObjectClasses: ( 2.25.196563589746542389.10
       NAME 'customPerson'
       DESC 'Custom class for a person'
       SUP inetOrgPerson
       STRUCTURAL
       MAY ( telephoneNumber2 $ gender $ grade )
       MUST ( isExpert ) )

Globalement dans ce fichier on a :

• Le nom de la nouvelle classe, et là où notre objet va être intégré dans la partie configuration du LDAP (cn=schema,cn=config)
• La liste des attributs (telephoneNumber2, isExpert, gender, grade), avec chaque fois :
  • Un identifiant qui doit être unique (vous pouvez ré-utiliser les miens en modifiant quelques chiffres)
  • De manière obligatoire : le nom de l’attribut (NAME) et sa syntaxe (SYNTAX)
  • De manière facultative : la description (DESC), des règles de comparaison (EQUALITY, SUBSTR), et SINGLE-VALUE (on ne peut avoir qu’une fois cette attribut pour une entrée. Si SINGLE-VALUE n’est pas indiqué, alors on peut avoir plusieurs valeurs)
• La définition de notre classe (à partir de la ligne 29) avec :
  • Encore une fois un identifiant unique
  • La classe dont elle hérite (SUP)
  • Le type de classe (STRUCTURAL ou ABSTRACT, il faudrait tout un article là-dessus !)
  • Les attributs facultatifs (MAY)
  • Les attributs obligatoires (MUST)

Pour les syntaxes, le plus simple est de s’inspirer d’attributs existants. Vous trouverez des infos anglais ici, ou encore ici. Vous avez aussi une traduction française de la RFC 2252 (doc définissant les syntaxes LDAP) ici, si l’anglais ne vous inspire pas.

Pour les règles de comparaison (les matching rules en anglais) EQUALITY, SUBSTR et ORDERING, les règles par défaut suffisent la plupart du temps. Si vous voulez modifier le comportement par défaut, vous trouverez de la doc utile sur le site de Zytrax, sur le site LDAPwiki.com et sur la doc officielle d’OpenLDAP (regardez en particulier le tableau 8.4).

Le nom de votre nouvelle classe est à mettre aux lignes 1, 3 et 30.

Voilà. N’hésitez pas à me dire si certaines choses ne sont pas claires dans ce fichier LDIF. Il ne reste plus qu’à l’envoyer à notre serveur OpenLDAP. Pour cela, il suffit d’une commande exécutée sur le serveur lui-même :

ldapadd -c -Y EXTERNAL -H ldapi:/// -f /mnt/partage/add-class-customperson.ldif

Que veut dire cette commande :

• Le « -c » signifie que la commande continue quand même en cas d’erreur
• Le « -Y EXTERNAL -H ldapi:/// » permet de s’authentifier automatiquement, mais ça ne marche qu’en local
• Le « -f » charge le fichier LDIF qu’on lui indique. Bien sûr ce fichier contient les lignes que nous avons commentées.

Conclusion

Normalement, la configuration se fait sans avoir besoin de redémarrer le serveur OpenLDAP. Vous pouvez utiliser la nouvelle classe, et les attributs qui y sont définis.

Par contre, si vous utiliser Apache Directory Studio pour vous connecter à votre LDAP, alors il se peut qu’il ne vous propose pas votre classe, ou qu’il l’indique en italique. J’ai cherché pendant un moment, pensant que l’ajout de ma classe n’avait pas marché. Mais en fait c’est ce logiciel Apache Directory Studio qui ne voit pas les ajouts que nous avons fait, le LDAP va très bien. Ce n’est pas grave, il suffit de cliquer droit sur votre connexion, et choisir « Recharger schéma » :

On peut aussi avoir éventuellement à recharger l’entrée. Se placer tout en haut de l’arborescence sur RootDSE, cliquer bouton droit et choisir « Recharger l’entrée » :

Voilà. On y est. Cet article est déjà bien long, et pourtant j’ai bien conscience de ne pas avoir tout détaillé. Je complèterai au fur et à mesure avec d’autres articles sur OpenLDAP. J’espère que ça sera utile à d’autres personnes.

N’hésitez pas à me signaler en commentaire s’il y a des choses qui ne sont pas claires.

@+ !

Michaël