Travailler avec LDAP en 2022

Merci de me faire découvrir que je n’ai jamais, mais alors vraiment jamais, envie d’utiliser ce truc. On dirait un amoncellement de dette technique et de mauvaises décisions sur des dizaines d’années

La documentation d’OpenLDAP semble très complète, mais est difficilement inutilisable : c’est plus un aide-mémoire à destination des personnes qui savent faire plutôt qu’une vraie documentation.

J’imagine que le mot juste était utilisable ?

Clairement. C’est dommage parce que le concept de base (les bases d’annuaires arborescentes – ou même de données arborescentes tout court, en fait) est très intéressant et très utile dans certains cas.

Mais oui, c’est un très vieux protocole, avec de très vieux outils, qui ne sont jamais trop sortis du petit monde de l’administration système, et avec trop peu de « marché » pour que ça vaille le cout de réécrire un outil et des protocoles propres pour ça (vu que Microsoft avec Azure AD prends la grande majorité du marché). Et aujourd’hui on en paie le prix.

Oui, et c’est corrigé (ça m’apprendra à reformuler mes phrases à moitié seulement).

On me signale que l’obtention des OID est en faite gratuite, mais qu’il y a des conditions. Le formulaire est là, la liste des OID déjà attribués est publique (dans le meilleur et le pire format qui soit : un gros fichier texte, assez moyennement RGPD vu qu’il est plein de noms et d’adresses email).

Donc ça ne suffit pas de LDAP lui-même, même les données externes associées sont dans un format pas possible ?

Oh, t’es méchant, il est spécifique (ça aurait pu être un bête CSV) mais trivial à lire et à parser.

J’admets que j’ai été un peu dur sur ce coup là c:

Cela dit, le fait d’ignorer totalement ce qui se fait par ailleurs (ici le format CSV) et de réinventer un truc, c’est un peu le quotidien quand tu touches à LDAP. Quelque part, c’est à la fois très cohérent et représentatif de l’état de l’écosystème.

Je vois mal comment le format CSV pourrait efficacement remplacer le LDIF.
ToML par-contre effectivement.

Tu ne parles pas d’authentification à un serveur LDAP. De manière à ne pas laisser un annuaire ouvert de manière publique. Tu n’as pas regardé de ce coté là, ou il n’y avait rien d’intéressant ?

Pour les OID, j’étais pas trop étonné. J’avais eu la « chance » de travailler avec dans le cadre du monitoring d’équipements via le protocole SNMP, typiquement des switchs et des routeurs (pour les metrics qui remontent dans Nagios ou autre). Chaque constructeur (Cisco, Juniper, etc.) expose un peu ses propres points de données, d’où l’utilisation des OID pour gérer tout ça malgré la diversité des équipements (et effectivement il me semble que chaque constructeur avait un certain préfixe).

Pour une application interne, j’ai du faire une authentification via ldap (uniquement valider le couple username/password). En C# sur un ADDS (Microsoft).

Tout fonctionnait bien, sauf que le login prenait plus d’une minute !

Et après un tas de recherche, c’était car l’accès « ssl » n’était pas activer (ou juste le port qui n’était pas ouvert, je ne sais plus). Et du coup ça devait timeout quelque part, mais aucun log ni rien pour l’indiquer…

La remarque ne porte pas sur LDIF mais sur le fichier de référence des OID.

Au vu des dates, LDIF aurait pu être inspiré de SQL, mais je suppose que l’influence de X.400 et de la partie DAP de X.500¹ en a décidé autrement.

Je n’ai pas compris la question.

Je n’ai pas compris la question.

Comment tu autorises un client à requêter l’annuaire ?
Tu ne parles pas de ça, c’est qu’il n’y a rien à dire ?

LDIF aurait pu être inspiré de SQL

Je vois toujours pas. Mais franchement, c’est pas grave.

Y’a pas grand-chose à en dire, c’est la partie qui fonctionne comme elle devrait sans trop poser de question.

Par défaut tu vas laisser tout le monde se bind (≃ s’identifier) sur l’annuaire, parce que c’est exactement le principe, mais les comptes normaux n’ont que le droit de voir (en lecture seule) les attributs qui leurs sont directement rattachés.

