sasl Miscellaneous failure bei AUTH GSSAPI

[ralfk]

Hallo,
habe auf Suse 10.0 zu Testzwecken einen Email-Server installiert.
Postfix 2.3 + Cyrus SASL +Courier Imap +MySQL +Kerberos +Pop-Before-Smtp

Fast alles funktioniert wie es soll, sofern ich es testen konnte, ein Problem habe ich aber seit nunmehr ein paar Tagen dem ich nicht auf die Schliche komme. Hab auch schon wie ein Bescheu..... gegoogelt, yahooed, etc, habe aber bisher keine Antwort gefunden.
Um die Anmeldung am Server über GSSAPI zu testen habe ich versucht über KMail eine Email zu senden. Das Anmeldeverfahren startet ganz normal, KMail sendet den Challenge an den Server, der Server dekodiert den Challenge, und dann beekomme ich folgende Fehlermeldung:

Jul 3 14:24:15 raid postfix/smtpd[25026]: warning: SASL
authentication failure: GSSAPI Error: Miscellaneous failure (No such
file or directory)
Jul 3 14:24:15 raid postfix/smtpd[25026]: warning:
unknown[192.168.13.89]: SASL GSSAPI authentication failed: generic failure
Jul 3 14:24:15 raid postfix/smtpd[25026]: > unknown[192.168.13.89]:
535 5.7.0 Error: authentication failed: generic failure

Egal wie ich die Log-Level setze, egal wo ich schaue, ich krieg nicht raus welche Datei der Server nicht finden kann.

Die Authentifizierung über testsaslauthd funktioniert ohne Probleme. Kerberos und die Erstellung der Tickets funktionieren auch.

Um den Beitrag hier kurz zu halten habe ich die Ausgabe von saslfinger, den relevanten Teil des Maillogs, etc in die angehängte PDF-Datei gepackt.

Wäre für Eure Hilfe sehr dankbar.

Beste Grüße

Ralf

 

[Huschi]

Hast Du Postfix in einer Chroot laufen?
Dann könnte es sein, daß innerhalb des chroot kein tmp-Verzeichnis existiert oder nicht nutzbar ist...?

Das wäre auch eine Erklärung, daß die manuellen Tests einwandfrei funktionieren, da sie ja nicht in der chroot laufen.

huschi.

 

[ralfk]

Hallo Huschi,
danke für Deine Antwort. Das ist es leider nicht.
Nein, läuft nicht chrooted oder jailed. Wie ich schon sagte ist die Installation lokal für Testzwecke, mit der chrooted-Geschichte habe ich mich am Anfang rumprügeln müssen, ständig fehlten von irgendwelchen Komponenten Sockets, Verzeichnisse, etc. Das ständige ln -s, und Herausfinden wo's denn nun weh tut oder wie auch immer ist mir nach ner Weile tierisch auf die Kelle gegangen, da war das Umschalten der logische Schritt.
Hat mich bisher einige Tage gekostet, am Anfang hatte ich ehrlich gesagt keine Ahnung worauf ich mich da eingelassen habe, habe bei der Geschichte aber Einiges gelernt, daher sehe ich den Zeitverlust eher locker.

Nur dieses Problem ist hartnäckiger als ich dachte. Und wie gesagt ist es so daß weder Cyrus noch Postfix noch das OS mir sagen wollen wo es weh tut, und dabei hatte ich mein System sogar schon so eingestellt das es jede Mausbewegung mitprotokollierte, übertrieben gesagt.

Ich programmiere gerade ein Email-Modul, Pop und Smtp. Brauche den Server um alles zu testen.

Wenn es denn hilft die Quelle des Übels zu finden hänge ich gerne meine ganzen Konfigurationsdateien als Zip hier hin.

Besten Dank

Ralf

 

[Huschi]

