Trucs:SASL sous Debian

Contexte

J'ai voulu mettre en place un serveur postfix qui s'appuie sur un annuaire LDAP pour la gestion des utilisateurs et des domaines. Afin d'éviter de faire un "serveur ouvert", plusieurs solutions se présentaient à moi :

. Mettre les IP publiques des gens autorisés à envoyer des mails dans la configuration de postfix. Bof : tout le monde n'a pas d'IP fixe

. Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.

N'attendez pas de ce petit article une solution miracle, clé en main. C'est plutôt pour faire comprendre aux utilisateurs que si l'on lit bien les docs, on arrive souvent au résultat. Après, il y a toujours Internet.

Premier point : Vérification avec sasltestsuite

En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite. En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c) En cherchant sur internet, j'ai trouvé ce lien : [1]

On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test : const char *username = "rjs3"; const char *password = "1234";

Pour créer l'utilisateur, on lance la commande suivante : saslpasswd2 rjs3

Il faut ensuite mettre le mot de passe et le confirmer. Ok, on considère que la base est bonne. On teste à nouveau avec sasltestsuite Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner. Premier point gagné...

Vérification avec testsaslauthd

Ensuite, il faut que saslauthd fonctionne. Il existe l'outil testsaslauthd. Pour l'instant, on part sur le fait que saslauthd cherche dans une base sasldb. On verra plus tard pour le LDAP. On lance le test : testsaslauthd -u rjs3 -p 1234 0: NO "authentication failed" Pas bon. Dans le script /etc/init.d/saslauthd, on voit que l'on récupère des infos depuis le fichier de config /etc/default/saslauthd. Le ou les méchanismes d'authentification $MECHANISMS et des paramètres $PARAMS. un petit man saslauthd pour savoir comment ça marche. Le méchanisme dans notre cas (en tout cas pour le test) est sasldb. Les options (-O) dans ce cas sont mal définies. Le man nous répond que c'est probablement pas ce que l'on veux faire (qu'est ce qu'il en sait lui, hein ?) et nous dit d'utiliser auxprop à la place comme pwcheck_method. J'aime pas qu'on me dise ce que je dois faire donc, je vais tester pwcheck_method: sasldb. Je crée un fichier /etc/saslauthd.conf (lu dans le man dans la partie ldap) et je met dedans pwcheck_method: sasldb. Je modifie le fichier /etc/default/saslauthd comme ceci : MECHANISMS="sasldb" PARAMS="-O /etc/saslauthd.conf" Un restart de /etc/init.d/saslauthd et on refait le test testsaslauthd -u rjs3 -p 1234 0: OK "Success."

Pas mal, non ? Deuxième point gagné.