https://lea-linux.org/docs/api.php?action=feedcontributions&feedformat=atom&user=Zebu 2026-04-22T08:25:35Z Contributions MediaWiki 1.40.1 https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14649 2007-06-06T12:18:15Z

<p>Zebu : Vérification avec testsaslauthd</p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> &lt;code&gt;<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> &lt;/code&gt;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante :<br /> &lt;code&gt;<br /> saslpasswd2 rjs3<br /> &lt;/code&gt;<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> == Vérification avec testsaslauthd ==<br /> <br /> Ensuite, il faut que saslauthd fonctionne. Il existe l'outil testsaslauthd.<br /> 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 &quot;authentication failed&quot; 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=&quot;sasldb&quot; PARAMS=&quot;-O /etc/saslauthd.conf&quot; Un restart de /etc/init.d/saslauthd et on refait le test testsaslauthd -u rjs3 -p 1234 0: OK &quot;Success.&quot; <br /> <br /> Pas mal, non ? Deuxième point gagné.</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14648 2007-06-06T12:16:08Z

<p>Zebu : </p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> &lt;code&gt;<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> &lt;/code&gt;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante :<br /> &lt;code&gt;<br /> saslpasswd2 rjs3<br /> &lt;/code&gt;<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14614 2007-05-22T08:55:16Z

<p>Zebu : </p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> &lt;code&gt;<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> &lt;/code&gt;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante :<br /> &lt;code&gt;<br /> saslpasswd2 rjs3<br /> &lt;/code&gt;<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> == Deuxième point : test avec testsaslauthd ==<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> == Troisème point : test avec authentification sur le LDAP ==<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domaines mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> == Conclusion ==<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14602 2007-05-18T15:24:10Z

<p>Zebu : </p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante : ''saslpasswd2 rjs3''<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> == Deuxième point : test avec testsaslauthd ==<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> == Troisème point : test avec authentification sur le LDAP ==<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domaines mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> == Conclusion ==<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14601 2007-05-18T15:22:20Z

<p>Zebu : </p> <hr /> <div>{{Modèle:En Construction}} <br /> == Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante : ''saslpasswd2 rjs3''<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> == Deuxième point : test avec testsaslauthd ==<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> == Troisème point : test avec authentification sur le LDAP ==<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domaines mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> == Conclusion ==<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tardd.</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14579 2007-05-17T11:31:39Z

<p>Zebu : </p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante : ''saslpasswd2 rjs3''<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> == Deuxième point : test avec testsaslauthd ==<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> == Troisème point : test avec authentification sur le LDAP ==<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domaines mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> == Conclusion ==<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14578 2007-05-17T11:30:37Z

<p>Zebu : Deuxième point : Vérification avec testsaslauthd</p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante : ''saslpasswd2 rjs3''<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> == Deuxième point : test avec testsaslauthd ==<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> == Troisème point : test avec authentification sur le LDAP ==<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domaines mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> == Conclusion ==<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.<br /> <br /> == Deuxième point : Vérification avec testsaslauthd ==</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14565 2007-05-16T19:33:04Z

<p>Zebu : </p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante : ''saslpasswd2 rjs3''<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> == Deuxième point : test avec testsaslauthd ==<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> == Troisème point : test avec authentification sur le LDAP ==<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domaines mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> == Conclusion ==<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14564 2007-05-16T19:32:12Z

<p>Zebu : Deuxième point : test avec testsaslauthd</p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante : ''saslpasswd2 rjs3''<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> == Deuxième point : test avec testsaslauthd ==<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> == Troisème point : test avec authentification sur le LDAP ==<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domaines mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> == Conclusion ==<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.<br /> <br /> == Deuxième point : test avec testsaslauthd ==<br /> <br /> 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 &quot;authentication failed&quot; 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=&quot;sasldb&quot; PARAMS=&quot;-O /etc/saslauthd.conf&quot; Un restart de /etc/init.d/saslauthd et on refait le test testsaslauthd -u rjs3 -p 1234 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14563 2007-05-16T19:28:22Z

<p>Zebu : </p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante : ''saslpasswd2 rjs3''<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> == Deuxième point : test avec testsaslauthd ==<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> == Troisème point : test avec authentification sur le LDAP ==<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domaines mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> == Conclusion ==<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14562 2007-05-16T19:26:33Z

<p>Zebu : </p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante : ''saslpasswd2 rjs3''<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> == Deuxième point : test avec testsaslauthd ==<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> == Troisème point : test avec authentification sur le LDAP ==<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domaines mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14561 2007-05-16T19:25:01Z

