Huhu,
Zu Ihrem Problem gibt es keine direkte Lösung, weil das aktuelle Verhalten “working as intended” ist. Wir haben in einem ganz anderen Zusammenhang mit genau diesem Problem zu kämpfen gehabt, in der Zeit viel mit Univention kommuniziert und haben schließlich eine eigene (eingeschränkte) Variante des Self-Services implementiert, der den udm-Befehl zur Passwortänderung nutzt (siehe unten, warum).
Meine Frage habe ich dann daher gestellt, weil die Nutzung von UCS als LDAP-Server das Problem komplett umgehen würde.
Es gibt momentan schlicht mehrere verschiedene Varianten, wie Passwörter geändert werden können. Zwei davon triggern die Passwortänderung am OpenLDAP, wodurch userPasswort gesetzt wird; von dort aus wird das Passwort zu Samba4 synchronisiert. Die anderen Mechanismen kommen von der anderen Seite: sie triggern die Passwortänderung via Kerberos, schreiben also initial ins Samba, und von dort werden die modifizierten Kerberos- und NT-Passwort-Felder ins OpenLDAP synchronisiert.
Das Problem am zweiten Weg ist schlicht, dass Samba keinerlei Zugriff aufs neue Klartextpasswort bekommt, wenn ich das richtig verstanden habe, und damit gar nicht das für userPassword nötige Hashing vornehmen könnte. Außerdem gibt es im AD-LDAP-Schema das Feld für das Unix-Passwort schlicht nicht.
Hier die zwei Methoden, wir das Passwort OpenLDAP-seitig geändert werden kann:
- Über den Kommandozeilenbefehl
univention-directory-manager bzw. udm, z.B. udm users/user modify --dn uid=mbunkus,… --set password=SuperSecret
- Über die webbasierte Univention Management Console, wenn man als Administrator angemeldet ist und dort im User-Modul einen Benutzer ändert
Hier ein paar Methoden, die letztlich über Kerberos laufen und damit nur noch {K5KEY} im OpenLDAP-userPassword-Attribut hinterlassen:
- Das Self-Service-Modul
- Wenn man sich als normaler User in der Univention Management Console anmeldet und sein eigenes Passwort ändert
- Wenn man’s über PAM ändert (z.B. Anmeldung via ssh, dann mit dem Befehl
passwd)
- Wenn man an einem Windows-PC angemeldet ist und die dort vorhandene Funktion zur Passwortänderung nutzt
Nein, das mag früher vielleicht wirklich so gewesen sein. Ich bin mir aber nahezu absolut sicher, dass wir aufgrund der oben aufgeführten Randbedingungen nicht mehr in die Situation kommen werden, in der wir uns auch nur ansatzweise auf den Inhalt von userPassword verlassen können.
Gruß
mosu
– eigentlich hätte ich mir ja denken können, dass es dafür einen Konfigurationsschlüssel gibt. Und ja, README zu k5pwd.c schreibt “This module was copied from smbk5pwd.”