Obsidian a écrit 5299 commentaires

L'histoire ne dit pas combien de kernels elle a recompilé, d'ailleurs, pendant tout ce temps (p'têt même celui du Hurd).

C'est DEVENU Katsuni, visiblement ...

Ce n'est pas celui de l'auteur du journal, en tout cas ...

C'est clair&nsbp;! Elle avait les moyens d'acheter 1000 fois sa propre libération. :-)

Énorme, ce journal. Qu'en pense Kastumi, au fait ?

http://www.z0pe.org/howto/securite/pki-openssl/creation-d-un(...)

Lire les deux pages (« avec l'usine »).

Et donc ? Tes conclusions ?

Après six ans d'abstinence (enfin, j'imagine), je pense le contraire. M'enfin, moi je dis ça mais je ne dis rien ...

Je suis assez d'accord, mais si on a au moins le prix réel de la licence OEM de Windows affichée en clair, ce sera déjà beaucoup.

Si on voit bien « PC : 600 €, dont Windows Vista OEM 120 € », au moins ça fera réfléchir les gens, et les informera sur la réalité des choses.

#TLS_CACERT /etc/openldap/cacerts/ldap.crt
#TLS_CERT /etc/openldap/cacerts/ldap.crt
#TLS_KEY /etc/openldap/cacerts/ldap.key

S'il y a des # devant tes lignes, c'est qu'elles sont commentées.

Sinon, essaie d'appeler ldapsearch avec -Z au lieu de -ZZ (qui force la validation).

Par contre, je maintiens que le mieux que tu aies à faire est de refaire des certificats au propre.

Essaie sudo startx ou sudo init 5.

À noter également que ldapsearch lit sa config dans /etc/openldap/ldap.conf

Il y existe TLS_REQCERT pour contourner ce contrôle, mais le mieux reste encore de générer un certificat valide.

C'est ce que je pensais (et j'ai buté dessus aussi) : le certificat envoyé par serveur n'est pas reconnu. Avec quoi, l'as-tu généré ? As-tu bien fourni la clé avec ?

Olalah ! GROSSE ERREUR de ma part ! Le port 177, c'est le Xdmcp ! Rien à voir, donc (c'était mon problème précédent en fait).

Bon, alors en gros :

- Commenter host et garder uri dans /etc/ldap.conf ;
- Utiliser ldap:// et pas ldaps:// dans cet URI (et ne pas oublier le deux-points, non plus) ;
- Ne pas préciser le numéro de port dans l'URI ;
- Passer en mode TLS par le port par défaut (389, donc) avec ssl start_tls;
- tlscacertfile pour préciser le nom de fichier de la CA qui a signé le certificat de ton serveur, pour que le client puisse l'authentifier. Peut-être pas nécessaire si tls_checkpeer no.

Ensuite, côté serveur, donc dans slapd.conf

