login nicht möglich

[Nighthawk11]

Danke für die schnelle Antwort.

Allerdings ist es so, dass ich garantiert den richtigen Benutzernamen und das richtige Passwort nutze, weil ich mit mit genau diesem Benutzer auch in das Login-Center und die Audiostation einloggen kann. Ich habe es gerade nochmal ausprobiert.

Ich wäre über jede Idee dankbar.
Ich habe sogar schon mal die Scripte durchforstet, ob dort irgendwo der Verweis auf /etc/passwd o.ä. zu finden ist. Vielleich stimmt dieser Verweis nicht ... warum auch immer. Habe ihn aber nirgendwo gefunden.

 

[Puppetmaster]

Allerdings ist es so, dass ich garantiert den richtigen Benutzernamen und das richtige Passwort nutze, weil ich mit mit genau diesem Benutzer auch in das Login-Center und die Audiostation einloggen kann. Ich habe es gerade nochmal ausprobiert.

Und bist du dir auch sicher, dass du nicht evtl. Sonderzeichen in deinem Passwort/Benutzernamen hast, auf die roundcube etwas allergisch reagiert?

 

[Nighthawk11]

Wow das ist ja klasse. Die Antworten kommen hier ja super schnell.

Ja das wäre noch eine Fehlerquelle gewesen, denn ich nutze natürlich Sonderzeichen und Großbuchstaben in meinen Passwörter. Allerdings habe ich gerade mal mein Passwort verändert und es hat immernoch nicht funktioniert.
Zudem hatte ich die Prozedur auch schon mit einem Testbenutzer probiert, der wie mir jetzt einfällt, auch keine Sonderzeichen und Großbuchstaben im Passwort hatte. Außerdem würde das auch nicht erklären warum Thunderbird mir ein Authentifizierungfehler liefert, da dieser mit Roundcube gar nichts zu tun hat.

Ich habe die Mailstation und besonders den Mailserver auch schon mehrfach deinstalliert und neuinstalliert. Es hat aber überhaupt nichts gebracht.

Hat sonst noch jemand eine Idee?

Besten Dank für die bisherigen Antworten.

 

[Nighthawk11]

Ich glaube ich habe den Fehler gefunden!

Jetzt schaue ich gerade alle meine Log-Files durch und stoße im auth.log file auf folgende Fehlermeldung:

Nov 13 18:21:30 DiskStation auth: PAM unable to dlopen(/usr/local/arm-none-linux-gnueabi/lib/security/pam_syno_autoblock.so)
Nov 13 18:21:30 DiskStation auth: PAM [error: /usr/local/arm-none-linux-gnueabi/lib/security/pam_syno_autoblock.so: cannot open shared object file: No such file or directory]
Nov 13 18:21:30 DiskStation auth: PAM adding faulty module: /usr/local/arm-none-linux-gnueabi/lib/security/pam_syno_autoblock.so

Das ist mir unerklärlich. Ich arbeite relativ viel mit Linux um zu wissen, dass PAM etwas mit der Authentifizierung zu tun hat und die Einträge sind auch genau in der Zeit des letzten Roundcube-Logins enstanden. Allerdings habe ich nicht die geringste Ahnung warum diese Library nicht geöffnet werden kann, bzw. warum auf diese Library überhaupt zugegriffen wird.
Ich kann mit erinnern, dass ich das arm-none-linux-gnueabi mal genutzt hatte, um einen TeamSpeak-Server auf meiner DS zu installieren. Leider bin ich damals daran gescheitert und habe es seidem gar nicht mehr angefasst. Es gab seitdem aber nie Probleme und ich kann mich auch nicht erinner im meinem System große Eingriffe vorgenommen zu haben, bzw. Libraries-Path geändert.

Was meint ihr dazu?

 

[jahlives]

das ist der syno-Autoblock welchen du im DSM aktivieren kannst damit fehlerhafte Logins überwacht werden. Hat imho nichts mit dem Loginproblem am Dovecot zu tun.
Da du ja den syslog-ng installiert hast: loggt der nicht noch mehr als diese eine Zeile bei einem Loginversuch? Ich würde auch mal den Login auf der Kommandozeile der DS testen

