Migration 1.8.007 nach 17.1 - Passwörter

[KThg]

Hallo zusammen,

ich habe heute die Datenbankmigration von einer 1.8.007 nach 7.1.20180523 durchgeführt. Alles lief ohne Fehlermeldungen durch. Ich konnte mich auch problemlos anmelden und selbst die Mailkonten wurden übernommen.

Jetzt kommt das entscheidende Problem. Die Benutzer können ihre Passwörter nicht mehr ändern. Es kommt ein “Passwortänderung fehlgeschlagen”

Szenario2: Als Admin versuche ich über “Rücksetzen mehrerer Passwörter…” die Passwörter zu ändern. Gleiche Fehlermeldung

Szenario3: In der Benutzerverwaltung ändere ich als Admin das Passwort. Es kommt ebenfalls ein "Error changing password for 25!!!"
Allerdings wird hier das Passwort geändert! Erneutes einloggen mit dem neuen Passwort funktioniert. Eine Passwortänderung durch den Benutzer aber erneut nicht.

Im Apachelog gibt es keine Auffälligkeiten. Wird hier noch irgendwo geloggt oder hat jemand einen Tipp?
Alle Anwendungen laufen prima, nur mit diesem Problem kann ich leider nicht aktiv schalten. Ich habe die Durchläufe etliche Male wiederholt immer das gleiche Problem.

Die Diagnosemeldungen vom Durchlauf Migration habe ich mal angehängt.

Vielen Dank für Eure Mühe und jeden Hinweis.

System:
Debian 8.10‬
Apache mit PHP 7.0.30 fpm

Grüße
Kaydiagnosemeldungen_egw.txt (272.4 KB)

[StefanU]

Hallo Kay,

hast du denn dieses mal eine Paketinstallation?
Hast du egroupware-epl-compat (siehe Release Notes 17.1) installiert?

Gruß
Stefan

[KThg]

Die angehängten Diagnosemeldungen sind noch ohne Paketinstallation. Ich habe aber zwischenzeitlich 2 VM´s mit Ubuntu und openSuse aufgesetzt. Hier habe ich jeweils die Paketinstallation genutzt. Das Paket egroupware-epl-compat wurde initial mitinstalliert. Es laufen auch alle Anwendungen fehlerfrei und alle Daten sind vorhanden. Ich hänge an dem Thema seit Monaten. Möchte endlich wechseln, da man die 1.8 eigentlich nicht mehr einsetzen sollte. Vor ein paar Wochen habe ich das ganze auch Step by Step durchgezogen. 1.8 -> 14 -> 16 -> 17… Leider das identische Ergebnis. Ich würde mir ja sogar die Arbeit machen die ca 90 Accounts neu anlegen, aber dann weiß ich nicht wie ich die Daten sauber mitbekomme. Für den Support haben wir als gemeinnütziger Verein gerade nicht wirklich ein Budget :-(.

[KThg]

Unter der 7.1.20180523 habe ich auch erstmals keine Datenbankfehler. Ich habe die Datenbanken auch mit einer Grundinstallation auf dem Server verglichen. Alle Indexe etc. sind identisch.

[StefanU]

Hi Kay,

ich habe da nun nicht wirklich eine Idee.

Aber was passiert, wenn du bei einem Benutzer in der DB den Inhalt aus account_pwd löscht und als Admin das PW neu setzt? Hast ja ein Testsystem…

Benutzt du eigentlich die EGw-eigene Datensicherung um die Daten von 1.8 nach 17.1 zu bringen?
Im Setup ist alles auf grün?

Gruß
Stefan

[KThg]

Hi Stefan,

vielen Dank für Deine Mühe!

Ich habe das gerade getestet. Habe Passwort in DB gelöscht und ein neues eingefügt. (HashGenerator) Ich kann mich mit dem neu generierten Passwort anmelden. Eine Passwortänderung geht nicht.

Jetzt hatte ich noch die Idee die Accounts komplett zu löschen und mit identischer ID neu anzulegen. Das klappt auch nicht, eine Passwortänderung ist nicht möglich.

Ich habe die Datenbank aus der egw eigenen Datensicherung, durch einen in der Shell erstellten Dump und durch kopieren in Plesk probiert. Immer das gleiche Ergebnis.

Kämpfe seit fast einem Jahr an dem Problem und komme einfach nicht weiter.

Güße
Kay

[RalfBecker]

Hi Kay,

ich würde als erstes mal verifizieren in Setup >> Gegenwärtige Konfiguration überarbeiten, dass bei “Welche Art der Authentifizierung wollen Sie benutzen” und “Wo wollen Sie die Benutzerkonten speichern” beides mal SQL eingestellt ist und nicht etwas anders.

Dann gibt es eine ACL, ob ein Benutzer sein Passwort ändern darf, das sollte aber nicht zu einem Fehler führen.

Ein Fehler könnte es geben, wenn Du einen Passwort Hash eingestellt hast, der eine PHP Erweiterung braucht, die du nicht (mehr) installiert hast. Hier sollte bei “SQL-Verschlüsselungstyp für das Passwort” heute immer “blowfish_crypt” eingestellt sein.

Ansonsten kann ich nur empfehlen abzuwägen wieviele Stunden/Tage Du schon mit dem Problem verbracht hast im Verhältnis was eine Stunde Support bei uns kostet.

Ralf

[KThg]

Hi Ralf,
Danke für den Input. In der 1.8 ist in der Tat noch ein sehr ungünstiges Verschlüsselungsverfahren eingestellt. Es war md5 eingetragen. Ich habe jetzt blowfish eingestellt - > erlaube Passwort Migration Ja - > erlaubte Typen md5 eingetragen. Die Passwörter stehen in der 1.8 noch als md5 Hash drin. Ändere ich das Passwort wird ein blowfish Hash erzeugt. Auth steht alles auf SQL.

Passt das so?

Ja, Du hast vermutlich recht. Das steht schon lange in keinem Verhältnis mehr. Wenigstens habe ich einiges gelernt. Leider im Moment kein Budget, bin aber dran.

Danke und Gruß
Kay

[KThg]

Problem gelöst. Manchmal kann es so einfach sein. Einige Migrationsprobleme haben sich zwischenzeitlich gegeben. Blieb das Passwort. Warum auch immer stand in der egroupware 1.8 “Welche Art der Authentifizierung…” SQL / SSL. Den Eintrag in SQL geändert und es geht. Hat also überhaupt nichts mit der Migration zu tun. Fehler lässt sich reproduzieren. Wieder zurückgestellt, Problem wieder da.

Danke für die Unterstützung!