Et tu as des comptes d’administration pour faire tout le reste.

Eh bien, toute cette histoire de classes et d’attributs, ça ressemble quand même furieusement à des tables et des colonnes. Donc on aurait pu imaginer que les créateurs de LDAP, quand ils ont inventé les LDIF, s’inspirent du format SQL déjà connu à l’époque ; et de même quand ils ont inventé les formats de déclaration de classes et d’attributs, s’inspirent des formats de DDL des SGBD, eux aussi bien connus à l’époque.

Si l’on devait faire un système d’annuaire et d’authentification (et autorisation ?) aujourd’hui, y aurait-il une raison d’utiliser LDAP, hormis Active Directory ?

J’ai vu que certains fournisseurs SSO (Identity Provider (IdP) plutôt) essayaient bien d’assurer une compatibilité avec du LDAP, mais j’ai l’impression que c’est surtout prévu pour les clients qui ont déjà une infra avec Active Directory. Pour les autres, il semblerait qu’on se contente simplement de la base de données interne gérée par l’IdP (qui est sûrement pas implémentée avec un serveur LDAP mais plutôt une base de données orthodoxe).

Un des intérêts du protocole LDAP, c’est le multi-master qui existe depuis longtemps. J’imagine que ça peut être un argument intéressant dans certains contextes.

Active Directory est payant (car Windows est payant) et non libre. OpenLDAP est gratuit.

C’est sans doute vrai¹, mais Active Directory a deux gigantesques avantages sur OpenLDAP (ou les autres implémentations libres) :

1. C’est facile de trouver des administrateurs système pour le gérer.
2. Si tu veux gérer ta flotte d’ordinateurs Windows, Active Directory est totalement intégré, alors qu’avec un LDAP open-source, je ne sais même pas si c’est possible et si ça l’est, ça demande sans doute infiniment plus de configuration.

C’est une question d’écosystème en fait : il faudrait un écosystème de gestion de parc d’enteprise aussi puissant et complet sous « Linux pour le desktop/laptop » que ce qui existe sous Windows. À ma connaissance, c’est très loin d’être le cas.

2. Si tu veux gérer ta flotte d’ordinateurs Windows, Active Directory est totalement intégré, alors qu’avec un LDAP open-source, je ne sais même pas si c’est possible et si ça l’est, ça demande sans doute infiniment plus de configuration.

Source: SpaceFox

Juste pour signaler que dans mon administration de taille moyenne, nous utilisons Samba v4 par rapport à l’Active Directory de Microsoft.
Nous gérons tout par scripts. Le plus difficile, c’est de les créer.

Merci beaucoup pour ce billet en tout cas, @SpaceFox ! Effectivement, quand on pense LDAP, on pense AD.

J’ai un jour vraiment essayé de me mettre à LDAP. Comprendre comment ça fonctionnait, comment l’utiliser. Je m’étais imposé une après-midi de travail pour essayer d’appréhender ça.

J’ai eu l’impression d’entrer dans un monde parallèle où rien n’avait de sens, et où tout était pile-poil mis de travers, où l’API tenait plus de la charade que de la documentation. Je n’y ai plus jamais remis les pieds.

Et pourtant ça marche, YunoHost l’utilise. Mais clairement, ça montre ses limites (dès qu’on atteint le millier d’utilisateurs différents sur une instance YunoHost, c’est LDAP qui goulotte). Il faudrait repenser entièrement le système, en garder la substance, l’extrader dans un cloître d’endpoints comprehensive, et en refaire toutes les fondations.

Mais merci pour ton billet, ça signifie que cette impression vicieuse de décalage constant avec l’outil ne venait pas de moi, ça me défait un peu le syndrome de l’imposteur.

Sur ce point précis, je serais curieux de savoir si c’est vraiment LDAP le goulot, ou le connecteur LDAP utilisé. Parce que comme je le disais, il y a un vrai gros problème de performances avec certains de ces connecteurs.

Par exemple mes LDAP de test font plusieurs milliers d’utilisateurs, et ça se charge et se requête presque instantanément. Que ça soit en « natif » ou via l’application. La charge via l’application mettait plusieurs minutes avant qu’on change de connecteur, par contre.