<p>Zebu : Deuxième partie : test avec testsaslauthd</p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante : ''saslpasswd2 rjs3''<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> == Deuxième point : test avec testsaslauthd ==<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domaines mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.<br /> <br /> == Deuxième partie : test avec testsaslauthd ==<br /> <br /> 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 &quot;authentication failed&quot; 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=&quot;sasldb&quot; PARAMS=&quot;-O /etc/saslauthd.conf&quot; Un restart de /etc/init.d/saslauthd et on refait le test testsaslauthd -u rjs3 -p 1234 0: OK &quot;Success.&quot; <br /> <br /> Pas mal, non ? Deuxième point gagné.</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14560 2007-05-16T19:22:16Z

<p>Zebu : /* Premier point : Vérification avec sasltestsuite */</p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante : ''saslpasswd2 rjs3''<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> == Deuxième point : test avec testsaslauthd ==<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domaines mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14559 2007-05-16T19:17:45Z

<p>Zebu : /* Premier point : Vérification avec sasltestsuite */</p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> const char *username = &quot;rjs3&quot;;<br /> const char *password = &quot;1234&quot;;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante : ''saslpasswd2 rjs3''<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=reader,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domains mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.</div>

Zebu https://lea-linux.org/docs/index.php?title=Trucs:SASL_sous_Debian&diff=14558 2007-05-16T19:16:33Z

