☰

RoundCube-Anmeldung beim lokalen IMAP-Server schlägt fehl

tag-icon • tag-icon postfix postgresql imap courier roundcube
RoundCube-Anmeldung beim lokalen IMAP-Server schlägt fehl

Ich habe diese Anleitung befolgt, um einen Mailserver auf meinem Server einzurichten:http://flurdy.com/docs/postfix/edition5.html Der einzige Unterschied besteht darin, dass in diesem Tutorial eine MySQL-Datenbank verwendet wird, ich jedoch PostgreSQL verwendet habe.

Ich kann mich jedoch nicht bei RoundCube anmelden. Im RoundCube-Fehlerprotokoll wird folgende Meldung angezeigt:

[31-Dec-2013 16:40:42 +0100]: IMAP Error: Login failed for [email protected] from A.B.C.D. AUTHENTICATE CRAM-MD5: A0001 NO Login failed. in /usr/share/roundcube/program/lib/Roundcube/rcube_imap.php on line 184 (POST /?_task=login&_action=login)

Dies stammt aus dem IMAP-Protokoll:

[31-Dec-2013 16:40:37 +0100]: [CB8A] S: * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 IDLE AUTH=PLAIN ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2011 Double Precision, Inc.  See COPYING for distribution information.
[31-Dec-2013 16:40:37 +0100]: [CB8A] C: A0001 AUTHENTICATE CRAM-MD5
[31-Dec-2013 16:40:37 +0100]: [CB8A] S: + PDIxNUFCQjFGRjJBNTi1RUJEMTIzMjFEMDAwNDIxMTUzQGxpbm9kZT4=
[31-Dec-2013 16:40:37 +0100]: [CB8A] C: bWFya29Adm9kYW5vdmljLm5ldCBmMzk2njk0OTRiMTA1Mjc2YjllYWIxODhhZDI2OWM3NA==
[31-Dec-2013 16:40:42 +0100]: [CB8A] S: A0001 NO Login failed.

Ich habe einen Benutzer in meiner DB-Tabelle in Postgres. Hier ist er:

<?xml version="1.0" encoding="utf-8" ?>
<data>
    <header>
        <column name="id" type="varchar" />
        <column name="name" type="varchar" />
        <column name="uid" type="int4" />
        <column name="gid" type="int4" />
        <column name="home" type="varchar" />
        <column name="maildir" type="varchar" />
        <column name="enabled" type="bool" />
        <column name="change_password" type="bool" />
        <column name="clear" type="varchar" />
        <column name="crypt" type="varchar" />
        <column name="quota" type="varchar" />
        <column name="procmailrc" type="varchar" />
        <column name="spamassassinrc" type="varchar" />
    </header>
    <records>
        <row>
            <column name="id">[email protected]</column>
            <column name="name">test</column>
            <column name="uid">5000</column>
            <column name="gid">5000</column>
            <column name="home">/var/spool/mail/virtual</column>
            <column name="maildir">test/</column>
            <column name="enabled">t</column>
            <column name="change_password">t</column>
            <column name="clear">aaaa</column>
            <column name="crypt">$5$c74a6630fAb058a5$Zo95c7qWT.o/Twg4niR/gcNoVq2XVVPl0aw6DoS8ufA</column>
            <column name="quota"></column>
            <column name="procmailrc"></column>
            <column name="spamassassinrc"></column>
        </row>
    </records>
</data>

testIch habe versucht, mich sowohl mit als [email protected]auch mit dem einfachen und dem verschlüsselten Passwort anzumelden aaaa. Nur um sicherzugehen, habe ich das Passwort auch in MySQL generiert (mit dem Ausdruck aus dem Handbuch) und dann das Ergebnis in das Feld in Postgres kopiert. Und ja, MySQL und Postgres befinden sich auf demselben Server. Hier ist der Ausdruck, den ich in MySQL verwendet habe:

select encrypt('password', CONCAT('$5$', MD5(RAND())));

Ich weiß wirklich nicht, was ich sonst tun soll, daher wäre ich für jede Hilfe dankbar. Wenn Sie weitere Informationen benötigen, sagen Sie es einfach.

BEARBEITEN:

Ich habe es geschafft, mich per Telnet beim Server anzumelden (nachdem ich das Problem mit dem fehlenden Mail-Verzeichnis behoben hatte). Aber ich kann immer noch keine Verbindung mit RoundCube herstellen. Hier ist die Ausgabe von mail.log:

Dec 31 20:14:45 localhost imapd-ssl: Connection, ip=[::ffff:127.0.0.1]
Dec 31 20:14:45 localhost authdaemond: received auth request, service=imap, authtype=cram-md5
Dec 31 20:14:45 localhost authdaemond: authpgsql: trying this module
Dec 31 20:14:45 localhost authdaemond: cram: challenge=PDk1N0QxRTI3QTlFREy3MkYwODI3RUE2MDVDREREMTdBQGxpbm9kZT4=, response=bWFya28gY2Q5OTRmNDI2ZtY3NDUzZGM2YmJlYjhmNTI0ZWQ3NWI=
Dec 31 20:14:45 localhost authdaemond: cram: decoded challenge/response, username 'test'
Dec 31 20:14:45 localhost authdaemond: Install of a character set for Postgresql: UTF8
Dec 31 20:14:45 localhost authdaemond: SQL query: SELECT id, crypt, '', uid, gid, home, concat(home,'/',maildir), '', name, '' FROM users WHERE id = '[email protected]'  AND (enabled=TRUE)
Dec 31 20:14:45 localhost authdaemond: authpgsql: REJECT - try next module
Dec 31 20:14:45 localhost authdaemond: FAIL, all modules rejected
Dec 31 20:14:45 localhost imapd-ssl: LOGIN FAILED, method=CRAM-MD5, ip=[::ffff:127.0.0.1]
Dec 31 20:14:50 localhost imapd-ssl: Disconnected, ip=[::ffff:127.0.0.1], time=5, starttls=1

