Benutzer können Passwort nur teilweise ändern

bitboy0 · May 25, 2018, 8:17am

Leider kann das UCS/Kopano bei uns immer noch nicht produktiv gehen.
Heute habe ich ein neues Problem gefunden:slight_smile:
Nutzer können normal ja über das Menü des Portals oder über Selfservice ihr Passwort selber ändern.
Das funktioniert aber nicht richtig!

Nach dem das Passwort geändert wurde können sie sich mit dem neuen Passwort am Portal anmelden, die Kopano Web-App aufrufen und Mails per POP/IMAP abrufen, aber NICHT PER SMTP Mails schicken.

Da funktioniert dann weder das alte, noch das neue Passwort.

Ich kann das gewünschte Passwort dann über die Adminoberfläche setzen. Dabei erhalte ich NICHT die Warnung, dass das Passwort schon verwendet wurde. Danach geht dann aus Sicht den Benutzers alles wieder wie gewohnt, auch SMTP und DANN erhalte ich beim Versuch das gleiche Passwort noch mal zu setzen einen Fehler, wenn ich die Historie nicht abschalte.

PS:
So, hab lange mit Kopano telefoniert:
Fakt ist, dass das Passwort mit Kopano syncronisiert wird. IMAP/POP/WEBAPP arbeiten sofort mit dem neuen Passwort. Und man kann sich mit dem selbst geänderten Passwort auch im Portal anmelden.

Aber SUBMISSION über Port 587 nicht. Der wird von Postfix gestellt.

Welchen Unterschied gibt es zwischen dem Ändern des Passwortes als angemeldeter User im Portal und wenn ich es als Admin in der Benutzerverwaltung mache?

Moritz_Bunkus · May 25, 2018, 12:02pm

Moin,

Postfix auf Port 587 (submission) erfordert Authentifizierung. So weit, so klar. Für die Authentifizierung nutzt Postfix den saslauthd (siehe /etc/postfix/sasl/smtpd). Der saslauthd wiederum ist standardmäßig so konfiguriert, dass er die Authentifizierung via PAM und nicht direkt gegen den LDAP-Server macht (siehe /etc/default/saslauthd).

In dieser Datei sieht man auch, dass der saslauthd standardmäßig mit der Option -c gestartet wird, was das Cachen der Authentifizierung aktiviert. Ich vermute, dass die bei Ihnen dazwischen funkt.

Ich kann das Problem aber, ehrlich gesagt, nur begrenzt nachvollziehen. Was ich mache:

Initialer Test mit altem Passwort funktioniert: swaks --from root@$(hostname -f) --to root@$(hostname -f) --server 127.0.0.1:587 --tls starttls --auth plain --auth-user mbunkus --auth-password secret1234 --quit-after rcpt
Passwort mit udm ändern: udm users/user modify --dn uid=mbunkus,cn=users,$(ucr get ldap/base) --set password=secret4711
Erneuter Test mit altem Passwort funktioniert weiterhin (wegen Cachings): swaks --from root@$(hostname -f) --to root@$(hostname -f) --server 127.0.0.1:587 --tls starttls --auth plain --auth-user mbunkus --auth-password secret1234 --quit-after rcpt
Test mit neuem Passwort funktioniert ebenfalls: swaks --from root@$(hostname -f) --to root@$(hostname -f) --server 127.0.0.1:587 --tls starttls --auth plain --auth-user mbunkus --auth-password secret4711 --quit-after rcpt
Erneuter Test mit altem Passwort funktioniert nun nicht mehr, weil der saslauthd gesehen hat, dass die gecacheten Credentials falsch sind.

Anschließend habe ich auch noch mal getestet, was passiert, wenn ich nicht als Admin das Passwort ändere, sondern als betroffener User über den Self-Service. Hier kann ich das Problem durchaus nachvollziehen.

Beide Methoden ändern das Passwort auf unterschiedliche Weise. Bei Verwendung des Self-Service-Moduls (und auch z.B. wenn man sein Passwort in Windows über Strg+Alt+Entf → »Passwort ändern« ändert) wird das Passwort über Kerberos geändert, sodass im Unix-Passwort-Feld anschließend nur noch {K5KEY} steht. Die Authentifizierung via LDAP-Bind funktioniert anschließend weiterhin problemlos, aber halt nicht, wenn ein Dienst versucht, den Wert aus dem Attribut userPasswort direkt auszulesen.

Das Problem ist übrigens auch schon seit längerem bekannt; ich hatte dazu in 2016 schon mal einen Bug eröffnet. Im Bug ist auch ein Workaround beschrieben: man konfiguriert den saslauthd so um, dass er nicht PAM nutzt, sondern direkt gegen den LDAP-Server authentifiziert (mit LDAP-Bind). LDAP-Binds funktionieren, wie oben gesagt, auch nach einem Passwortwechsel via Kerberos.

Gruß
mosu

bitboy0 · May 25, 2018, 1:33pm

Das hört sich schon mal sehr interessant an…

allerdings funktioniert bei mir nach dem Passwortwechsel durch den User selber gar kein Passwort mehr… weder das alte, noch das neue. Also der Cache scheint das alte Passwort auch nicht mehr zu enthalten.

Ich habe noch ein Ticket bei Univention laufen und warte mal ab was die schreiben. Am liebstebn wäre mir natürlich eine offizielle Lösung, die auch ein Update überlebt.

Moritz_Bunkus · May 25, 2018, 1:50pm

Huhu,

Ja, das ist bei mir auch so, wenn der Benutzer sein eigenes Passwort ändert. Wenn aber der Admin es ändert, z.B. durch den Aufruf von udm users/user modify… oder über die UMC, so wird das alte nach Wechsel akzeptiert, weil gecachet. In beiden Fällen kommen halt unterschiedliche Mechanismen zur Passwortänderung zum Einsatz.