- il te faut au moins un certificat côté serveur, fût-il autosigné (mais moi j'ai pris le temps de créer une CA puis de créer un certificat propre à LDAP).

TLSCertificateFile /etc/pki/tls/certs/ldap.pem
TLSCertificateKeyFile /etc/pki/tls/private/ldap.key

sans oublier de redémarrer :

# /etc/init.d/ldap restart

Ça devrait suffire à faire démarrer le TLS.
Puis :

ldapsearch -x -H ldap://srvtest3.test.org -ZZ '*'

Pour voir si tu peux établir une connexion en TLS avec ton serveur.

Après, c'est la configuration de PAM et NSS.
Bon courage.

Si tu lances vi dans un script, celui-ci va rester en attente jusqu'à ce que tu refermes vi de toi-même puis passer à la suite.

Si tu veux simuler une entrée clavier, tu peux utiliser <<END mon texte END sous bash.

Si tu veux simplement faire un script qui écrit quelque chose dans un fichier, tu utilises echo ou cat.

Que cherches-tu à faire, exactement ?

venant étayé ce chiffre, de coups cachés.

Ouch ! C'est vrai qu'on s'en prend plein la tronche, là ...

Ok, après en avoir sué, l'authentification utilisateur via LDAP-TLS fonctionne chez moi, tcpdump à l'appui pour comparer les flux.

Il faut d'abord configurer proprement /etc/ldap.conf et /etc/openldap/ldap.conf, puis veiller a ce que les clients aient accès au certificat de l'autorité racine qui à signé celui du serveur (si pas auto-signé), faire attention au format (.PEM,.CRT,...) et surtout se méfier de host et uri, mutuellement exclusifs. Enfin, il faut se souvenir que le TLS écoute le port 177 par défaut (le SSL Netscape utilisait le 636).

Le piège, c'est que si on spécifie uri ldaps://ldap.serveur.org, le mot-clé est associé au port 636, qui n'est pas ouvert si on fonctionne en start_tls. Moralité, les modules nss_ldap et pam_ldap ne peuvent pas se connecter, alors qu'un ldapsearch -h ldap.serveur.org -ZZ, lui, y arrive très bien parce qu'on ne précise que le nom d'hôte sans le protocole, et que l'on négocie ensuite le TLS manuellement, avec l'option idoine.

Beaucoup de temps perdu, mais ça servira bien.

Depuis le serveur, ce n'est peut-être pas une bonne idée, puisqu'il peut ouvrir des sockets UNIX plutôt qu'UDP (ils appellent çà le LDAP over IPC :-).

Essaie d'ajouter l'option -Z à ta commande, pour forcer le TLS, puis -ZZ pour l'obliger à s'arrêter en cas d'échec de l'authentification. Cette étape fonctionne désormais chez moi, mais nsswitch, lui, continue d'échouer sur un timeout.

Au fait, ça fait quoi si tu commentes host et que dans uri, tu remplaces ldap:// par ldaps:// ?

J'utilise une Fedora 9, donc ce doit être relativement proche. Il faut distinguer d'un côté les vrais fichiers de conf' et de l'autre les GNOMEries qui permettent de les manipuler. Par exemple : Système->Administration->Authentification.

Oui.

Quelle distribution utilises-tu au fait ?

mais je me trompe peut-être

Oui, enfin en partie.

La man page stipule que l'une des grandes particuliarités du passage de SSL à TLS est l'utilisation (par défaut) du même port de communication.

À vue de nez, j'ai l'impression que NSS gère déjà le LDAP alors que ton serveur n'est pas encore lancé, et ça affecte toutes tes applications ... y compris le serveur LDAP lui-même.

D'autre part, le TLS_CACERT en majuscule est une directive de /etc/openldap/ldap.conf et pas /etc/ldap.conf (une saloperie, ce truc). Ceci dit, on utilise les mêmes directives dans l'autre aussi, mais en minuscules. Je ne sais pas si le parser fait la distinction ou pas.

Enfin, essaie déjà de désactiver LDAP dans le NSS puis lancer une recherche avec ldapsearch -h tonserveurldap -LLL -x -ZZ dn pour voir si le TLS fonctionne bien du côté d'OpenLDAP et de ses outils.

Moi, j'en suis à cette étape aussi. OpenLDAP ok, NSS échoue.

Pas grave, moi aussi, je devrais être couché !

Bananuit à tous.

Non ? 16 fois le budget pub de Windows 95 ? Nan, pas possible.

Ça me rappelle la fois où un pirate s'est mis à scanner mon port 22, aussi. À cette époque, j'avais sous WindowMaker une dockapp très réactive qui reproduisait l'activité de ma carte réseau. La p'tite LED verte qui se mettait à clignoter frénétiquement n'était pas discrète :-) Un petit coup de tcpdump pour lever les doutes, ensuite ...

Pas eu besoin de gueuler beaucoup. Un p'tit ssh en retour vers sa machine a fait tout de suite comprendre au gars que je l'avais repéré et que je savais ce qu'il faisait.

Maintenant, il y a une Freebox en routeur devant, c'est moins drôle :-)