• # C'est vrai :)

    Posté par  . Évalué à 7.

    LDAP, c'est un peu comme SNMP, c'est vieux, les syntaxes ASN.1 sont horribles, la doc est nulle, c'est pas souple…

    Mais… Le truc super, c'est que les classes de base sont bien définies et ont peu bougé depuis des années, idem pour les protocoles réseau, ce qui donne un niveau d'interopérabilité incroyable sur des systèmes hétérogènes, comparativement à d'autres mécanismes plus souples.

    Sinon pour avoir un OID d'entreprise, c'est gratuit, ça se fait auprès de l'IANA par exemple, mais tout le monde ne peut pas en avoir un : https://pen.iana.org/pen/PenApplication.page

    On peut aussi mentionner l'outil shelldap qui permet de donner du ls/cd/cat/rm dans l'annuaire :)

    • [^] # Re: C'est vrai :)

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Merci pour les infos !

      Pour les classes de base, je suis d'accord… sauf quand un Microsoft AD vient mettre son nez dans le bazar (c'est-à-dire « trop souvent » en entreprise). Les classes additionnelles AD sont disponibles, mais rien que les charger selon la configuration de ton LDAP, ça peut être la purge…

      Au-delà de ça, tant qu'on s'en sert pour du bind, normalement ça se passe bien, même sur des systèmes hétérogènes – tant qu'on arrive à récupérer la configuration exacte à utiliser pour chaque sous-système, mais ça c'est un problème d'organisation.

      Pour l'OID on m'avait dit que c'était payant, sans que je sache si c'est une information qui a été vraie un jour, ou qui ne l'a jamais été.

      La connaissance libre : https://zestedesavoir.com

    • [^] # Re: C'est vrai :)

      Posté par  . Évalué à 2.

      Sinon pour avoir un OID d'entreprise, c'est gratuit, ça se fait auprès de l'IANA par exemple, mais tout le monde ne peut pas en avoir un

      Je ne sais pas si les conditions d’obtention ont changé depuis, mais j’en avais obtenu un il y a une quinzaine d’années. On ne m’a opposé aucune difficulté, juste une ou deux questions sur ce que je comptais en faire. L’OID m’a été attribué en trois jours.

      On peut aussi mentionner l'outil shelldap

      À l’époque où je faisais du LDAP (il y a une quinzaine d’années donc), j’aimais bien aussi ldapvi, pour modifier des entrées LDAP au format LDIF depuis un éditeur comme Vim.

      Je ne sais pas s’il est toujours utilisable, la dernière mise à jour date de 2010… Il compile toujours en tout cas (modulo une fonction à renommer), mais ça fait longtemps que je n’ai plus de base LDAP contre lequel le tester !

      • [^] # Re: C'est vrai :)

        Posté par  . Évalué à 2.

        Oui, ldapvi est toujours utilisable (présent dans Debian), c'est mon outil favori pour éditer des entrées, je m'en sers presque tous les jours ;).

    • [^] # Re: C'est vrai :)

      Posté par  . Évalué à 4. Dernière modification le 28 août 2022 à 12:36.

      LDAP, c'est un peu comme SNMP, c'est vieux, les syntaxes ASN.1 sont horribles, la doc est nulle, c'est pas souple…

      On peut reprocher beaucoup de choses à ASN.1, mais :
      - c'est du déclaratif
      - beaucoup de langages savent le parser. Il y a même des parsers en ligne
      - la spécification est suffisamment précise, et moins ambigüe qu'une spécification en yaml ou toml. Je peux peut-être me tromper mais seul le xml avec une DTD ou un schéma xml pourrait être une alternative fiable. Mais dans ce cas, il ne suffirait pas d'apprendre uniquement XML, mais la spécification du langage également (un peu comme le SVG pour le vectoriel). Mais en cherchant un peu, je suis tombé sur cet article : https://www.cs.kent.ac.uk/pubs/2004/2102/content.pdf

      Tout ça pour dire qu'il ne faut pas tout mélanger : le protocole, la spécification, l'implémentation et le stockage. Le truc c'est que j'ai l'iumpression qu'aujourd'hui ça n'intéresse plus grand monde de travailler sur ce genre de techno dans le libre, et que c'est surtout ça qui fait qu'Openldap ou ses alternatives sont toujours vieillottes.

      • [^] # Re: C'est vrai :)

        Posté par  . Évalué à 1.

        Je vois un peu ASN.1 comme la notation BNF pour décrire les langages de programmation.

      • [^] # Re: C'est vrai :)

        Posté par  . Évalué à 1.

        • c'est du déclaratif

        C'est à dire ? Pour un format de description quelle est la différence entre déclaratif et pas déclaratif ?

        • la spécification est suffisamment précise, et moins ambigüe qu'une spécification en yaml ou toml. Je peux peut-être me tromper mais seul le xml avec une DTD ou un schéma xml pourrait être une alternative fiable. Mais dans ce cas, il ne suffirait pas d'apprendre uniquement XML, mais la spécification du langage également (un peu comme le SVG pour le vectoriel).

        Je ne connais pas particulièrement ASN.1, mais les spécifications pour son usage dans LDAP font parti de la spec ASN.1 ? C'est pareil pour son usage dans X509 ? Ça veut dire que tous les cas d'usages d'ASN.1 ont était défini a sa création et qu'il ne peut pas être utilisé ailleurs ?

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: C'est vrai :)

      Posté par  . Évalué à 2. Dernière modification le 28 août 2022 à 13:04.

      J'ai oublié d'insister sur ce point :

      c'est pas souple

      Je pense que c'est volontaire. Mettre trop de soulesse dans une spécification d'échange réseaux, c'est à mon avis se tirer une balle dans le pied, la porte ouverte à des ambigüités d'interprétation.

      • [^] # Re: C'est vrai :)

        Posté par  . Évalué à 1.

        De plus ça permet d'implémenter des interpreteurs ASN.1 légers, qui ne doivent pas gérer les différentes interprétations possibles qui pourraient être une conséquence d'une souplesse syntaxique trop large.

        Quelque part je me dis qu'ASN.1 est peut-être a voir comme le XML, ou comme le langage intermédiaire d'un compilateur : ce n'est pas parce que c'est du texte qu'il faut le générer manuellement : peut-être qu'un langage plus souple avec un ide adequat serait plus efficace ?

      • [^] # Re: C'est vrai :)

        Posté par  . Évalué à 2.

        Ah mais je suis complètement d'accord (je l'ai -mal- exprimé dans mon second paragraphe, merci d'insister dessus) ! Et c'est sans doute une des raisons de la pérennité de SNMP et de LDAP.

    • [^] # Re: C'est vrai :)

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 01 septembre 2022 à 08:53.

      Un peu comme les bases de données, […]

      Mais OpenLDAP est une base de données. Elle n'est pas compatible SQL, voilà tout.

      Mais… Le truc super, c'est que les classes de base sont bien définies et ont peu bougé depuis des années, idem pour les protocoles réseau, ce qui donne un niveau d'interopérabilité incroyable sur des systèmes hétérogènes, comparativement à d'autres mécanismes plus souples.

      Classes bien définies… mais pas forcément bien pratiques pour autant : on a par exemple des composants qui veulent du posixGroup/posixUser et d'autres du Group/inetOrgPerson, alors que les deux sont incompatibles. La solution est donc d'avoir les informations en doublon si tu veux vraiment tout baser sur LDAP.
      D'autre part, plein de logiciels acceptent LDAP… mais sans donner beaucoup de possibilité pour configurer. Si tu as un LDAP qui n'est pas accessible anonymement en lecture et que tu ne fais que de l'authentification sans mot de passe (avec Kerberos), c'est possible mais presque personne ne prévoit ce cas.

  • # Projet LDAP Tool Box

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Salut,

    pour apporter un point de vue un peu contradictoire, je viens témoigner que certaines personnes sur Internet savent faire du LDAP et travailler avec OpenLDAP, et contribuent même à des outils libres qui facilitent l'installation et l'utilisation des annuaires.

    Nous avons créé le projet LDAP Tool Box en espérant pouvoir être utile aux personnes voulant mettre en place un annuaire LDAP dans leur infrastructure.

    • [^] # Re: Projet LDAP Tool Box

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Content qu’on me donne tort sur ce point là :)

      La connaissance libre : https://zestedesavoir.com

    • [^] # Re: Projet LDAP Tool Box

      Posté par  . Évalué à 2.

      Cool! LDAP fait partie de ces trucs que j'ai envie de me déployer dans un petit labo maison (et a terme pour gérer mon LAN perso), vu que je ne suis pas sysadmin et du coup n'ai pas l'occasion de le manipuler.

      Pour info, je trouve le site un peu confusant: la page de téléchargement par exemple donne l'impression que l'on va télécharger openLDAP, et non des outils pour openLDAP.
      La présentation de la page d'accueil me donne l'impression que les 4 lignes en dessous de "COMPILATION OF TOOLS FOR LDAP ADMINISTRATORS" sont des liens, mais non.

      Enfin, merci en tout cas, je vais creuser ça.

      PS: si jamais quelqu'un a des liens pour apprendre LDAP par un débutant (débutant LDAP, hein, pas débutant debian ou en shell) ça m'intéresserait.
      J'ai déjà un peu joué avec, je me souviens notamment que l'un des outils pour l'intégrer dans PAM sur debian segfaultait, mais je n'ai pas été très loin.

  • # OpenDJ

    Posté par  (site web personnel) . Évalué à 3.

    Ici on utilise OpenDJ, il est relativement facile à déployer, il a une API oueb et une IHM d'administration.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

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