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.
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é.
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 !
Posté par totof2000 .
É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.
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 ?
Posté par totof2000 .
É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.
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 ?
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.
Posté par flan (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.
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.
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.
# C'est vrai :)
Posté par cg . É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/rmdans l'annuaire :)[^] # Re: C'est vrai :)
Posté par SpaceFox (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 gouttegd . Évalué à 2.
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.
À 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 cg . É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 totof2000 . Évalué à 4. Dernière modification le 28 août 2022 à 12:36.
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 totof2000 . É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 barmic 🦦 . Évalué à 1.
C'est à dire ? Pour un format de description quelle est la différence entre déclaratif et pas déclaratif ?
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 totof2000 . Évalué à 2. Dernière modification le 28 août 2022 à 13:04.
J'ai oublié d'insister sur ce point :
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 totof2000 . É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 cg . É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 flan (site web personnel) . Évalué à 2. Dernière modification le 01 septembre 2022 à 08:53.
Mais OpenLDAP est une base de données. Elle n'est pas compatible SQL, voilà tout.
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 KPTN (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 SpaceFox (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 freem . É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 devnewton 🍺 (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.