Ce qu’il faut comprendre, c’est que SQL est pour adresser des schémas de tables en relation. Ici, il s’agit de schémas plus ou moins arborescents (les poupées gigognes, le plan comptable, la classification des espèces biologique, etc.)
Ceci dit, il y a des implémentations qui utilisent sous le capot un SGBDR, et sans surprise on n’y retrouve pas toutes les fonctionnalités possibles permises par la norme.
On peut utiliser un SGBDOG générique (OpenLDAP en utilise juste un spécialisé qui lui est propre), mais aucune d’entre elles ne parle SQL qui n’est absolument pas adapté !

Faut arrêter de croire que le truc a été pensé en cinq seconde comme ce billet. C’est d’ailleurs marrant de vouloir que ça ressemble à du SQL et en même temps reprocher à OpenLDAP de proposer le même type de découpage dans la partie sur les commandes…

Ça va dépendre de votre implémentation, mais avec OpenLDAP, il y a toute une batterie de commandes différentes selon ce que vous voulez faire :

• ldapsearch → select
• ldapadd → insert
• ldapmodify → update

Je ne dis pas que le truc a été pensé en cinq secondes, hein.

D’autre part, c’est assez malhonnête de tronquer la citation pour lui faire dire ce que tu veux, parce qu’elle continue par :

leur syntaxe est assez absconse, et les différentes options ont tendance à se cumuler pour faire des effets supplémentaires quand utilisées ensemble.

D’une part, tu compares des commandes (à lancer dans ton terminal) avec des directives (qui font partie d’un langage, le SQL). Même s’il y a des similitudes, l’approche n’est pas la même (et en particulier, il faut apprendre la syntaxe des commandes et celle des LDIF). Et surtout, la mutiplicité des commandes n’est pas le problème principal, mais ce qui est cité ensuite.

Il y a des distros, comme SME, qui font cela. C’est aussi ce genre d’intégration que propose aux entreprises des solutions Red Hat et Novel. Ça marche très bien.

Expérience similaire ici, avec un groupe assez conséquent et sur plusieurs sites à l’international : une grosse forêt faite de Samba… et des clients bureautique Windows.

À noter aussi que j’ai déjà eu à corriger des soucis de l’AD W depuis les outils en console Linux là où les GUI mmc laissaient les admins en rade.

Faut arrêter de croire que le truc a été pensé en cinq seconde comme ce billet.

Je ne dis pas que le truc a été pensé en cinq secondes, hein.

Façon de parler, hein. Certes, même en mettant des esprits brillants ensemble ne signifie pas qu’on obtient en sortie la somme de leurs QI Mais je voulais souligner que, contrairement à l’impression que laisse ce billet, il y a eu un réel travail avec un certain nombre de contraintes héritées de X500 lui-même pensé par un commité de grands acteurs qui connaissaient et utilisaient diverses bases de données SQL et non SQL. En particulier, il est prévu un schéma d’adressage qui facilite la vie si on veut un accès web (au moins pour les requêtes) là avec SQL on doit réinventer le REST. C’est aussi et surtout un protocole client-serveur qui permet à n’importe quel client LDAP de pouvoir dialoguer avec n’importe quel serveur LDAP : côté bases de données ce n’est pas du tout la même chanson…

[…]

D’autre part, c’est assez malhonnête de tronquer la citation pour lui faire dire ce que tu veux, parce qu’elle continue par :

leur syntaxe est assez absconse, et les différentes options ont tendance à se cumuler pour faire des effets supplémentaires quand utilisées ensemble.

Justement, j’ai beau retourner dans tous les sens, je ne trouve pas ce que la syntaxe a d’abscons ni le problème avec les options qui ajoutent des effets supplémentaires. Il se trouve qu’on a la même chose en SQL où on il y a des termes optionnels qui peuvent s’ajouter pour produire des effets supplémentaires. Et je ne vois pas en quoi mettre en regard les commandes d’un côté avec les ordre de l’autre côté fait dire le contraire de ton écrit, mais bon.

