Sortie de l’outil ldap-schema-manager

28
16
mai
2017
Administration système

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/
  • # Suppression de schéma

    Posté par (page perso) . Évalué à 5 (+3/-0).

    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 !

  • # LDAP... toujours pas :(

    Posté par . Évalué à 2 (+0/-0).

    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 ?

    • [^] # Re: LDAP... toujours pas :(

      Posté par . Évalué à 1 (+0/-0).

      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 (page perso) . Évalué à 1 (+1/-0).

        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 . Évalué à 3 (+1/-0).

        phpLDAPAdmin

        C'est toujours maintenu ?

        • [^] # Re: LDAP... toujours pas :(

          Posté par . Évalué à 1 (+0/-0).

          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 . Évalué à 2 (+0/-0).

        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

    • [^] # LDAP, mon approche

      Posté par . Évalué à 3 (+1/-0).

      A chaque fois que je me motive pour m'y mettre, je finis par abandonner. J'ai toujours pas compris le concept.

      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)…

      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 ?

      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).

      Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.