Gruß
mosu

bitboy0 · May 25, 2018, 2:20pm

Wenn die von dir genannte Lösung/Workaround gut funktioniert würde ich mich über etwas Hilfe bei der Installation dieser freuen.

Also erst mal das Verzeichnis
/etc/univention/templates/files/etc/saslauthd.conf.d/
anlegen (welche Rechte?)
Dann den Text beginnend mit @% und endend mit !@ in das Verzeichnis in eine Datei mit dem Namen
99_custom
schreiben (welche Rechte?)

Dann einVereichnis
/etc/univention/template/info/custom
anlegen

Dort eine Datei
custom
mit dem Inhalt des nächsten Abschnitts (beginnen mit Type: multifile)
Muss ich da die variablen mit den Daten meines System ersetzen oder sind das schon die richtigen Werte?

Dann die Datei
/usr/lib/univention-server/server_password_change.d/custom-saslauthd
anlegen mit dem Inhalt im nächsten Abschnitt und chmod 700?

wars das dann schon? ich bin was so was angeht noch nicht so arg weit mit Linux … also wäre ich echt dankbar für eine Erklärung, die ein funktionierendes System hinterlässt

Moritz_Bunkus · May 28, 2018, 8:16am

Hey,

Ist schon etwas her, dass ich damit experimentiert hatte. Aktuell setze ich die Lösung so nicht ein, kann also nicht sagen, ob die noch 1:1 funktioniert. Der Bug-Report ist immerhin von 2016 und für ältere UCS-Versionen gedacht. Kannst es trotzdem gerne probieren.

Solltest du nicht anlegen müssen. Meine Situation ging davon aus, dass das Paket univeniton-sasl installiert ist. In dem Fall existiert das Verzeichnis bereits (und auch ein paar Dateien darin). Daher solltest du als erstes besagtes Paket installieren.

Ja. Rechte: root:root, 0644

Jein. Die Datei heißt custom direkt im Verzeichnis /etc/univention/template/info. Kein Unterverzeichnis.

Die Variablen werden vom Tool ucr in dem Moment durch die aktuell gültigen Werte ersetzt, wenn mit ucr commit /etc/saslauthd.conf die Datei neu gebaut wird. Das fehlt in meiner Anleitung übrigens; den Befehl musst du am Ende einmal manuell ausführen, genauso wie einen Neustart des saslauthd-Daemons.

Rechte sind auch hier wieder: root:root, 0644

Jup.

Hintergrund: das ist das Univention-Template-System, mit dem Konfigurationsdateien aus Vorlagen erzeugt werden, wobei UCR-Variablen berücksichtigt werden können. Ich hatte zur Funktionsweise mal einen Blog-Post geschrieben; falls du ein wenig mehr darüber wissen willst, was da passiert.

Der letzte Teil (die server_password_change.d) wird aus einem anderen Grund benötigt. Der saslauthd muss sich mit dem LDAP-Server verbinden, um nach Benutzeraccounts zu suchen. So eine Verbindung erfordert standardmäßig eine Authentifizierung, sprich einen LDAP-Account, mit dem sich der saslauthd anmeldet. Glücklicherweise gibt es für jeden UCS-Server ein Konto im LDAP, das genau dafür genutzt wird (UCR-Variable ldap/hostdn). Allerdings wird das dazugehörige Passwort regelmäßig geändert — und sobald das passiert, muss eben auch die /etc/saslauthd.conf mit besagtem neuen Passwort neu erzeugt werden. Das erledigt das Script, denn nach jedem Passwortwechsel des Serverkontos werden alle Scripte in diesem Unterverzeichnis automatisch ausgeführt.

Gruß
mosu

bitboy0 · May 29, 2018, 9:54am

Der Univention-Support hat mir eine Lösung genannt, die weit weniger aufwändig ist.
Das Problem scheint wohl daher zu kommmen, dass als Nutzername historisch eigentlich die primäre-Mailadresse erwartet wird und damit funktioniert es wohl auch. Allerdings ist das für Kopano-Nutzer mit mehreren zugeordneten Adressen etwas verwirrend.

Da PAM nach einer Änderung des Passworts durch den Nutzer aber nicht funktioniert, weil der nötige Hash dann nicht verfügbar ist, kann man PAM optional machen und dann erfolgt die Auth durch ein anderes Verfahren weiter unten in der Liste.

in /etc/pam.d/smtp steht
auth requisite pam_univentionmailcyrus.so ldap_host=master.schein.ig ldap_base=dc=schein,dc=ig from_attr=mailPrimaryAddress to_attr=uid binddn=cn=master,cn=dc,cn=computers,dc=schein,dc=ig pwfile=/etc/machine.secret ldap_port=7389

Das requisite wird hier gegen optional getauscht und im Ergebnis gehts dann.

Damit es dauerhaft überlebt muss man das in
/etc/univention/templates/files/etc/pam.d/smtp
auch ändern und mit ucr commit /etc/pam.d/smtp bestätigen.

Deine Lösung würde es wohl eleganter lösen, ist aber nicht zwingend erforderlich.

Schwardt · May 30, 2018, 3:23pm

Hallo,

Wie bereits in Saslauthd pam_authenticate failed beschrieben wurde, bleiben einem, bis es eine Paketanpassung gibt, nur 2 mögliche Lösungen:

Verwenden der primären Mailadresse als Authentifizierungsbenutzer
Anpassen des UCR-Templates (wie von dir beschrieben)

Viele Grüße

Sönke