D’une part, tu compares des commandes (à lancer dans ton terminal) avec des directives (qui font partie d’un langage, le SQL). Même s’il y a des similitudes, l’approche n’est pas la même (et en particulier, il faut apprendre la syntaxe des commandes et celle des LDIF). Et surtout, la mutiplicité des commandes n’est pas le problème principal, mais ce qui est cité ensuite.

Pour avoir écrit des commandes sqlsel/sqladd/sqldelete/sqlchange/etc., je peux t’assure qu’on abouti au même résultat : on fait peu de chose, ou on a des options qui permettent d’adresser plus de cas. certains éditeurs de SGBDR proposent aussi des commandes pour faire des opérations qu’on pourrait faire en lançant un client dans lequel on taperait les directives équivalentes ; c’est juste pas pratique (i.e. scriptable tout ça.) Je t’assure que tu peux utiliser les commandes ldap* sans faire de LDIF Mais OpenLDAP a prévu que ces mêmes commandes puissent traiter des fichiers de ce format : c’est utile pour passer plusieurs ordres, c’est la même logique/similitude qui fait que les clients SQL permettent de charger des fichiers de requêtes… Par contre, il faut effectivement savoir lire le format LDIF qui est celui de sortie de ldapsearch, et il faut se tourner vers ldap-attributes-selector par exemple si tu veux directement du CSV (beurk) Si tu veux travailler dans un client et non via des commandes, je te conseillerai de regarder du côté de : ldapvi —avec le binding de l’éditeur vi— ou shelldap —avec plutôt l’analogie avec le shell : cat/read et ls pour lire, grep pour chercher, vi/edit pour modifier, touch/create pour ajouter, etc.— ou ldapclient —qui est un client GUI et une fenêtre pour utiliser le binding SQL comme tu souhaites— et probablement d’autres.

Ben, dès que je suis rétabli, je sais donc le tuto qu’il me reste à pondre.

Je ne vois pas le rapport : tu attaques ta base de données (au sens large) directement en REST, sans aucune couche de contrôle au milieu ? Personnellement, je ne fais pas ça.

Ça, c’est un vrai avantage LDAP, il est vrai.

Je crois qu’en fait tu mets en exergue une différence fondamentale dans nos approches du truc, ce qui explique ton incompréhension face à mon billet.

Pour moi, la notion de « commandes scriptables » n’est en aucun cas un argument. Parce que je déteste les scripts shell. Ces machins n’ont pratiquement aucun avantage : c’est très vite illisible, c’est presque impossible à tester et à débugger, c’est pourri de comportements spécifiques¹, c’est pas spécialement portable (voire pas du tout si Windows est dans la boucle), tu dois vérifier à la main que chaque exécutable existe ou être prêts à gérer des erreurs horribles³, il y a des tonnes de pièges², le risque de laisser ton système dans un état instable est immense… Pour moi tout script qui dépasse les 10 lignes, contrôles inclus, devrait être écrit dans un vrai langage de programmation.

C’est d’autant plus vrai maintenant avec les techniques de déploiement modernes, qui nécessitent de moins en moins d’interventions directes sur le serveur.

La conséquence, c’est que je n’ai aucun intérêt à avoir des commandes multiples, qu’elles soient « scriptables » ou non. Par exemple, ça ne me viendrait jamais à l’idée d’avoir des commandes sqlsel/sqladd/sqldelete/sqlchange. Je préfère de loin une commande unique sql qui mange tous les fichiers .sql que lui donne : je n’ai qu’une syntaxe à apprendre, et aucun risque d’incohérence entre les différentes commandes. Accessoirement ça me permet de faire du transactionnel (quoique avec LDAP…).

Ce qui m’intéresse, c’est donc des bonnes bibliothèques d’intégration avec des langages de programmation, et une interface qui n’oublie pas qu’on a maintenant un peu mieux qu’un écran en 80 x 25 caractères et un clavier 60 touches.

PS : j’ai fait du bash (j’ai même programmé un jeu de dames « graphique » en réseau local avec, pendant mes études). Mais chaque jour que j’ai passé à maintenir des scripts m’a convaincu un peu plus que ce système était fait pour des petits outil one-shot de dix, quinze ligne grand max. En aucun cas pour des programmes complexes de plusieurs centaines de lignes comme on en trouve trop souvent.