« Trucs:SASL sous Debian » : différence entre les versions

De Lea Linux
Aller à la navigation Aller à la recherche
m (Deuxième partie : test avec testsaslauthd)
Aucun résumé des modifications
 
(16 versions intermédiaires par 4 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
[[Catégorie:Trucs]]
== Contexte ==
== 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 :
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 :
Ligne 16 : Ligne 18 :


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


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


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
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
Ligne 25 : Ligne 32 :
Premier point gagné...
Premier point gagné...


== Deuxième point : test avec testsaslauthd ==
== 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.
Ensuite, il faut que saslauthd fonctionne. Il existe l'outil testsaslauthd.
On lance le test : testsaslauthd -u rjs3 -p 1234
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."  
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é.
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.
(c) Zebu 2007
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é.

Dernière version du 29 décembre 2023 à 16:59


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

(c) Zebu 2007

Récupérée de « https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&oldid=45614 »