8
Postfix mit SMTP-Auth gegen saslauthd und PAM unter Debian ohne chroot
PAM-Stack für smtpd greift nicht.
Hallo,
ich habe es nun endlich geschafft, meinen Postfix unter Debian aus dem chroot zu holen und er authentifiziert ordentlich gegen saslauthd und damit gegen PAM.
Kurze Info vorweg: Der Cyrus-IMAPd authentifiziert auf dieselbe Art, und macht dabei im Gegensatz zum Postfix genau, was er soll.
Wie gesagt, die Authntifikation klappt grundlegend, daher vermute ich, dass sowohl der Postfix als auch der Saslauthd richtig konfiguriert sind. Daher spare ich mir die Konfigurationsdateien erst einmal.
Da ich mir nicht sicher war, welchen Dienstnamen des saslauthd im beschriebenen Fall verwendet, habe ich PAM-Stacks in /etc/pam.d für die Dienste saslauthd, smtp und smtpd angelegt. Allerdings scheint das Ganze immer wieder auf login hinauszulaufen, denn für die Beschränkungen in den drei Stacks interessiert sich der saslauthd nicht.
Daher zwei mögliche Fragen:
1. Welchen Dienstnamen benutzt der saslauthd in dem Fall?
2. Falls einer der drei oben genannten Dienstnamen stimmt (was laut einiger Tutorials der Fall ist), was könnte da noch falsch laufen?
-nik
ich habe es nun endlich geschafft, meinen Postfix unter Debian aus dem chroot zu holen und er authentifiziert ordentlich gegen saslauthd und damit gegen PAM.
Kurze Info vorweg: Der Cyrus-IMAPd authentifiziert auf dieselbe Art, und macht dabei im Gegensatz zum Postfix genau, was er soll.
Wie gesagt, die Authntifikation klappt grundlegend, daher vermute ich, dass sowohl der Postfix als auch der Saslauthd richtig konfiguriert sind. Daher spare ich mir die Konfigurationsdateien erst einmal.
Da ich mir nicht sicher war, welchen Dienstnamen des saslauthd im beschriebenen Fall verwendet, habe ich PAM-Stacks in /etc/pam.d für die Dienste saslauthd, smtp und smtpd angelegt. Allerdings scheint das Ganze immer wieder auf login hinauszulaufen, denn für die Beschränkungen in den drei Stacks interessiert sich der saslauthd nicht.
Daher zwei mögliche Fragen:
1. Welchen Dienstnamen benutzt der saslauthd in dem Fall?
2. Falls einer der drei oben genannten Dienstnamen stimmt (was laut einiger Tutorials der Fall ist), was könnte da noch falsch laufen?
-nik
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 71422
Url: https://administrator.de/contentid/71422
Printed on: April 19, 2024 at 20:04 o'clock
8 Comments
Latest comment
Da ich mir nicht sicher war, welchen
Dienstnamen des saslauthd im beschriebenen
Fall verwendet, habe ich PAM-Stacks in
/etc/pam.d für die Dienste saslauthd,
smtp und smtpd angelegt. Allerdings scheint
das Ganze immer wieder auf login
hinauszulaufen, denn für die
Beschränkungen in den drei Stacks
interessiert sich der saslauthd nicht.
Dienstnamen des saslauthd im beschriebenen
Fall verwendet, habe ich PAM-Stacks in
/etc/pam.d für die Dienste saslauthd,
smtp und smtpd angelegt. Allerdings scheint
das Ganze immer wieder auf login
hinauszulaufen, denn für die
Beschränkungen in den drei Stacks
interessiert sich der saslauthd nicht.
Daher zwei mögliche Fragen:
1. Welchen Dienstnamen benutzt der saslauthd
in dem Fall?
1. Welchen Dienstnamen benutzt der saslauthd
in dem Fall?
hatte lange zeit ganz ähnliche probleme mit postfix / sasl / pam und co.
soweit ich das inzw. herausfinden konnte meldet sich saslauthd bei PAM unter dem servicenamen "smtp" an. d.h. PAM sucht daraufhin unter /etc/pam.d nach einer datei "smtp" und liest die zu verwendenden PAM Module. zur Authentifizierung ist nur das auth modul notwendig. bei mir unter debian sieht das z.b. so aus:
hostname:~# cat /etc/pam.d/smtp
@include common-auth
hostname:~#
das es diese datei ist kannst du auch selbst testen. lösche mal all deine smtp, smtpd, saslauth oder was du da alles angelegt hast und versuche dann mal per SMTP eine email über deinen postfix server abzusetzen (achtung! localnet regel vorher rausnehmen
sonst klappts sowieso immer. musst also dafür sorgen das ohne authentifizierung kein smtp relaying möglich ist).das ergebniss war bei mir >> authentifizierung fehlgeschlagen! allerdings ohne gescheide fehlermeldungen zu liefern die mir sagen was wo das problem ist.
dann lege die datei /etc/pam.d/smtp mit dem inhalt oben an und versuche da gleiche nochmal. btw: ein neustart der dienste war bei mir nicht notwendig.
siehe da...die smtp authentifizierung funktioniert wieder.
2. Falls einer der drei oben genannten
Dienstnamen stimmt (was laut einiger
Tutorials der Fall ist), was könnte da
noch falsch laufen?
Dienstnamen stimmt (was laut einiger
Tutorials der Fall ist), was könnte da
noch falsch laufen?
Was läuft denn noch falsch ?
soweit ich das überblicken kann funktioniert das prinzip so: (von unten nach oben)
[userdatenbank /etc/passwd] <=== PAM <==== SASLAUTHD <==== POSTFIX SMTPD etc
/etc/pam.d/smtp >>> -------------------^^
hostname:~# cat /etc/pam.d/smtp
@include common-auth
@include common-auth
Bei mir ist da halt noch definiert, dass nur eine bestimmte Systemgruppe darf. Aber das greift, wie ich schon schrieb, leider nicht.
das es diese datei ist kannst du auch selbst
testen. lösche mal all deine smtp,
smtpd, saslauth oder was du da alles angelegt
hast und versuche dann mal per SMTP eine
email über deinen postfix server
abzusetzen
testen. lösche mal all deine smtp,
smtpd, saslauth oder was du da alles angelegt
hast und versuche dann mal per SMTP eine
email über deinen postfix server
abzusetzen
Nein, das hätte keinen Effekt. Ich hab's auch gerade getestet, und wie erwartet klappt die Authentifizierung immer noch. PAM fällt bei fehlendem Stack immer auf die common-* Stacks zurück.
Was läuft denn noch falsch ?
Tja, die Authentifikation fällt halt IMMER auf common-auth zurück. Die Direktiven im Stack smtp werden nicht abgearbeitet.
Grüße,
Nik
> Was läuft denn noch falsch ?
Tja, die Authentifikation fällt halt
IMMER auf common-auth zurück. Die
Direktiven im Stack smtp werden nicht
abgearbeitet.
Grüße,
Nik
Tja, die Authentifikation fällt halt
IMMER auf common-auth zurück. Die
Direktiven im Stack smtp werden nicht
abgearbeitet.
Grüße,
Nik
hmm.. also dem IMMER möchte ich widersprechen. wenn du die Datei /etc/pam.d/other umbenennst is vorbei mit fallback. spätestens dann muss es fehlschlagen.
was hast du denn in deiner /etc/pam.d/smtp stehen ?
was hast du denn in deiner /etc/pam.d/smtp
stehen ?
stehen ?
@include common-auth
@include common-account
auth required pam_succeed_if.so debug user ingroup nnmailers
@include common-auth
@include common-account
auth required pam_succeed_if.so debug user
ingroup nnmailers
@include common-account
auth required pam_succeed_if.so debug user
ingroup nnmailers
Auszug aus der Seite http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-overview.ht ...
"
The Linux-PAM library (in the center) consults the contents of the PAM configuration file and loads the modules that are appropriate for application-X. These modules fall into one of four management groups (lower-center) and are stacked in the order they appear in the configuration file.
"
Könnte also die Reihenfolge etwas damit zu tun haben ? Schonmal versucht deine Zeile ganz nach oben zu verschieben ?
Habe ich gerade, bringt nichts.
Aber wie ich schon in meinem ursprünglichen Beitrag schrieb, sieht die Config für Cyrus genau so aus, und es funktioniert einwandfrei.
-nik
Aber wie ich schon in meinem ursprünglichen Beitrag schrieb, sieht die Config für Cyrus genau so aus, und es funktioniert einwandfrei.
-nik
Grundsätzliche Frage...
schlägt dein SMTP PAM Modul (/etc/pam.d/smtp ) grundsätzlich fehl oder lässt es mehr zu als du willst ?
Hast du das schonmal folgendes versucht?
1. benenne /etc/pam.d/other um nach DISABLED.other
2. benenne /etc/pam.d/smtp um nach DISABLED.smtp
3. funktioniert die smtp authentifizierung noch immer ? sollte nicht
4. setze dafür folgendes in die Datei /etc/pam.d/smtp ein:
"
auth requisite pam_succeed_if.so debug user ingroup nnmailers
auth required pam_unix.so nullok_secure
"
dies sollte alle OTHER und common-auth etc fallbacks umgehen.
also meinem verständniss nach sollte smtp auth jetzt nur noch leuten der gruppe nnmailers möglich sein.
schlägt dein SMTP PAM Modul (/etc/pam.d/smtp ) grundsätzlich fehl oder lässt es mehr zu als du willst ?
Hast du das schonmal folgendes versucht?
1. benenne /etc/pam.d/other um nach DISABLED.other
2. benenne /etc/pam.d/smtp um nach DISABLED.smtp
3. funktioniert die smtp authentifizierung noch immer ? sollte nicht
4. setze dafür folgendes in die Datei /etc/pam.d/smtp ein:
"
auth requisite pam_succeed_if.so debug user ingroup nnmailers
auth required pam_unix.so nullok_secure
"
dies sollte alle OTHER und common-auth etc fallbacks umgehen.
also meinem verständniss nach sollte smtp auth jetzt nur noch leuten der gruppe nnmailers möglich sein.
Werde ich versuchen.
Aber nochmal: GENAU dieser Stack funktioniert mit Cyrus einwandfrei!
-nik
Aber nochmal: GENAU dieser Stack funktioniert mit Cyrus einwandfrei!
-nik
