La gestion et la mise à jour des schémas dans un annuaire OpenLDAP reste compliquée pour les non‐initiés.
Le projet FusionDirectory avait donc créé des outils qui permettent de simplifier la gestion des schémas pour son utilisation propre.
Suite aux demandes des utilisateurs de pouvoir utiliser ces outils hors du contexte FusionDirectory, nous avons créé un nouvel outil, ldap-schema-manager, qui peut être utilisé indépendamment. Il est sous licence GPL v2+.
Il s’agit en fait de l’outil fusiondirectory-insert-schema qui a été rendu générique pour pouvoir être utilisé y compris par les personnes n’utilisant pas FusionDirectory pour gérer leur arbre OpenLDAP.
Dans la prochaine version de FusionDirectory, fusiondirectory-insert-schema se basera sur ldap-schema-manager (avec la seule différence d’insérer par défaut les schémas FusionDirectory, et de chercher dans le dossier de schéma FusionDirectory au lieu du dossier standard utilisé par défaut dans l’outil générique).
Installation
L’installation peut se faire sous Debian, RHEL, CentOS, Scientific Linux en utilisant les dépôts mentionnés ci‐dessus. Le code source est disponible sous forme d’archive tar.gz sur le dépôt http://repos.fusiondirectory.org/sources/, ainsi que sur le miroir chez GitHub.
Utilisation
Lister les schémas déjà insérés :
ldap-schema-manager -l
Insérer un schéma depuis le dossier standard :
ldap-schema-manager -i cosine
Pour insérer /etc/ldap/schema/cosine.ldif ; spécifier cosine.schema pour convertir /etc/ldap/schema/cosine.schema en LDIF et insérer le résultat.
Insérer un schéma depuis un fichier quelconque :
ldap-schema-manager -i /path/to/your/file.schema
Mettre à jour un schéma :
ldap-schema-manager -m /path/to/your/file.schema
Vider un schéma :
ldap-schema-manager -e schema_name
Attention : Cela vide le schéma mais le nœud sera toujours présent dans l’arbre de cn=schema,cn=config.
Il est impossible de supprimer un nœud de cn=schema,cn=config à notre connaissance, à part en arrêtant le serveur LDAP et en supprimant le fichier à la main (dans le cas d’un back‐end fichiers). L’outil propose donc cette solution pour pouvoir retirer un schéma sans arrêter le serveur LDAP, mais le schéma sera toujours listé dans les schémas présents par -l.
La conversion de schéma vers LDIF est faite par l’outil schema2ldif, déjà disponible depuis un moment. La seule contrainte est que le schéma liste d’abord les attributs puis les_ objectClass_, ce qui est le cas dans tous les schémas standards qu’on a pu croiser.
L’outil cherchera un fichier avec l’extension .ldif si son extension .schema n’est pas explicitement donnée.
Lors de l’insertion avec -i, l’opération échouera si un schéma de même nom est déjà présent.
À l’inverse, lors d’un -m, l’opération échoue si un schéma du même nom n’est pas présent.
Il faut donc faire attention si l’on veut insérer un schéma vidé par -e, il faut utiliser -m et non pas -i.
On peut spécifier autant de schémas à insérer que l’on veut dans la même commande (s’ils sont dans le même dossier, vous pouvez spécifier d’abord le dossier puis la liste des noms de schéma après le -i ou -m).
Pour plus d’informations, consultez l’aide de l’outil :
$ ldap-schema-manager -h
usage: /usr/bin/ldap-schema-manager [-y] [-n] [-c] [-o options] [path] [-h|-l|-i schema1 schema2|-m schema1 schema2|-e schema1 schema2]
-h, --help : this (help) message
path : where to find the schemas
-i, --insert : specify the schemas to insert
-l, --list : list inserted schemas
-m, --modify : modify exising inserted schemas
-e, --empty : empty exising inserted schemas (do not remove them)
-n, --nodelete : do not delete generated ldifs at the end
-o, --options : set ldap options used (default is -Y EXTERNAL -H ldapi:///)
-c, --continue : continue on error(s)
-y, --yes : answer yes to all questions
Default path is /etc/ldap/schema/Aller plus loin
- Forge du projet (231 clics)
- Page de l’outil (627 clics)
- Téléchargement pour Debian (202 clics)
- Téléchargement pour Redhat / Centos (144 clics)
- Téléchargement pour Scientific Linux (128 clics)
- Télécharger les sources (139 clics)
# Suppression de schéma
Posté par KPTN (site web personnel, Mastodon) . Évalué à 5.
Pour information la suppression de schéma dans le backend cn=config (comme la suppression de n'importe quel nœud de configuration d'ailleurs) devrait être possible dans OpenLDAP 2.5, ou alors dans OpenLDAP 2.4 à condition de le compiler avec l'option SLAP_CONFIG_DELETE.
Sinon bravo pour cet excellent outil !
[^] # Re: Suppression de schéma
Posté par Benoit Mortier . Évalué à 4.
Bonjour,
Merci on a essye de faire simple et pratique
Benoit Mortier - CEO FusionDirectory
# LDAP... toujours pas :(
Posté par gUI (Mastodon) . Évalué à 2.
Est-ce l'outil qui va me mettre au LDAP ? Peut-être, en tous cas je vais jeter un œil.
A chaque fois que je me motive pour m'y mettre, je finis par abandonner. J'ai toujours pas compris le concept. Par exemple ces fameux schéma. Je sais que je peux puiser dans une base existante de schémas "pas déconnants". Mais ensuite, comment savoir, pour chaque appli qui dit "LDAP compatible" si mon schéma finalement choisi sera le bon ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: LDAP... toujours pas :(
Posté par Julien L. . Évalué à 1.
A un moment j'utilisais la Mandriva Directory Server (MDS) et Mandriva Management Console (MMC comme à la M$) sur une Debian pour gérer de façon simplifiée mon LDAP (voir ici). C'était vraiment bien fait, ça marchait aussi avec les domaines et utilisateurs/emails virtuel.
Je ne sais pas si c'est encore possible sur les version récentes de Debian, j'utilise phpLDAPAdmin maintenant. Mais tout les schémas et configurations LDAP mises en place avec (et pour) MDS fonctionnent toujours très bien.
Ensuite les applications qui utilisent le LDAP, soit c'est une utilisation "basique" type authentification et on a juste un ou deux champs à préciser soit, si c'est plus complexe, on peut leur "décrire" le schéma à utiliser.
[^] # Re: LDAP... toujours pas :(
Posté par droide (site web personnel) . Évalué à 1.
Dans ce cas, je te conseil FusionDirectory !
Nous l'utilisons et l'interfaçons avec différents outils compatibles LDAP (Splunk, FreeRadius sur pfSense, Zabbix, GLPI, Libertempo, FileMaker, etc …)
[^] # Re: LDAP... toujours pas :(
Posté par MTux . Évalué à 3.
C'est toujours maintenu ?
[^] # Re: LDAP... toujours pas :(
Posté par Julien L. . Évalué à 1.
Tout dépend ce qu'on entend pas la.
Le dernier "commit" sur Github date de Octobre 2016, il y a quelques discussions dans la partie "Issue".
Pour moi, ça "juste fonctionne"
Je sécurise quand même l'accès au site lui-même pour éviter les vulnérabilités du type "injection".
[^] # Re: LDAP... toujours pas :(
Posté par Benoit Mortier . Évalué à 2.
Bonjour,
ça c'est la vielle idée que ldap est juste quelques données et juste de l'authentification, ce qui n'est vraiment plus le cas aujourd’hui.
les annuaires sont complexes et contiennent beaucoup de données manipulées par des gens différents et venant de sources différentes.
Les schémas sont essentiels mais il faut éviter de créer ses propres schémas qui finissent souvent par dupliquer ce qui existe et les utiliser a bon escients
FusionDirectory est un outil développé pour gérer la complexité d'un annuaire actuel, mais de manière simple et structurée et qui permet d’enrichir l'application avec des données personnelles
https://www.fusiondirectory.org/
Bonne journée
Benoit Mortier - CEO FusionDirectory
[^] # LDAP, mon approche
Posté par Arthur Accroc . Évalué à 3.
Je ne sais pas dans quelle mesure ça c’est amélioré, mais quand je me suis mis à LDAP, il y a presque quinze ans (ça ne me rajeunit pas…), il y avait d’un côté des documentations qui l’abordaient d’un point de vue complètement théorique et souvent abscons, et de l’autre des utilitaires pour « migrer » par exemple d’un annuaire NIS en reproduisant totalement à l’identique son contenu (des tables séparées, pas forcément cohérentes — par exemple un mail nom.prenom qui traîne dans la table des alias pour un login supprimé).
Pas très utile pour faire un annuaire LDAP cohérent mais qui rend le service attendu.
Accessoirement, à l’époque, les applications n’étaient pas forcément documentées par rapport aux attributs LDAP qu’elles utilisaient (quand il n’y avait pas carrément une documentation erronée)…
Pour ça, j’ai une approche inverse :
– déterminer ce qu’utilisent les applications comme attributs, selon leur documentation si elle est correcte, sinon carrément en activant la trace du serveur LDAP et en les testant pour voir ce qu’elles font comme requêtes ;
– rechercher dans les schémas quelles sont les classes qui fournissent les attributs en question et choisir les plus cohérentes par rapport au besoin ;
– utiliser les schéma qui les contiennent.
Cela dit, certaines applications font des requêtes selon la classe des objets (on utilise plutôt le terme « entrée » selon la nomenclature LDAP, mais ça va peut-être être plus abordable si je m’en tiens à « objet ») ou ont carrément un schéma dédié. Dans ce cas, le choix de la classe et du schéma est sans ambiguïté.
Il faut voir qu’un objet peut appartenir à plusieurs classes, par exemple person pour une personne, inetOrgPerson pour son adresse mail (entre autres), posixAccount pour son compte Unix.
On peut aussi surclasser ou déclasser des objets existants. Par exemple, si on veut créer un compte Unix pour une personne qui n’en avait pas, et donc que l’objet qui la représente ne faisait pas partie de la classe posixAccount, on peut lui ajouter cette classe et les attributs nécessaires pour le compte Unix.
L’intérêt de rassembler dans un seul objet tous les attributs concernant une personne (ou toute autre entité du monde réel), c’est la cohérence. Si une personne part, en supprimant son objet, on supprime à la fois son alias mail, son compte Unix, etc. (bon, une organisation officielle préférera probablement garder trace de ses anciens membres et déplacer les objets qui les représentent dans une branche séparée).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.