eigentlich wollten wir an diesem Wochenende nach einem einjährigen Probelauf in unserer Übungsfirma komplett auf die LMN7 umsteigen. Wir sind jetzt auch so gut wie fertig. Wir scheitern aber zum Schluss an ein paar Problemen:
Die Migration aller Benutzer von der LMN6.2 und das Überspielen der Hashes hat soweit funktioniert. Alle Nutzer können sich mit Ihrem bisher benutzten Passwort. An der webUI anmelden. ABER: Dieses Passwort funktiert nicht bei der Anmeldung an einem Windows-10-Client. Allerdings geht -oh-Wunder- bei dem Benutzer das ursprüngliche Erst-Passwort. Das heißt, es gibt irgendwelche Inkonsistenzen. Meine Vermutung: der SSHA-Hash wird kopiert aber nicht der dazugehörige Hash den Windows braucht (ist das noch NTLM?).
Wenn ein Benutzer sein Passwort über die webUI ändert, dann funktioniert die Anmeldung an dem Windows-Client und der webUI. Allerdings kann der Benutzer nicht das Passwort direkt am Client ändern (STRG+Alt+F -> „Kennwort ändern“). Hier erscheint die Fehlermeldung dass das Passwort nicht den Richtlinien entspricht. Die Uhrzeit des Clients und des Servers entsprechen sich: Windows hat die Uhrzeit auf UTC gesetzt und timedatectl sagt auf dem Server:
Und noch eine Kleinigkeit oder auch nicht: Mir ist nicht klar worin sich die Bezeichnung der Benutzerkonten „Enabled“ und „Usable“ unterscheiden.
Ich bzw. wir sind natürlich über Tipps und Hinweise dankbar.
Die Migration aller Benutzer von der LMN6.2 und das Überspielen der
Hashes hat soweit funktioniert. Alle Nutzer können sich mit Ihrem
bisher benutzten Passwort. An der webUI anmelden. ABER: Dieses
Passwort funktiert nicht bei der Anmeldung an einem
Windows-10-Client. Allerdings geht -oh-Wunder- bei dem Benutzer das
ursprüngliche Erst-Passwort. Das heißt, es gibt irgendwelche
Inkonsistenzen. Meine Vermutung: der SSHA-Hash wird kopiert aber
nicht der dazugehörige Hash den Windows braucht (ist das noch NTLM?).
bei der migration meiner Schule vor einem Jahr wurde etwas ähnliches
beobachtet, allerdings nur bei wenigen Konten.
Der Grund war wohl, dass wir direkt vor den Ferien 2019 einen
Lehrerpasswortklau hatten, der dazu führte, dass ich alle
Lehrerpasswörter änderte.
Die hatten dann nach der Migration keien Anmeldeprobleme (auch nicht an
Windows). Schüler aber schon: da deren Passwörter älter waren.
Es schien also damit zusammen zu hängen, dass in der lmn6 irgend wann
mal die Art Passworter im LDAP ab zu legen geändert wurde …
So ist meien Beobachtung: neue Passwörter kanm rüber, alte nciht richtig
(ob die in der WebUI gingen, hab ich nciht probiert).
Das Problem der Schülerpassworte lag dann aber bei den Lehrern: die
haben Schülern, die Probleme hatten, einfach einneus Passwort gegeben:
deswegen weiß ich nciht, wieviele betroffen waren.
Wenn ein Benutzer sein Passwort über die webUI ändert, dann
funktioniert die Anmeldung an dem Windows-Client und der webUI.
Allerdings kann der Benutzer nicht das Passwort direkt am Client
ändern (STRG+Alt+F → „Kennwort ändern“). Hier erscheint die
Fehlermeldung dass das Passwort nicht den Richtlinien entspricht.
die Meldung kommt dann, wenn das Passwort den Richtlinien nicht
entsprich: das ist kein BUG, sondern ein Feature.
Allerdings hat das Passwort ändern am CLietn zwei Probleme:
es sagt nicht vorher, wie die WebUI, was benötigt ist (komplexity)
und was erlaubte Zeichen sind.
die RÜckmeldung ist undifferenziert (Passwort zu einfach) während die
WebUI sagen kann: zu wenig komplex oder unerlaubtes Zeichen.
Deswegen empfehle ich schon immer: Passwortändern → SchulKonsole.
Und noch eine Kleinigkeit oder auch nicht: Mir ist nicht klar worin
sich die Bezeichnung der Benutzerkonten „Enabled“ und „Usable“
unterscheiden.
i dont know: schau mal in die manpages von sophomorix.
Problem 2 haben wir jetzt gelöst. Es war kein Bug sondern die simple Einstellung, dass Passwörter erst nach einem Tag geändert werden dürfen. Das kann man allerdings ausschalten:
samba-tool domain passwordsettings set --min-pwd-age=0
um das zum Abschluss zu bringen und falls jemand über das gleiche Problem stolpert. Wir konnten (dank der Analyse meines Kollegen) folgendes Problem jetzt beheben:
Das sophomoirx-Skript kopiert die Hashes laut Doku mit folgendem Befehl: sophomorix-vampire --datadir /path/to/dir/sophomorix-dump --import-user-password-hashes
Das funktioniert auch und kann mit folgendem Befehl gegen gecheckt werden: pdbedit -Lw <username>
Aber irgendwie sind diese Passwort-Hashes dann nicht für die Windows-Auth-Geschichte verfügbar. Es scheint als ob das reine Migrieren des Hashes nicht ausreicht. Setzt man den Hash eines Users mit pdbedit manuell auf den gleichen Wert der zuvor mit dem obigen Befehl gelesen wurde, dann klappt die Win-Anmeldung: pdbedit -u <username> --set-nt-hash <hash>
Daher habe ich für unsere Zwecke ein kleines Skript geschrieben, dass alles Hashes nach der Migration ausliest und einfach noch Mal setzt. Damit ist das Problem für uns behoben. Falls jemand da drüber stolpert. Hier ist das Skript. Wahrscheinlich gibt es auch eine elegantere Lösung.
Daher habe ich für unsere Zwecke ein kleines Skript geschrieben, dass
alles Hashes nach der Migration ausliest und einfach noch Mal setzt.
Damit ist das Problem für uns behoben. Falls jemand da drüber stolpert.
Hier ist das Skript. Wahrscheinlich gibt es auch eine elegantere Lösung.
nur ein kurzes Update, obwohl ich hoffe/glaube dass das für niemanden mehr von Belang ist. Sofern jemand über das gleiche Passwort-Problem stolpert und mein oben hoch geladenes Skript verwendet gibt es ein kleines Problem mit dem Exam-User. D. h. das Skript funktioniert für den User. Der dazugehörige Exam-User funktioniert dann aber dennoch nicht. Ergo: Die Schüler nach einer Migration bitten, ihr Passwort 1x zu ändern und alles ist gut.
Wie gesagt: Dieser Beitrag ist nur der Vollständigkeit halber. In erster Linie sollte die normale PW-Migration für die Windows-Clients unktionieren.