telnet 127.0.0.1 143
a1 LOGIN DEIN_BENUTZER DEIN_PASSWORT

kommt dann eine längere Antwort, die mit einem a1 OK beginnt?

 

[Nighthawk11]

Danke für den Tipp ...
Nein ich bekomme keine weiteren Ausgaben in meinen Logs.
Aber ich habe folgendes eingegeben und folgende Ausgabe bekommen:

root@DiskStation ~ #> telnet 127.0.0.1 143
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Dovecot ready.
a1 LOGIN jannik <password>
a1 NO [AUTHENTICATIONFAILED] Authentication failed.

 

[Nighthawk11]

Hallo Zusammen,

So ... nach 2 Tage langer, intensiver Suche, habe ich nun endlich den Fehler gefunden.
Der ist echt krass und ich hoffe, dass er bei mir einmalig aufgetreten ist. Sollte der Fehler jedoch bei irgendjemand anderem nochmal auftreten, muss Synology direkt kontaktiert werden. Es handelt sich nähmlich um einen Verweisfehler auf Libraries.

Die Fehlerausgabe der Datei auth.log des syslog-ng war doch der Schlüssel des Problems.

Ich glaube ich habe den Fehler gefunden!

Jetzt schaue ich gerade alle meine Log-Files durch und stoße im auth.log file auf folgende Fehlermeldung:

Nov 13 18:21:30 DiskStation auth: PAM unable to dlopen(/usr/local/arm-none-linux-gnueabi/lib/security/pam_syno_autoblock.so)
Nov 13 18:21:30 DiskStation auth: PAM [error: /usr/local/arm-none-linux-gnueabi/lib/security/pam_syno_autoblock.so: cannot open shared object file: No such file or directory]
Nov 13 18:21:30 DiskStation auth: PAM adding faulty module: /usr/local/arm-none-linux-gnueabi/lib/security/pam_syno_autoblock.so

Das ist mir unerklärlich. Ich arbeite relativ viel mit Linux um zu wissen, dass PAM etwas mit der Authentifizierung zu tun hat und die Einträge sind auch genau in der Zeit des letzten Roundcube-Logins enstanden. Allerdings habe ich nicht die geringste Ahnung warum diese Library nicht geöffnet werden kann, bzw. warum auf diese Library überhaupt zugegriffen wird.
Ich kann mit erinnern, dass ich das arm-none-linux-gnueabi mal genutzt hatte, um einen TeamSpeak-Server auf meiner DS zu installieren. Leider bin ich damals daran gescheitert und habe es seidem gar nicht mehr angefasst. Es gab seitdem aber nie Probleme und ich kann mich auch nicht erinner im meinem System große Eingriffe vorgenommen zu haben, bzw. Libraries-Path geändert.

Es ist so, dass das Modul PAM doch wichtig für die Authentifizierung über dovecot ist. Wahrscheinlich wurden bei einem Update, die Libraries von /usr/local/arm-none-linux-gnueabi/lib/security nach /lib/security/ verschoben und die Verweise nicht angepasst. Das PAM kann so die Libraries nicht finden und bricht den Authentifizierungsprozess ab.

Folgender Artikel hat mich darauf gebracht:
http://forum.synology.com/enu/viewtopic.php?f=132&t=66593

Lösung:

Ich habe einfach symbolische Links angelegt, die auf die neuen Pfade der Libraries verweisen.

Das Ausführung der folgenden Befehle, fixt das Problem:

$ cd /usr/local/arm-none-linux-gnueabi/lib/security
$ ln -s /lib/security/pam_syno_autoblock.so pam_syno_autoblock.so
$ ln -s /lib/security/pam_syno_log_fail.so pam_syno_log_fail.so
$ ln -s /lib/security/pam_syno_log_success.so pam_syno_log_success.so

Es funktioniert nun einwandfrei. Ich hoffe ich kann mit diesem Artikel einigen die tagelange Suche ersparen.

Viele Grüße

Nighthawk11