J'ai donc plein d'URL super sympa mais éparpillées (le pire c'est celle que je m'envoies par courrier électronique pour m'en souvenir (et oui, l'email comme moyen de sauvegarde)).
Je me suis dit "ce serait sympa d'avoir tout ça dans un annuaire LDAP", les annuaires LDAP étant l'absolu en terme de cool-attitude :-)
J'ai donc réfléchi a une méthode pour le faire. Les objectifs étant simple :
- Indépendant, tant que possible, du langage de documentation (wikicreole, markdown, rest, ...)
- Simple, lecture sur stdin, écriture sur stdout
- La syntaxe ne demandant pas d'utiliser plus d'un doigt sur mon clavier Dvorak-US (j'utilise vi, pas emacs :-)
- La syntaxe demandant au plus 2 caractères en plus du nom de la norme
Je me suis donc penché sur les langages de script existant. Ces langages n'étant pas assez trollesque, j'ai décidé de le faire en C :-) (non, pas d'autres raisons, si j'avais fait en Perl, ça aurait été presque normal, en Python, c'est la mode donc c'est bon, avec sed ça aurait fait vieux barbu mais je me rase, par contre avec C, c'est certain que le choix est trollable à mort).
La syntaxe reste très simple, on met un = suivi du nom de la norme, si on est dans le texte un espace termine la balise, sinon on met un = en fin de balise (donc pas d'espace dans les noms de balise). Un exemple :
La =RFC1149 défini le MTU standard comme étant de 256 milligrammes. [...] La qualité de service est traitée dans la =RFC2549=.
Donc ce programme va prendre ce texte et remplacer ces deux normes (=RFC1149 et =RFC2549=) par quelques choses de plus agréable, défini par le fichier de configuration. Dans ce cas la chaîne de remplacement indiquée dans la configuration est "`$$documentidentifier$$ <$$documentlocation$$>`_", le motif de recherche LDAP est "(&(objectclass=*)(cn=$$))" et l'annuaire contient :
dn: cn=RFC1149,ou=documentation,dc=example,dc=org
objectclass: document
cn: RFC1149
documentidentifier: RFC 1149
documentlocation: http://www.rfc-editor.org/rfc/rfc1149.txt
dn: cn=RFC2549,ou=documentation,dc=example,dc=org
objectclass: document
cn: RFC2549
documentidentifier: RFC 2549
documentlocation: http://www.rfc-editor.org/rfc/rfc2549.txt
Le résultat, une fois traité par ce programme magique, est :
La `RFC 1149 <http://www.rfc-editor.org/rfc/rfc1149.txt>`_ défini le MTU standard comme étant de 256 milligrammes. [...] La qualité de service est traitée dans la `RFC 2549 <http://www.rfc-editor.org/rfc/rfc2549.txt>`_.
Magique !
Bon voilà pour finir, peut-être indiquer que ce programme, prénommé lref pour "Ldap Revient En Force", "Ldap REFerence" ou "Lannuaire pour les Références Enfantines et Faciles" ou encore "Le Rose ÉléFant" (comme vous voulez), est sous la seule vraie licence Libre, soit la WTFPL (pas comme la GPL ou la BSD X-clause(s) qui sont des licences tristement propriétaires et annoncées comme libre).
Je vais indiquer un lien pour éventuellement obtenir ce programme, il faut "svn co http://www.tchetch.net/svn/lref/tags/lref-0.1" (ou svn export). Il y a aussi un websvn.
Il y a aussi une page web.
Pour installer, il faut lire le "README", mais il y a même pas de Makefile, il y a pas de paquets Debian, ni de RPM, rien, c'est pas "Michu Ready" (d'ailleurs ça s'utilise en ligne de commande).
Pour terminer (encore une fois), cette solution n'est peut-être pas compatible avec les langages de pré-cités (wikicreole, markdown, rest, ...), c'est vaguement testé avec rest et visuellement admis de fonctionner avec markdown. Mais ça marche peut-être avec Tex ...
Le numéro de version est 0.1, ça veut rien dire, la prochaine version pourrait être la 100.99.87, je cherche encore une manière débile de versionner ce logiciel (si vous avez une idée).
# C'est LOURD!
Posté par Gabin . Évalué à -2.
Nan mais, vous êtes vraiment chiants à la fin...
Le troll n'a même plus de saveur, si tant est qu'il en eut une.
C'est relou de chez relou!
[^] # Re: C'est LOURD!
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 5.
+1
[^] # Re: C'est LOURD!
Posté par Frank-N-Furter . Évalué à 5.
Depending on the time of day, the French go either way.
[^] # Re: C'est LOURD!
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# Langage de tapette!
Posté par Maclag . Évalué à 2.
M'en vais te la recoder en assembleur ton appli, Et puis le serveur LDAP avec si j'ai une heure ou deux dans la foulée.
---------> [ ]
# Pour ou contre
Posté par Sébastien Koechlin . Évalué à 2.
J'aime bien LDAP dans le concept; par contre je trouve l'implémentation totalement désastreuse. La comparaison avec un projet comme Apache httpd est effroyable.
Niveau serveur, le choix se fait entre openldap et... des trucs hyperlourds en java qui demandent beaucoup de puissance ou des trucs palibres. Donc openldap.
Coté administration, la doc d'openldap est loin de la qualité de celle d'Apache. La configuration elle aussi n'est pas très limpide, peu d'exemples, beaucoup de renvois vers des pages de manuels (quel est l'intérêt d'éclater la documentation dans deux systèmes ?).
La configuration mélange passablement les directives relatives au serveur, aux annuaires et aux moteurs de stockage contribuant à beaucoup de confusion pour les nouveaux admins.
Coté exploitation, ce n'est pas beaucoup mieux. Les logs sont globalement inutilisables; les messages d'erreur rarement informatifs, et la supervision inexistante. La descente de privilèges pose encore des problèmes (par exemple sur la lecture des fichiers de certificats SSL).
Mais le gros gros soucis, ce sont les outils :
- La configuration d'une application pour utiliser LDAP en annuaire d'authentification est rarement une partie de plaisir, on trouve a chaque fois une dizaine de paramètres avec des noms et des traductions variables; la configuration revient a tester successivement de multiples configurations, jusqu'à ce que ça fonctionne. Pas forcément dans le mode que l'on souhaite. Aucun outil ou fichier ne semble capable de remonter les requêtes passées et les données ou les erreurs retournées.
- Les clients libres d'administration de l'annuaire sont très laborieux à utiliser. L'injection en ligne de commande passe encore lorsqu'on a un modèle, mais les interrogations sont déconseillés aux personnes dépressives. Les interfaces PHP ou Java permettent rarement de gérer facilement les utilisateurs et les groupes.
Bref, LDAP n'est pas prêt pour le desktop.
[^] # Re: Pour ou contre
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Un serveur d'annuaire LDAP demande quelques connaissances relativement pointues. Mais globalement il me semble que cela se tient très bien. La complexité de l'annuaire vient du fait que l'on y met les informations sur des personnes, des périphériques diverses, carnet d'adresses, comptes utilisateurs, groupes, DNS, ... Tout ce qui peut-être nécessaire pour l'entreprise.
La documentation est, à mon sens, très claire. Mais elle demande de connaître les bases, soit la série de documents UTI-T X.500. Chaque élément inter-agi dans un service d'annuaire et doit être vu comme un élément indépendant. Le stockage est le DIB, structuré en arbre, le DIT, accéder par le DUA à travers le DSA. Le DMD est un ensemble de DSA (1,n), ... Tous ces éléments se trouvent détaillés dans le document X.500. Il reste à lire les documents suivant pour le reste.
LDAP est une simplification de ces normes, mais totalise pas mal de RFC qu'il est nécessaire de lire.
Donc tu peux toujours appréhender LDAP par la pratique en bidoulliant et regardant les résultats, mais c'est, à mon sens, un système demandant une compréhension de la théorie de base : lire les RFC.
Une fois armé de ce bagage, la documentation d'openLDAP devient limpide, les logs claires et précis et les configurations simples.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pour ou contre
Posté par Sébastien Koechlin . Évalué à 3.
Je ne conteste pas l'intérêt de LDAP, les choses que l'on peut mettre dedans. Je trouve par contre que les outils dont on dispose ne sont pas à la hauteur.
Concernant les logs, a chaque fois que j'ai eu des soucis, le message n'avait pas grand rapport avec la cause du problème. Par exemple lorsque les certificats x509 ne sont lisibles que par root; openldap ne les lit pas avant d'abandonner les privilèges, puis il sort une belle erreur "main: TLS init def ctx failed: -64" plutôt que de dire qu'il ne peut pas lire le fichier.
[^] # Re: Pour ou contre
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Ensuite les outils, ils sont super, tu as phpldapadmin si tu veux une interface graphique, sinon tu as les commandes ldap* qui te permettent de tout faire. Pour les gros travaux tu fais tes fichiers ldif et départ pour voir gicler des entrées dans tous les sens. Tu as les outils slap* pour traiter avec les données quand le serveur est éteint.
Aprés tu as ldapvi pour voir ton annuaire comme un fichier ldif et l'éditer joyeusement. Il existe Gtruc ou Kmachin aussi, mais bon j'utilise pas trop ...
Je trouve plutôt mature les outils sauf ce qui sort de chez Mozilla (Thunderbird est une horreur à ce niveau) et OOo pire encore (et c'est régressif la qualité, dans 2 je pouvais approximativement me connecter, dans 3 plus rien). Je parlerais pas de Outlook et de Mac OS X, ça va gâcher mon humeur.
Et le support est bien présent dans les langages ... Non je trouve que les outils d'administration LDAP sont bons et bien présents. Et si tu veux du vrai clickodrome, tu as AD qui fonctionne bien.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pour ou contre
Posté par Frank-N-Furter . Évalué à 2.
Depending on the time of day, the French go either way.
[^] # Re: Pour ou contre
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
En réalité ils ont enfin changé le schéma et, miracle, "SUP top AUXILIARY". Mais ça doit pas faire longtemps ... Donc je retire ce que j'ai dis.
Sinon en terme applicatif, il y'a :
- samba qui supporte très bien LDAP
- des serveurs DNS, pam et nss
- il est possible de configurer thunderbird et firefox (adm.js)
- des tonnes d'applications Web (dokuwiki, webcalendar, mediawiki, phpbb, ...)
- httpd d'Apache
- authentification de Mac OS X
- exim (smtp)
- dovecot (imap4, pop3)
- asterisk (pbx)
- obélix (j'étais obligé)
- serveur jabber (je sais plus lequel j'avais testé, mais jabber.fsfe.org utilise certainement LDAP, l'interface Web pour gérer le compte étant basée sur phpldapadmin)
- mysql avait planifié l'authentification ldap (je sais pas où s'en est)
- Debian (debconf, j'ai pas testé (pas encore), mais livre "Debian, Administration et configuration avancées, Eyrolles")
- autofs (pour les automount NFS)
- il y'a un patch pour openssh (stocker les clés openssh dans LDAP au lieu de ~/.ssh)
- il est possible de faire interopérer openldap et Microsoft AD (j'ai pas d'AD pour tester, mais livre "LDAP, System Administration, O'Reilly")
- FTP (proftpd)
- GnuPG
- lref :-)
- CUPS (il semble)
- ...
Alors ça laisse quand même quelques applications ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pour ou contre
Posté par Sébastien Koechlin . Évalué à 1.
Et comme souvent c'est de l'authentification, les erreurs sont jetés, compliquant d'autant le diagnostique.
Les autres pierres d'achoppement que j'ai rencontré sont la gestion des groupes et la méthode d'authentification.
Si j'ai bien compris, l'authentification peut se faire selon deux méthodes:
- soit on essaye de se connecter à l'annuaire avec les informations fournies par l'utilisateur, si ça rate c'est (probablement) que le login ou le mot de passe sont faux.
- Autre méthode, se connecter avec un utilisateur dédié et par une opération un peu magique que je n'ai jamais bien identifié malgré mes lectures, on fait ensuite la validation (est-ce qu'on récupère le mdp chiffré de l'utilisateur ? Est-ce qu'on utilise une fonction que je n'ai pas vu ? Mystère).
Une fois faite l'authentification (le client est bien celui que l'on croit) il faut faire l'autorisation (le client a-t-il le droit ?) et là, c'est encore pire. Beaucoup d'applications s'imaginent qu'elles sont seules au monde (alors qu'on utilise généralement LDAP pour mutualiser les comptes) et partent du principe que si l'utilisateur est authentifié, c'est qu'il a le droit.
D'autre permettent de définir des groupes, mais ne laisse pas forcément beaucoup de latitude sur l'usage des groupes. Si j'ai bien compris mes bouquins, la notion de groupe est étrangère à LDAP, on se contente de regarder si un objet contient l'identifiant d'un autre objet. Comme il faut se taper le boulot à la main, c'est rarement récursif.
D'autres enfin permettent d'exprimer la requête qui va permettre d'autoriser l'utilisateur. Il faut être capable d'écrire une requête LDAP qui ne remonte un utilisateur que s'il est dans un groupe; j'ai jamais réussi, j'ignore toujours si c'est possible.
[^] # Re: Pour ou contre
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Une chose est certaine : des applications codées avec les pieds au niveau de l'authentification, il y'en a. Comme j'ai compris ton problème, c'est le cas des applications qui s'authentifient et gèrent ça un peu comme une base de donnée sql. En fait c'est faux car, comme tu l'as si bien remarqué, ça contourne les ACL du serveur LDAP (qui sont, à mon avis, très puissantes (par expression régulière, demander un niveau d'algo de chiffrement minimum (en plus du classique utilisateurs/groupe) avec diverses niveaux (tu peux donner l'accès à un attribut uniquement à l'authentification, mais pas à la lecture, la comparaison et la recherche)).
Malheureusement j'ai trop souvent vu des applications qui demandent un utilisateur dédié et vont comparer le mot de passe directement en assumant que l'annuaire stocke celui-ci dans un format X (genre SSHA ou SHA ou MD5) ou pire qui vont modifier le mot de passe en écrivant directement l'attribut userPassword au lieu d'utiliser l'opération étendue disponible pour ça (et qui permet à l'annuaire de gérer d'autres champs, très utile pour avoir les mots de passe unifié entre Unix et Windows (samba et pam gère très bien le changement de mot de passe avec exop))
Le problème de LDAP c'est que du côté applicatif, beaucoup de gens n'ont pas compris et utilisent ça comme une base MySQL (et tellement peu d'applications ont compris le referal qu'il faut faire faire au serveur le chaînage (alors que le client est nettement moins occupé et peut le faire (d'ailleurs je dois le faire pour lref)).
Donc oui la méthode 2 est la plus utilisée parce que c'est fait comme ça dans MySQL, mais maintenant je banni automatiquement ou corrige (si je peux) l'application. Quand je fait la remarque à un projet, on me dit que non https://linuxfr.org//comments/1107150.html#1107150
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pour ou contre
Posté par Sébastien Koechlin . Évalué à 1.
J'ai beau avoir lu "Les annuaires LDAP : Protocole, administration, méta-annuaires, API" et plusieurs HOWTO, et la gestion des authentifications reste floue. Et je n'ai trouvé nul part un "howto" qui explique comment un développeur doit implémenter ça dans son application.
J'ai listé les deux méthodes que j'ai rencontré, sans être capable de détailler le contenu, sans savoir quelle est la meilleur des deux. J'imagine donc les problèmes rencontrés par les développeurs qui veulent supporter LDAP.
Méthode bind:
1- Se connecter au serveur
2- Faire un bind(user, pass) pour la partie authentification
3- Et ensuite pour l'autorisation ? Lire les valeurs de l'attribut member du groupe et regarder si on est dedans ?
4- Se déconnecter
Méthode mysql:
1- Se connecter au serveur
2- Faire un bind avec l'utilisateur applicatif
3- Rechercher l'utilisateur
4- Si on l'a trouvé, lire les valeurs de l'attribut userpassword ?
5- Espérer que c'est un algo connu et vérifier en local si on obtient la même valeur ?
6- Pour les groupes, idem, lire les valeurs de l'attribut member du groupe concerné ?
7- Se déconnecter
Ces séquences sont probablement fausses, mais je ne trouve pas plus d'informations claires sur la méthode à suivre. Toute recherche sur Google de "LDAP authentification" remonte tous les cas particuliers de chaque application et tous les problèmes que les gens ont rencontré; mais pas ça.
C'est bien les referals, les opérations étendues, mais les usecase de base, dans les règles de l'art, sont difficiles à trouver.
[^] # Re: Pour ou contre
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
1. Se connecter
2. Faire le bind
3. Faire des requêtes
4. Se déconnecter.
Le serveur sait ce que tu as le droit d'accéder, toi pas. C'est pas l'application qui gère les autorisations, c'est l'annuaire. Toi tu veux l'objet cn=Paul,ou=Bass,o=Beatles, ben tu fais une lecture de l'objet. Tu sais pas s'il existe, tu cherches pour (&(objectclass=musicien)(cn=Paul)) et tu verras bien si tu as quelques chose.
Je vois pas ce que tu voudrais faire de plus ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pour ou contre
Posté par Sébastien Koechlin . Évalué à 1.
Et pour les groupes ?
[^] # Re: Pour ou contre
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
1) Windows ne peut pas s'authentifier sur le LDAP directement (si il peut, mais le plus simple c'est directement avec samba)
2) Samba a ces propres entrées qu'il doit pouvoir accéder
Les groupes, de nouveau c'est les ACLs qui gèrent l'accès (tiré d'un cas réel) :
access to dn.sub="ou=contacts,o=example"
by group.exact="cn=admin,ou=groups,o=example" peername.ip=127.0.0.1 write
by group.exact="cn=contact,ou=groups,o=example" peername.ip=127.0.0.1 write
by group.exact="cn=users,ou=groups,o=example" peername.ip=127.0.0.1 read
by group.exact="cn=admin,ou=groups,o=example" ssf=112 write
by group.exact="cn=contact,ou=groups,o=example" ssf=112 write
by group.exact="cn=users,ou=groups,o=example" ssf=112 read
by * none
Voilà ici j'ai trois groupes (admin, contact, users) chacun ayant leur niveau. Chaque membre du groupe peut accéder en local sans aucune autre limitation, sinon pour tous les autres accès le chiffrement de la communication doit au moins être du tripleDES (ssf=112).
Après tu peux faire des trucs encore plus fun avec les expressions régulières, par exemple j'ai fait un cas suivant :
"ou=contacts,o=example" -> annuaire d'entreprise, tout le monde peut lire et écrire (après il y a encore des attributs réservés au secrétariat (tu peux imposer des ACL par attribut)
"ou=username,ou=contacts,o=example" -> carnet d'adresse par utilisateur
Donc ACL :
access to dn.regex="(.+),ou=([^,]+),ou=contacts,o=example$"
by dn.exact,expand="uid=$2,ou=users,o=example" write
access to dn.regex="^ou=([^,]+),ou=contacts,o=example$" attrs=entry,children
by dn.exact,expand="uid=$1,ou=users,o=example" write
by dn.base="cn=xerox,ou=applications,o=example" none
by * break
Et là on voit qu'il y a un compte pour les machines xerox pour qu'elles accèdent au carnet d'adresse sans demander à l'utilisateur de s'authentifier.
Ensuite les groupes que je t'ai montré c'est pour les groupes contenant des "uniqueMember", mais tu peux faire ce que tu veux avec la syntaxe là :
access to ....
by set="[cn=Domain Admins,ou=groups,o=example]/memberUid & user/uid" write
Donc si l'attribut "uid" de l'utilisateur actuellement est dans un attribut "memberUid" de l'objet "cn=Domain Admins,ou=groups,o=example", droit en écriture !
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pour ou contre
Posté par Sébastien Koechlin . Évalué à 1.
# référence au RFC
Posté par maxime1986 . Évalué à 1.
[^] # Re: référence au RFC
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Et là, l'intérêt de ce programme c'est que je peux me faire des "bookmarks" de tout et n'importe quoi dans un annuaire LDAP et les partager aux gens s'ils veulent (d'où l'ajout de l'authentification anonyme sur le LDAP dans la version 0.2). Et les gens ils ont juste besoin de faire des "referal" vers mon annuaire pour avoir mon contenu en plus du leur. Alors quand j'aurais référencé la série X.500, c'est déjà ça de gagné.
Là je médite un schéma qui irait bien pour gérer plusieurs langues et après une petite interface web pour fédérer le tout et j'aurais créer le facebook des normes et à moi le fric, les gonzesses, la grosse voiture, les banquets, la une des journaux et tout :-)
... je trouve plus mes calmants ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.