<p>Zebu : </p> <hr /> <div>== Contexte ==<br /> 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 &quot;serveur ouvert&quot;, plusieurs solutions se présentaient à moi :<br /> <br /> . 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<br /> <br /> . Demander une authentification à l'utilisateur si il essaye d'envoyer un message à l'extérieur. C'est là où l'on va retrouver SASL.<br /> <br /> 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.<br /> <br /> == Premier point : Vérification avec sasltestsuite ==<br /> <br /> En premier, j'ai voulu tester avec un des outils fournis avec sasl : sasltestsuite.<br /> En le lançant, erreur. Il n'arrive pas à se connecter à la base /etc/sasldb. Il renvoie sur le code source (testsuite.c)<br /> En cherchant sur internet, j'ai trouvé ce lien : <br /> [http://www.opensource.apple.com/darwinsource/10.3.9/passwordserver_sasl-58.2/cyrus_sasl/utils/testsuite.c]<br /> <br /> On retrouve dans le code, le login et le mot de passe qui sont utilisés pour le test :<br /> <br /> const char *username = &quot;rjs3&quot;;<br /> <br /> const char *password = &quot;1234&quot;;<br /> <br /> Pour créer l'utilisateur, on lance la commande suivante : ''saslpasswd2 rjs3''<br /> <br /> 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<br /> Cool, il effectue un bon paquet de test et nous dit que tout à l'air de fonctionner.<br /> Premier point gagné...<br /> <br /> 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.<br /> On lance le test : testsaslauthd -u rjs3 -p 1234<br /> 0: NO &quot;authentication failed&quot;<br /> 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.<br /> Le méchanisme dans notre cas (en tout cas pour le test) est sasldb.<br /> 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 :<br /> MECHANISMS=&quot;sasldb&quot;<br /> PARAMS=&quot;-O /etc/saslauthd.conf&quot;<br /> Un restart de /etc/init.d/saslauthd et on refait le test<br /> testsaslauthd -u rjs3 -p 1234<br /> 0: OK &quot;Success.&quot;<br /> <br /> Pas mal, non ? Deuxième point gagné.<br /> <br /> On passe au LDAP. On l'a vu avant, il faut modifier /etc/default/saslauthd avec MECHANISMS=&quot;ldap&quot;. On laisse le lien vers le fichier de paramètres /etc/saslauthd.conf.<br /> 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<br /> Il nous donne un exemple basic :<br /> <br /> ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/<br /> ldap_bind_dn: cn=operator,ou=Profile,o=foo.com<br /> ldap_password: secret<br /> <br /> Une fois adapté à mon besoin :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=readeruser,dc=domain,dc=com<br /> ldap_password: readerpassword<br /> <br /> En regardant plus bas les autres paramétres, voilà ce que donne mon fichier :<br /> ldap_servers: ldap://127.0.0.1/<br /> ldap_bind_dn: cn=reader,dc=domain,dc=com<br /> <br /> ldap_bind_pw: readerpassword (parce que c'est plus joli ecrit comme ça)<br /> ldap_filter: mail=%u (parce que mes utilisateurs apparaissent dans le LDAP sous la forme mail=moi@domain.com)<br /> ldap_scope: sub (je cherche dans les sous entrées...)<br /> ldap_search_base: dc=domain,dc=com (... à partir de la racine pour pouvoir trouver mes domains mais aussi mes relais)<br /> ldap_version: 3 (parce que mon LDAP supporte la version 3)<br /> <br /> On sauvegarde le fichier de paramètres, on restart /etc/init.d/saslauthd et on teste :<br /> testsaslauthd -u moi@domain.com -p mon_mot_de_passe<br /> 0: OK &quot;Success.&quot;<br /> <br /> Et un, et deux et trois... Bon saslauthd marche avec le LDAP. La suite pour Postfix et le TLS plus tard.</div>

Zebu https://lea-linux.org/docs/index.php?title=Proposition_d%27article&diff=14557 2007-05-16T18:56:28Z

<p>Zebu : /* Rubrique : Le réseau */</p> <hr /> <div>= Proposition d'article =<br /> Indiquer ici les articles qui manquent et que vous vous proposez de créer, puis créez les ! Si vous avez besoin de mettre des images dans votre article, n'hésitez pas à demander à Léa les [[Lea_Linux:Groupe_Editeur|droit d'éditeurs]]. '''Ne mettez pas''' des articles que vous désireriez voir écrits par quelqu'un d'autre que vous ! <br /> <br /> &lt;cadre type=alert&gt;'''Note :''' pour proposer un nouveau truc ou une nouvelle astuce, utiliser [[Trucs:Proposition_d'un_truc|cette page]].&lt;/cadre&gt;<br /> <br /> Il suffit d'insérer dans la section qui correspond à votre article, quelque chose du genre : <br /> * exemple : &lt;nowiki&gt;[[Nom de l'article]]&lt;/nowiki&gt;<br /> qui donnera : <br /> * exemple : [[Nom de l'article]] (SVP ne créez pas l'article '''Nom de l'article''').<br /> <br /> &lt;cadre type=alert&gt;'''Publication :''' Léa étant un wiki, c'est à vous de modifier la page principale de la rubrique dans laquelle vous voulez voir votre article publié, lorsque vous jugez que celui-ci est suffissament complet. Nous pouvons également ajouter votre article sur la page principale de Léa, pour ce faire, contactez-nous à admin &lt;chez&gt; lea-linux.org (en remplaçant &lt;chez&gt; par @). Si nous jugeons cet article de qualité, il sera publié.&lt;/cadre&gt;<br /> <br /> == Rubrique : Installation ==<br /> * [[UBUNTU et eagle-usb]] [[Utilisateur: mujma|Marc UJMA]]<br /> * [[Guide d'installation Linux SuSE 10.0 pas à pas]] leibowitz 29 janvier 2006<br /> * [[Guide d'installation et de configuration de Fluxbox,Conky, Idesk, Fbpager]] pingadaroça 31/01/06<br /> * [[L'erreur est humaine, ou bienvenue dans le monde de l'informatique libre]] (à caser dans philo et histoire je pense, ou dans découvrir Linux... bref on verra ça après) --[[Utilisateur:Linux.tar.gz|Linux.tar.gz]] 7 sep 2006 à 17:01 (CEST)<br /> * [[Installation et (surtout) configuration post-installation de Slackware 11.0]]<br /> * [[Configuration messagerie sur Debian]]<br /> *: [[Utilisateur:Fred (phorum)|Fred (phorum)]] &gt; Vas-y ... sauf que le nom est discutable (trop long : [[Configuration de la messagerie/Debian]] me parait plus adapté)<br /> <br /> *[[MANDRIVA 2007 - installation d'un système complet]] Zorglub 18/12/2006<br /> * [[KAELLA et ecran noir au demarrage taper knoppix xmodule=fbdev]]<br /> *[[Installation serveur LAMP uniquement en mode texte]]<br /> <br /> == Rubrique : X Window ==<br /> <br /> == Rubrique : Logiciels ==<br /> <br /> * [[Java et linux]]<br /> <br /> * [[Netbeans|Environnements de développement Java]]<br /> <br /> * [[J2EE|La version java entreprise edition]]<br /> <br /> * [[GlassFish|La version Open Source du Serveur d'application d'entreprise de SUN]]<br /> <br /> == Rubrique : Matériel ==<br /> * [[Le X10 et Linux]]<br /> * [[Installation d'une ATI Radeon X1600 sur Mandriva]]<br /> * [[Clavier Logitech G15]]<br /> * [[Souris Logitech MediaPlay]]<br /> <br /> === Publiés ===<br /> <br /> * [[Hardware-hard_plus-matos_bis]]<br /> * [[AC775|Carte PCMCIA GPRS/EDGE Sierra Wireless AC775]]<br /> <br /> == Rubrique : Le réseau ==<br /> * [[Streaming mp3 avec Icecast2 et ices]]. --[[Utilisateur:CoKe|CoKe]] 4 avr 2006 à 16:04 (CEST)<br /> * [[Debian GNU/Linux et IPv6]]. [[Utilisateur: Thomas Carlu|Thomas Carlu]] 25 oct 2005 à 1:15 (CEST)<br /> * [[Sécurité des réseaux WIFI]]. --[[Utilisateur:Maston28|Maston28]] 13 nov 2005 à 16:30 (CET)<br /> * [[Configurer le wifi avec une livebox, freebox etc...]] par Samiche, avril 2006<br /> * [[Nagios]] par [[Utilisateur:Jiel|Jiel]] 4 avr 2007 à 15:10 (CEST)<br /> *[[SASL sous Debian]] par [[Utilisateur:Zebu|Zebu]] 16 mai 2007 à 20:55 (CET)<br /> <br /> === Publiés ===<br /> * [[Tunnels ethernet avec openssh]]. --[[Utilisateur:Misc|Misc]] 12 fév 2006 à 13:30 (CET)<br /> * [[Créer un point d'accès sécurisé avec hostAPd]] --[[Utilisateur:Glandos|Glandos]] 26 avr 2006 à 23:16 (CEST)<br /> *[[postfix-courier-mysql-quota-spamassassin-amavis|Serveur de mail multi-domaines postfix - mysql (quota, antivirus, spamassasin) sous Debian]] --[[Utilisateur:Space2d|Space2d]] 29 nov 2006 à 12:25 (CET)<br /> <br /> == Rubrique : Administrer ==<br /> * [[Arrêter Windows et son routeur Linux]], [[Utilisateur:Vivecom|Vivecom]] 26 nov 2005 à 16:40 (CET)<br /> * [[S'identifier par une clé USB]], [[Utilisateur:thomas debay]] 28 fév 2006<br /> * [[Les sauvegardes]], [[Utilisateur:oudoubah|oudoubah]] 05 sep 2006<br /> * [[Utilisation de webmin administration a distance]] --[[Utilisateur:Pascalfares|Pascalfares]] 10 jan 2007 à 00:42 (CET)<br /> <br /> === Publiés ===<br /> * [[Gestion des ACL]] (ou [[ACL]] pour le titre). [[Utilisateur:Vincent Ramos|Vincent Ramos]] 24 oct 2005 à 23:00 (CEST)<br /> ::Fait. Bien qu'améliorable, l'article me semble complet. [[Utilisateur:Vincent Ramos|Vincent Ramos]] 26 oct 2005 à 00:22 (CEST) ;<br /> * [[Attributs étendus]] (''chattr'' sur ext2 et ext3, outils efs2progs) [[Utilisateur:Vincent Ramos|Vincent Ramos]] 26 oct 2005 à 17:40 (CEST)<br /> <br /> == Rubrique : Noyau et modules ==<br /> <br /> * [[RT2500]] : compilation et installation du modules RT2500 Pour les cartes wifi , essai avec la carte '''PCI PC54G2''' , Auteur: Laplaine Freddy, Alias mr_pupu[corbeille]<br /> <br /> === Publiés ===<br /> * [[HOWTO Dkms]] : Utiliser dkms pour gérer ses drivers dynamiquement et facilement<br /> <br /> == Rubrique : Développer ==<br /> <br /> * [[Ocaml]] : une présentation du langage ocaml<br /> *[[FreePascal]] : Un langage familier pour nombre de développeurs [[Utilisateur: mujma|Marc UJMA]]<br /> *[[Trucs:Obtenir le code HTML d'un glyphe]] [[Utilisateur:Nicola|Nicola]] 2 jan 2006 à 19:10 (CET)<br /> <br /> == Rubrique : Léavancé ==<br /> <br /> * [[Virtualisation avec Xen]]<br /> * [[OpenMosix]] axé Slackware mais applicable à d'autres distributions<br /> * [[Compilation Distribuée]] ou comment accélérer ses compilations</div>

Zebu