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é...

Deuxième point : test 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é.

On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS="ldap". On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf. Que mettre dans le fichier de config ? man saslauthd, on cherche LDAP. Il nous renvoit sur le fichier de doc LDAP_SASLAUTHD. vi /usr/share/doc/sasl2-bin/LDAP_SASLAUTHD.gz Il nous donne un exemple basic :

ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/ ldap_bind_dn: cn=operator,ou=Profile,o=foo.com ldap_password: secret

Une fois adapté à mon besoin : ldap_servers: ldap://127.0.0.1/ ldap_bind_dn: cn=readeruser,dc=domain,dc=com ldap_password: readerpassword

En regardant plus bas les autres paramétres, voilà ce que donne mon fichier : ldap_servers: ldap://127.0.0.1/ ldap_bind_dn: cn=readeruser,dc=domain,dc=com

ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça) ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com) ldap_scope: sub (je cherche dans les sous entrées...) ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domaines mais aussi mes relais) ldap_version: 3 (parce que mon LDAP supporte la version 3)

On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste : testsaslauthd -u moi@domain.com -p mon_mot_de_passe 0: OK "Success."

Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.

Deuxième partie : test 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é.