Nach dem ich mir jetzt doch mal das PDF angeschaut hab (da steht's ja auch drin, daß es nicht chrooted ist), ist mir folgendes aufgefallen:

Der "saslfinger -s" geht nicht bis zum Ende sondern bricht ab.
(Wenn er ganz durchläuft kommt ein "-- end of saslfinger output --".)

Er bricht sogar im Entscheidenden Moment ab. Es sollte mit einem "telnet localhost smtp" weiter gehen. Z.B. so:

-- mechanisms on localhost --
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN

Teste den Telnet mal selber. (Evtl folgende Anleitung beachten: ESMTP-Dialog (SMTP-Auth))

Desweiteren irritiert mich Deine /usr/lib/sasl2/smtpd.conf:

saslauthd_path: /var/run/sasl2/mux/mux

Diese Dopplung von mux kenne ich nur aus einer (mittelmässig konfigurierten) chroot-Umgebung. Ist /var/run/sasl2/mux/mux/ wirklich ein eigenes Verzeichnis oder bereits der mux selber?

Das sind die Punkte, die mir aufgefallen sind. Ob sie Dich der Lösung näher bringen, kann ich aber auf die Schnelle nicht sagen.

/edit:
Was ist mit "Ticket cache: FILE:/tmp/krb5cc_1000"?
Hast Du mal nachgesehen, welche Berechtigungen hier vorherschen oder gebraucht werden?

huschi.

 

[ralfk]

Hallo Huschi,
Das mit dem sasl_authpath ist zwar korrekt, hatte mal was im Internet gefunden, war aber nur zum testen, zum Zeitpunkt des saslfingers war es auch noch aktiv. Danach habe ich es aber wieder deaktiviert.

Mit dem Ticket cache gibt es keine Probleme sofern ich das erkennen kann.
krb5cc_1000:
Eigentümer ist der Account des Client, Gruppe users rw-------
krbcc_0:
Eigentümer/Gruppe root rw-------

Wenn ich das richtig gelesen habe sollte das auch so sein. Habe nichts desto trotz die Rechte gerade so geändert daß Alle lesen und schreiben können, und kriege beim Senden genau die selbe Fehlermeldung.

Habs auch grade über Telnet probiert, genau das Gleiche. DIGEST, CRAM, LOGIN, PLAIN funktionieren auch über telnet ohne Probleme.

Eins was ich nicht wußte ist das saslfinger eine end of output Meldung bringt. Hatte nur einfach den Befehl eingegeben und den Output in die Datei gepackt.

Aber Du hast Recht wenn dem so ist, der saslfinger bricht wirklich an der entscheidenden Stelle ab, nämlich wenn er die mechlist holen soll.

Hab mir grad mal das saslfinger-Skript angeschaut. Er bricht deswegen ab weil er versucht die Verbindung mit localhost aufzunehmen und nicht mit meinem mailer-host. Hab localhost gegen den mailer ausgetauscht. Ergebnis:

-- mechanisms on mailer.gauchonet.ath.cx --
250-AUTH GSSAPI CRAM-MD5 DIGEST-MD5 LOGIN PLAIN
250-AUTH=GSSAPI CRAM-MD5 DIGEST-MD5 LOGIN PLAIN


-- end of saslfinger output --

Bin gerade dabei den saslfinger -c zu untersuchen, da der auch zwischendrin abbricht.

Melde mich dann wieder.

Grüße

Ralf

 

[ralfk]

Hallo nochmals,
Clientseitig hat saslfinger abgebrochen weil ich ja die password_map über MySQL abfrage. Habe aber einfach mal eine auth_map über hash angelegt, da hat saslfinger seine Arbeit zu Ende geführt. Er hat wie auf der Serverseite die mechlist angezeigt.

Hab dann mal wieder versucht eine Mail über GSSAPI zu verschicken, und kriegte prompt wieder haargenau den selben Fehler.

Beste Grüße

Ralf

 

[ralfk]

GSSAPI Problem gelöst

Hallo Huschi,
wollte nur sagen daß ich das Problem gelöst habe. Nachdem ich die letzten Tage weiter programmiert habe hatte ich Heute eine Eingebung. Kam wirklich so aus heiterem Himmel.
Hab mich gefragt welche Dateien Kerberos in einer Standardinstallation verwendet, wo diese sich befinden und welche Dateien erzeugt werden dessen Ablageort frei gewählt werden kann. Dann habe ich mich gefragt welche Dateien von Postfix bzw. saslauthd benötigt werden könnten. Ich habe mich daran erinnert daß ich auf Grund eines Beitrags im Internet in der smtpd.conf den Speicherort des keytabs angegeben hatte, was aber nicht funktioniert hat.
Die Logik sagte mir daß es eigentlich nur diese Datei sein kann die sasl nicht findet, also habe ich die Datei kopiert und in die verschiedenen Konfigurationsverzeichnisse eingefügt. (/usr/lib/sasl2, /etc/postfix, /etc). Die Konfigurationsverzeichnisse deshalb weil bei Kerberos der Standardpfad /var/lib/kerberos/krb5kdc ist und dort die Konfigurationsdateien liegen, bis auf die krb5.conf.
Beim kopieren des keytabs hatte ich einen kleinen Fehler gemacht, hatte die falsche kopiert da ich zwei hatte. Eine kadm5.keytab (die Richtige) und krb5.keytab, die ich vor einigen Tagen aus welchem Grund auch immer angelegt hatte.

Am Ende hatte ich nun die krb5.keytab im /etc Verzeichnis.
Habe wie zuvor auch wieder versucht eine Email zu verschicken, und auf einmal stand dort eine andere Fehlermeldung => "Key version number for principal in key table is incorrect".

Da habe ich festgestellt daß saslauthd eine Datei "/etc/krb5.keytab" erwartet.
Hab dann die Datei wieder gelöscht und ein Symlink mit dem Namen zu meiner /var/lib/kerberos/krb5kdc/kadm5.keytab generiert und dann einen neuen Versuch gestartet eine Email zu verschicken.
Und ein Wunder war geschehen, die Mail verschwand aus KMail in meinen lokalen Email-Server. Ohhhhh, es geschehen immer noch Zeichen und Wunder.

Jetzt muß ich Kerberos nur noch beibringen die Daten nicht aus seiner eigenen Datenbank zu holen sondern aus der MySQL-Datenbank. Soweit ich das gelesen habe funktioniert das über pam_krb5 nsswitch.

Besten Dank nochmals für Deine Hilfe

Grüße und schönes WE

Ralf