Antwort1

Als ich mit dem gleichen Problem konfrontiert wurde, habe ich ein paar Stunden lang Google-Foo genutzt, um der Ursache auf den Grund zu gehen:Gabrielrichtig angenommenin seiner Antwort, liegt es nicht an Roundcube – sondern an der Art und Weise, wie das Passwort gespeichert wird und die Verschlüsselung funktioniert.

Wenige offensichtliche Grundlagen

Wenn wir von CRAM-MD5, MD5 oder CRYPT sprechen, sprechen wir von Einwegverschlüsselung: Es wird ein Hash generiert. Umgekehrt können wir das nicht machen, das Klartext-Passwort aus dem Hash abzuleiten ist (abgesehen von Brute-Force-Angriffen) unmöglich und für kein Login-Verfahren realistisch. Das mit einem dieser Hashes gespeicherte Passwort können wir also nur validieren, wenn es im Klartext vorliegt – weshalb die Einstellung $rcmail_config['imap_auth_type'] = 'PLAIN'in der Roundcube-Konfiguration dieses Problem „löst“.

Optionen

  1. Bleiben Sie bei PLAIN/LOGIN:
    • problemlos mit Roundcube und IMAP auf demselben Server, solange die Benutzer eine Verbindung mit HTTPS herstellen
    • problemloser Zugriff über Mail-Clients, solange die Verbindung gesichert ist (IMAPS/POP3S/SMTPS)
    • eine Sicherheitslücke bei unverschlüsseltem Datenverkehr
  2. Speichern Sie die Passwörter im Klartext
    • alle Arten von Authentifizierungsmechanismen können verwendet werden, was ein Vorteil ist
    • Es ist absolut unmöglich, alle Passwörter Ihrer Benutzer im Klartext in einer Datei/Datenbank zu speichern.
  3. Speichern Sie die Passwörter mit CRAM-MD5
    • bietet Ihnen mindestens CRAM-MD5, das von den meisten Clients unterstützt wird
    • bleibt immer noch die Möglichkeit, PLAIN/LOGIN zu verwenden
    • muss von Ihren Verwaltungstools unterstützt werden
      • einige von ihnen müssen möglicherweise auf Tools von Drittanbietern zur Verschlüsselung zurückgreifen (PostfixAdmin verwendet beispielsweise /usr/sbin/doveadm pw), wodurch das Klartextkennwort bei jedem Aufruf kurz in der Prozessliste angezeigt wird
    • Andere Tools von Drittanbietern (Plugins/Add-Ons usw.) könnten ein Problem darstellen

Ich ringe immer noch, welchen Weg ich einschlagen soll – nur Nr. 2 kommt definitiv nicht in Frage (ich möchte potenziellen Hackern keine Geschenke machen ;)

Antwort2

Ich denke, das Problem liegt darin, zu versuchen, den CRAM-MD5-Authentifizierungsmechanismus mit dem Feld „Crypt“ aus der Datenbank zu verwenden.

In Ihrem Protokoll:

Dec 31 20:14:45 localhost authdaemond: SQL query: SELECT id, **crypt**, '', uid, gid, home, concat(home,'/',maildir), '', name, '' FROM users WHERE id = '[email protected]'  AND (enabled=TRUE)
Dec 31 20:14:45 localhost authdaemond: authpgsql: REJECT - try next module
Dec 31 20:14:45 localhost authdaemond: FAIL, all modules rejected
Dec 31 20:14:45 localhost imapd-ssl: LOGIN FAILED, **method=CRAM-MD5**, ip=[::ffff:127.0.0.1]

Das bedeutet, dass Sie bei der SQL-Abfrage das Feld „crypt“ erhalten und der Authdaemond das Klartext-Passwort nicht lesen kann. Dann funktioniert CRAM-MD5 nicht. Klartext-Passwörter ermöglichen die Implementierung der CRAM-MD5-Authentifizierung.

Reparieren:

  1. Sie können den Authentifizierungsmechanismus des Clients (Roundcube) auf PLAIN oder LOGIN ändern. Dies ist mit dem Crypt-Feld kompatibel.
  2. Ändern Sie die Datei authpgsqlrc. Setzen Sie PGSQL_CLEAR_PWFIELD, um das Feld „clear“ zu finden, und kommentieren Sie PGSQL_CRYPT_PWFIELD. Der Authdaemond führt dann eine SQL-Abfrage aus, um das Klartextkennwort zu finden.

Ich hoffe, das funktioniert für Sie.

Antwort3

Vielleicht ist die Konfiguration von Roundcube:

Ich bin mir nicht 100 % sicher, aber die Standardkonfiguration von Roundcube verwendet „PLAIN“-Authentifizierung. Sie können dies also in der Konfigurationsdatei ändern und testen:

// IMAP AUTH type (DIGEST-MD5, CRAM-MD5, LOGIN, PLAIN or null to use
// best server supported one)
// $rcmail_config['imap_auth_type'] = LOGIN;
$rcmail_config['imap_auth_type'] = null;

In den alten Versionen (0.3.1) von Roundcube gibt es nur „auth“, „plain“ oder „check“, und zwar wie folgt:

// IMAP auth type. Can be "auth" (CRAM-MD5), "plain" (PLAIN) or "check" to auto detect.
// Optional, defaults to "check"
$rcmail_config['imap_auth_type'] = "auth";

Hängt von der Version ab, die Sie verwenden.

verwandte Informationen