Anmeldung nach Migration an Windows10-Client nicht möglich

Hallo zusammen,

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:
    2020-07-11_23-13

  • 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.

Viele Grüße

Tobi

Hallo Tobias,

  • 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:

  1. es sagt nicht vorher, wie die WebUI, was benötigt ist (komplexity)
    und was erlaubte Zeichen sind.
  2. 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.

LG

Holger

Hallo Holger,

vielen Dank für Deine schnelle Antwort.

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

Gibt es ein Label für „Problem zu 50% gelöst“? :wink:

Hallo,

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.

reinitial_nt_hashes.zip (379 Bytes)

Viele Grüße

Tobi

2 „Gefällt mir“

Hallo Tobi,

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.

reinitial_nt_hashes.zip
https://ask.linuxmuster.net/uploads/short-url/qyUm6PnIZNT0s0HWA8QjPj5fnPa.zip
(379 Bytes)

perfekt: vielen Dank :slight_smile:

LG
Holger

Hallo ihr,
das hochladen des passworthashes ins AD sollte eigentlich ausreichen.
Ich werd mich da schlau machen und mich melden.

LG, Rüdiger

1 „Gefällt mir“

Hallo zusammen,

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.

Viele Grüße

Tobi