1
Zarafa smtp-auth via CRAM-MD5
Hallo zusammen,
nach tagelangen Kopfzerbrechen möchte ich mich nun an die Admin Kollegen wenden.
Mein Mailservers läuft auf Debian 7. Das Mailssystem ist, kann man sagen, Standard. Zarafa, Postfix auf Basis von MySQL und die diversen Filter.
Das System läuft auch jetzt schon Jahre stabil.
Nun benötige ich aber für smtp nicht nur die authentifizierungsmethode PLAIN-LOGIN sondern auch CRAM-MD5. Zur Authentifizierung für den Postfix kommt sasl (saslauthd) zum Einsatz.
Das funktioniert auch mit PLAIN-LOGIN, aber eben nicht mit CRAM-MD5.
Ich habe jetzt hier schon ein grundlegendes Verständnisproblem. Das liegt daran das sich das System bei Änderungen unlogisch verhält. Nach meinem Verständnis konfiguriere ich dies in der smtpd.conf. Allerdings funktioniert PLAIN-LOGIN auch ohne jegliche Einstellung in dieser Datei. Das kann ich mir ja noch erklären, in dem ich denke das sich Postfix dann mit den virtuellen maps begnügt, in denen die Abfrage der Datenbank konfiguriert ist. Aber warum macht dies dann Postfix nicht für CRAM-MD5? OK, weil es nicht konfiguriert ist. Aber warum funtioniert es mit PLAIN-LOGIN?
Ich würde es ja auch wieder wie unter der alten 6er Zarafa in der smtpd.conf konfigurieren. Aber auch das geht nicht weil die Datenbankabfrage so wie ich sie habe nicht mehr funktioniert bzw. kein Resultat bringt.
Datenbankabfrage:
sql_select: SELECT DISTINCT `objectid` FROM `objectproperty` WHERE objectid = (SELECT `objectid` FROM `objectproperty` WHERE `propname` = ‚loginname‘ AND `value` = ‚%u‘) AND `propname` = ‚password‘ AND `value` = CONCAT(SUBSTR(`value`, 1, 8), MD5(CONCAT(SUBSTR(`value`, 1, 8), ‚%p‘)))
Die Tabellen sind da... Das passt....
Aber es kommt dann der Fehler:
sql plugin create statement from userPassword xxxxxx xxxx
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin doing query SELECT DISTINCT `objectid` FROM `objectproperty` WHERE objectid = (SELECT `objectid` FROM `objectproperty` WHERE `propname` = ‚loginname‘ AND `value` = ‚xxxxxx‘) AND `propname` = ‚password‘ AND `value` = CONCAT(SUBSTR(`value`, 1, 8), MD5(CONCAT(SUBSTR(`value`, 1, 8), ‚userPassword‘)));
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin: no result found
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin create statement from cmusaslsecretCRAM-MD5 xxxxxx xxxx
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin doing query SELECT DISTINCT `objectid` FROM `objectproperty` WHERE objectid = (SELECT `objectid` FROM `objectproperty` WHERE `propname` = ‚loginname‘ AND `value` = ‚xxxxxx‘) AND `propname` = ‚password‘ AND `value` = CONCAT(SUBSTR(`value`, 1, 8), MD5(CONCAT(SUBSTR(`value`, 1, 8), ‚cmusaslsecretCRAM-MD5‘)));
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin: no result found
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: commit transaction
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin Parse the username xxxxxx
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin try and connect to a host
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin trying to open db ‚xxxxx‘ on host ‚127.0.0.1‘
Er löst den Anmeldenamen noch auf, das sieht man. Aber mit dem Passwort kommt er nicht klar.
Hat jemand von euch noch eine Idee wie ich CRAM-MD5 integriere? Wie habt ihr das gelöst?
LG. Sven
nach tagelangen Kopfzerbrechen möchte ich mich nun an die Admin Kollegen wenden.
Mein Mailservers läuft auf Debian 7. Das Mailssystem ist, kann man sagen, Standard. Zarafa, Postfix auf Basis von MySQL und die diversen Filter.
Das System läuft auch jetzt schon Jahre stabil.
Nun benötige ich aber für smtp nicht nur die authentifizierungsmethode PLAIN-LOGIN sondern auch CRAM-MD5. Zur Authentifizierung für den Postfix kommt sasl (saslauthd) zum Einsatz.
Das funktioniert auch mit PLAIN-LOGIN, aber eben nicht mit CRAM-MD5.
Ich habe jetzt hier schon ein grundlegendes Verständnisproblem. Das liegt daran das sich das System bei Änderungen unlogisch verhält. Nach meinem Verständnis konfiguriere ich dies in der smtpd.conf. Allerdings funktioniert PLAIN-LOGIN auch ohne jegliche Einstellung in dieser Datei. Das kann ich mir ja noch erklären, in dem ich denke das sich Postfix dann mit den virtuellen maps begnügt, in denen die Abfrage der Datenbank konfiguriert ist. Aber warum macht dies dann Postfix nicht für CRAM-MD5? OK, weil es nicht konfiguriert ist. Aber warum funtioniert es mit PLAIN-LOGIN?
Ich würde es ja auch wieder wie unter der alten 6er Zarafa in der smtpd.conf konfigurieren. Aber auch das geht nicht weil die Datenbankabfrage so wie ich sie habe nicht mehr funktioniert bzw. kein Resultat bringt.
Datenbankabfrage:
sql_select: SELECT DISTINCT `objectid` FROM `objectproperty` WHERE objectid = (SELECT `objectid` FROM `objectproperty` WHERE `propname` = ‚loginname‘ AND `value` = ‚%u‘) AND `propname` = ‚password‘ AND `value` = CONCAT(SUBSTR(`value`, 1, 8), MD5(CONCAT(SUBSTR(`value`, 1, 8), ‚%p‘)))
Die Tabellen sind da... Das passt....
Aber es kommt dann der Fehler:
sql plugin create statement from userPassword xxxxxx xxxx
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin doing query SELECT DISTINCT `objectid` FROM `objectproperty` WHERE objectid = (SELECT `objectid` FROM `objectproperty` WHERE `propname` = ‚loginname‘ AND `value` = ‚xxxxxx‘) AND `propname` = ‚password‘ AND `value` = CONCAT(SUBSTR(`value`, 1, 8), MD5(CONCAT(SUBSTR(`value`, 1, 8), ‚userPassword‘)));
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin: no result found
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin create statement from cmusaslsecretCRAM-MD5 xxxxxx xxxx
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin doing query SELECT DISTINCT `objectid` FROM `objectproperty` WHERE objectid = (SELECT `objectid` FROM `objectproperty` WHERE `propname` = ‚loginname‘ AND `value` = ‚xxxxxx‘) AND `propname` = ‚password‘ AND `value` = CONCAT(SUBSTR(`value`, 1, 8), MD5(CONCAT(SUBSTR(`value`, 1, 8), ‚cmusaslsecretCRAM-MD5‘)));
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin: no result found
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: commit transaction
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin Parse the username xxxxxx
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin try and connect to a host
Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin trying to open db ‚xxxxx‘ on host ‚127.0.0.1‘
Er löst den Anmeldenamen noch auf, das sieht man. Aber mit dem Passwort kommt er nicht klar.
Hat jemand von euch noch eine Idee wie ich CRAM-MD5 integriere? Wie habt ihr das gelöst?
LG. Sven
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 325546
Url: https://administrator.de/forum/zarafa-smtp-auth-via-cram-md5-325546.html
Ausgedruckt am: 24.02.2025 um 01:02 Uhr
1 Kommentar
Nach langer Recherche, die Antwort für das Problem auf "https://linux.robert-scheck.de/software/pam_mapi/" gefunden:
Zitat:
"Anwendungen wie die Kopano WebApp, die Kopano DeskApp, der Zarafa WebAccess, die Zarafa WebApp oder Microsoft Outlook (mit dem Zarafa Windows Client) verbinden sich über MAPI in SOAP zu Kopano Core (KC) bzw. zur Zarafa Collaboration Platform (ZCP) und wickeln auch darüber die Authentifizierung z.B. beim Versand von E-Mails ab. Alle Benutzer-Informationen dafür werden in einer MariaDB- oder MySQL-Datenbank gespeichert, wurde Kopano bzw. Zarafa mit dem Datenbank-Plugin konfiguriert. Kommt jedoch IMAP/POP3 über das Kopano- bzw. Zarafa-Gateway ins Spiel, so ist meist SMTP für ausgehende E-Mails involviert. Hierfür benötigt man üblicherweise SMTP-Authentifizierung (auch "SMTP-Auth"), um sogenannte offene Relays zu vermeiden, aber die Benutzer-Informationen in der MariaDB- oder MySQL-Datenbank sind für die gängigen SASL-Daemons nicht verwendbar.
Das Passwort wird zwar generell als MD5-Hash abgelegt, wird jedoch zusätzlich mehrmals mit einem Salt versehen und es werden jeweils erneut MD5-Hashes gebildet. Das spricht zwar für die Sicherheit, aber Cyrus SASL beispielsweise erwartet ein Klartext-Passwort in der Datenbank, wird das Plugin "SQL auxprop" verwendet. Die sogenannten "Frost-Patches" helfen hier ebenfalls leider nicht weiter - abgesehen davon, dass sie in führenden Linux-Distributionen, die auch im professionellen Umfeld verwendet werden, nicht enthalten sind. Und pam_mysql unterstützt zwar Passwörter als MD5- oder SHA1-Hash (abgesehen von Klartext-Passwörtern), doch keine Salts."
tscha, ok.... darum funktionierten alle meine Versuche nicht!
Die Lösung habe ich aber leider nicht ganz verstanden, bzw wie man dies dann konfiguriert. Unter Debian gibt es da kein Paket man muss dieses dann wohl selber kompilieren.:
"Genau diese Lücke füllt pam_mapi durch die Bereitstellung von MAPI-basierter Authentifizierung, die dann wiederum von einem SASL-Daemon für den SMTP-Dienst verwendet werden kann. Typischerweise wird Sendmail oder Postfix verwendet und "saslauthd" (aus Cyrus SASL) kümmert sich dann mittels pam_mapi um die Prüfung der Benutzer-Informationen aus dem SMTP-Dialog. Letztendlich baut pam_mapi eine Verbindung zum hinterlegten Kopano- bzw. Zarafa-Server auf und führt eine Anmeldung durch - das Ergebnis wird entsprechend zurückgeliefert woraufhin der SMTP-Dienst dann den Versand von E-Mails zulässt oder ablehnt. Lizenziert ist pam_mapi unter der 3-Klausel-BSD bzw. GNU General Public License (GPL), da es einen potentiellen Konflikt zwischen der GNU GPL und den Einschränkungen beim Copyright im BSD-Stil gibt."
Habt ihr noch Ideen?
Zitat:
"Anwendungen wie die Kopano WebApp, die Kopano DeskApp, der Zarafa WebAccess, die Zarafa WebApp oder Microsoft Outlook (mit dem Zarafa Windows Client) verbinden sich über MAPI in SOAP zu Kopano Core (KC) bzw. zur Zarafa Collaboration Platform (ZCP) und wickeln auch darüber die Authentifizierung z.B. beim Versand von E-Mails ab. Alle Benutzer-Informationen dafür werden in einer MariaDB- oder MySQL-Datenbank gespeichert, wurde Kopano bzw. Zarafa mit dem Datenbank-Plugin konfiguriert. Kommt jedoch IMAP/POP3 über das Kopano- bzw. Zarafa-Gateway ins Spiel, so ist meist SMTP für ausgehende E-Mails involviert. Hierfür benötigt man üblicherweise SMTP-Authentifizierung (auch "SMTP-Auth"), um sogenannte offene Relays zu vermeiden, aber die Benutzer-Informationen in der MariaDB- oder MySQL-Datenbank sind für die gängigen SASL-Daemons nicht verwendbar.
Das Passwort wird zwar generell als MD5-Hash abgelegt, wird jedoch zusätzlich mehrmals mit einem Salt versehen und es werden jeweils erneut MD5-Hashes gebildet. Das spricht zwar für die Sicherheit, aber Cyrus SASL beispielsweise erwartet ein Klartext-Passwort in der Datenbank, wird das Plugin "SQL auxprop" verwendet. Die sogenannten "Frost-Patches" helfen hier ebenfalls leider nicht weiter - abgesehen davon, dass sie in führenden Linux-Distributionen, die auch im professionellen Umfeld verwendet werden, nicht enthalten sind. Und pam_mysql unterstützt zwar Passwörter als MD5- oder SHA1-Hash (abgesehen von Klartext-Passwörtern), doch keine Salts."
tscha, ok.... darum funktionierten alle meine Versuche nicht!
Die Lösung habe ich aber leider nicht ganz verstanden, bzw wie man dies dann konfiguriert. Unter Debian gibt es da kein Paket man muss dieses dann wohl selber kompilieren.:
"Genau diese Lücke füllt pam_mapi durch die Bereitstellung von MAPI-basierter Authentifizierung, die dann wiederum von einem SASL-Daemon für den SMTP-Dienst verwendet werden kann. Typischerweise wird Sendmail oder Postfix verwendet und "saslauthd" (aus Cyrus SASL) kümmert sich dann mittels pam_mapi um die Prüfung der Benutzer-Informationen aus dem SMTP-Dialog. Letztendlich baut pam_mapi eine Verbindung zum hinterlegten Kopano- bzw. Zarafa-Server auf und führt eine Anmeldung durch - das Ergebnis wird entsprechend zurückgeliefert woraufhin der SMTP-Dienst dann den Versand von E-Mails zulässt oder ablehnt. Lizenziert ist pam_mapi unter der 3-Klausel-BSD bzw. GNU General Public License (GPL), da es einen potentiellen Konflikt zwischen der GNU GPL und den Einschränkungen beim Copyright im BSD-Stil gibt."
Habt ihr noch Ideen?
