« Trucs:SASL sous Debian » : différence entre les versions
mAucun résumé des modifications |
Aucun résumé des modifications |
||
| (19 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 : | 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 27 : | Ligne 32 : | ||
Premier point gagné... | Premier point gagné... | ||
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. | == Vérification avec testsaslauthd == | ||
On lance le test : | |||
0: NO "authentication failed" | Ensuite, il faut que saslauthd fonctionne. Il existe l'outil testsaslauthd. | ||
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. | 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." | ||
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é. | ||
(c) Zebu 2007 | |||
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