Login nach erstem Neustart nicht mehr möglich

Hallo *,

Ich habe folgendes Problem:
Ich habe ein Windows 11 Image, welches ich auf Laptops (nativ nur WLAN-Schnittstelle) verteilen möchte.
Damit die Cache-Partition schnell befüllt wird, habe ich die Laptops mit einem LAN-USB-Dongle gebootet und unter einem temporären Gerätenamen die Cachepartition via linbo-remote aktualisiert.
Anschließend habe ich Linbo im WLan gebootet und von Hand mit dem korrekten Gerätenamen einen Rotstart durchgeführt.

Nun das Problem: Direkt nach dem ersten Start klappt der Login ohne Probleme. Nach einen Neustart (egal ob zuvor ein Login erfolgt ist oder nicht) ist ein Login nicht mehr möglich. Als Rückmeldung erhalte ich lediglich, dass Nutzername oder Passwort falsch wären (sind sie aber nicht).
Das ganze ist zu 100% reproduzierbar.

Wie kann ich das debuggen? Worin könnte die Ursache liegen? Wer kennt sich da aus - welche Info meinerseits ist noch notwendig?

Lieben Gruß und Danke für die Hilfe
Simon

Hi,

ich habe weder Clients mit Windows 11 noch welche nur mit WLAN, daher hier paar Schüsse ins Blaue:

  • Ist der Client im Windows-Anmeldebildschirm mit dem WLAN verbunden?
  • Wird der korrekte Clientname angezeigt, wenn du im Feld Benutzername „.\“ einträgst?
    • Der Backslash trennt die Domäne bzw. den Computernamen vom Benutzernamen. Der Punkt steht für localhost und zusammen veranlasst diese Eingabe Windows unter dem Eingabefeld den Computernamen anzuzeigen, der bei Anmeldung mit einem lokalen Benutzerkonto verwendet würde.
  • Du schreibst „von Hand mit dem korrekten Gerätenamen einen Rotstart durchgeführt“. Heißt das du hast den Gerätenamen zuvor von Hand korrigiert oder wurde dies durch der korrekte Gerätename durch die Linbo-Mechanismen herbeigeführt?

VG
Buster

Hi Buster, danke für die schnelle Antwort.

  • WLan hat der Client. Das kann man auch im Anmeldebildschirm direkt sehen. Wäre das nicht so, gäbe es eine Fehlermeldung aka „Domäne nicht erreichbar“. Diese wird anscheinend gefunden, aber die Authentifizierung gegen den samba 4 scheint für alle Domänennutzer fehlzuschlagen (negative Antwort). Nur wieso?
  • Clientname sollte stimmen. Habe mich als lokaler Admin angemeldet und da stimmt es.
  • „Von Hand“ meine ich aus der Linbo-Gui direkt am Gerät im Gegensatz zu „Mit Linbo-remote“. Der Gerätename wurde von den Linbo-Mechanismen gesetzt.

Was ich nicht nachvollziehen kann: Wieso klappt es beim erste Start nach sync, aber nicht mehr danach? Und das reproduzierbar? Wird beim Cache-Aktualisieren von Linbo irgendwas am Image angepasst? Ich dachte das passiert erst beim Sync…

VG
Simon

Hallo,

ich weiß nun echt nicht mehr weiter!

Ich habe alles mögliche debugged.
Mit unserem Dienstleister habe ich herausgefunden, dass Die Linbo-Beta wohl einen Bug hat: Wenn Linbo versucht die macct Datei zu lesen, wird diese nicht gefunden, da im falschen Verzeichnis ( /srv/linbo statt /srv/linbo/images/<image>). Außerdem scheint die macct Datei falsche Rechte zu haben.

Wir haben also vom ‚falschen‘ Verzeichnis einen symbolischen Link auf die korrekten Dateien gesetzt und die Rechte angepasst. → Ändert aber nichts am Problem.

Ich habe einen betroffenen PC einer anderen Gruppe mit anderem Windows 11 Image zugewiesen. → Login klappt.
Also vermutete ich, dass es am Image liegt. Ich habe gestern im betroffenen Image den Domänenjoin erneut durchgeführt und das Image neu geschrieben. → Siehe da, der Login klappt. Also > 15 Laptops und auch PCs mit dem Image beschrieben. Alles läuft.

ABER nur bis heute um ca. 11:20Uhr. Just als eine Klasse den Informatik-Biber auf den Geräten, die ich 1h zuvor noch geprüft hatte machen möchte, klappt auf keinem mobilen Gerät (Zugriff via WLAN) mehr der Login. Auf den stationären PCs (via LAN) klappt es. Dann gerade eben einen Laptop neu gestartet und direkt erfolgreich angemeldet. Aber nach einmaligem Abmelden schlägt die Anmeldung dann doch wieder fehl :frowning:
Entschuldigt, aber WTF?

Gleichzeitig hat unser ITler Rechner gesynct (rotstart mit cache-Aktualisierung). Kann es sein, dass das WLAN oder der Server überfordert sind? Wie debugge ich das?

Hoffentlich kann mir jemand helfen… ich weiß nicht weiter.
Danke
Simon

Gerade habe ich folgendes bemerkt:
Der Rechnername auf den vom Image betroffenen Geräten endet auf .DOMAIN statt .domain.lan. Auf Letzteres hatte ich es eigentlich beim neuen Domänenjoin gesetzt.Wie kann es dazu kommen, dass das, obwohl es ursprünglich nicht so im Image war plötzlich bei diesen Geräten anders ist??? @thomas Tut Linbo da irgendwas?

Auf dem Server ist die einzige Datei, die sich seit dem neuen Image gestern geändert hat die .reg Datei

Vielen Dank für weitere Ideen
Simon

Hallo,

in Hinsicht auf das Linbo-Beta-Problem kann ich hier nichts sagen, aber das Problem mit dem Informatik-Biber kann ich für gestern und heute nachvollziehen. Aktuell haben wir hier ein paar ungeklärte Probleme mit dem Proxy, was dazu führt, das die Internetgeschwindigkeit massiv eingeschränkt ist. Das Fehlerbild gleicht sich - Anmeldung am Biber funktioniert nicht oder nur sehr verzögert. Scheint, das die Responsezeit für die Anmeldung beim Biber eine kurze Lunte hat - wenn es länger dauert, bricht es ab. Und da bei Ihnen im Netz gleichzeitig viel Datenverkehr durch Synchronisation war, hat das eventuell den gleichen Effekt, da es ebenfalls die Bandbreite einschränkt … meine Vermutung.

Grüße
H. Schaffrik

@HenryNick Die Anmeldung am Biber funktioniert bei uns. Die Anmeldung an der Domäne am Laptop selbst schlägt fehl.

In der Ereignisanzeige eines betroffenen Geräts sehe ich einen NETLOGON Fehler mit Ereignis-ID 5789.

Kann Ereignis-IDs 5788 und 5789 treten auf - Windows Server | Microsoft Learn das der Grund sein und falls ja, hat jemand eine Lösungsidee?

Hallo Simon,

bitte poste mal die
IMAGENAME.reg
Datei des betroffenen Images.

Vergleich diese auch mal mit der Vorlage in /srv/linbo/*.reg

LG
Holger

Hallo Holger,
an der IMAGENAME.reg kann es eigentlich nicht liegen. Die ist die selbe wie im anderen Image, welches funktioniert. Aber gerne trotzdem, vllt. übersehe ich ja etwas:

Windows Registry Editor Version 5.00

; linuxmuster.net 7

; patches hostname, to be applied after every image sync

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ActiveComputerName\]
"ComputerName"="{$HostName$}"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ActiveComputerName\]
"ComputerName"="{$HostName$}"

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ComputerName\]
"ComputerName"="{$HostName$}"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName\]
"ComputerName"="{$HostName$}"

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\]
"Hostname"="{$HostName$}"
"NV Hostname"="{$HostName$}"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\]
"Hostname"="{$HostName$}"
"NV Hostname"="{$HostName$}"
; add your custom registry patches below

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths]
"\\\\*\\SYSVOL"="RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0"

Danke für die Hilfe.

Ich habe jetzt mal ausprobiert und einem Gerät die Computernamen geändert. Und schon geht der Login dort. Beim Image erstellen hatte ich das auch gemacht. Nur wiese taucht dann plötzlich 23h später der mismatch im Computernamen auf?

LG
Simon

Hallo Simon,

ein Fehlerhafter Rechnernamen deutet schon auf den Regpatch hin: oder besser: einen Fehler beim Regpatchen.
Da die Registry als Dateien auf der Festplatte liegen, kann natürlich ein unsauberes Dateisystem dafür Sorgen, das es Probleme beim Patchen gibt.
Wurden den die Clients mit rot gesynct, bevor das Problem auftritt?
Behebt ein Rotsync das Problem?

Dann wundert mich die letzte Zeile in deinem Regpatch.
Derart statische Registryeinträge (die für alle Cleints gleich sind: also nciht den Hostnamen enthalten) würde ich entweder in den global.reg packen, oder einmal auf dem Cleint die .reg datei ausführen: aber doch nicht bei jedem Sync patchen.
Eine sehr ähnliche Zeile steht auch in der global.reg:

Windows Registry Editor Version 5.00

; linuxmuster.net 7
; thomas@linuxmuster.net
; 20230510

; to be applied once before domain join and image creation
; change SAMBADOMAIN to the name of your samba domainname

; machine account password may not expire
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters]
"DisablePasswordChange"=dword:00000001
"MaximumPasswordAge"=dword:000f4240
"RefusePasswordChange"=dword:00000001
"RequireSignOrSeal"=dword:00000001
"RequireStrongKey"=dword:00000001

; needed for netlogon
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths]
"\\\\*\\netlogon"="RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0"

; disable hiberboot
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Power]
"HiberbootEnabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power]
"HiberbootEnabled"=dword:00000000

; allow users to install printer drivers
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint]
"RestrictDriverInstallationToAdministrators"=dword:00000000

; samba domain, to be adapted
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\]
"DefaultLogonDomain"="SAMBADOMAIN"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters]
"Domain"="SAMBADOMAIN"
"NV Domain"="SAMBADOMAIN"

; don't show the username of the last login
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"dontdisplaylastusername"=dword:00000001

; add your custom registry patches below

Dann eine Frage zu deiner Aussage :

was genau hast du beim Image erstellen gemacht?
Den Rechnernamen geändert?
Stimmte er da auch schon nicht?

LG
Holger

Hallo Holger,
ich stimme dir zu, irgendwas stimmt nicht beim benennen des Rechners, ich weiß nur nicht wo genau? Außerdem weiß ich auch,…

  • Nicht weshalb das die Rechner, welche via LAN angebunden aber ansonsten identisch konfiguriert sind nicht betrifft.
  • Nicht, weshalb Rechner die ein anderes Image nutzen aber den selben Regpatch das Problem nicht haben.
  • Nicht, weshalb wenn ich das funktionierende Image lade und dann die Gruppe ändere und unverändert als neues Image hochlade das Problem wieder auftaucht.

Was mir auffiel ist: „Das primäre DNS-Suffix des Computers stimmt nicht mit dem DNS-Namen der AD DS-Domäne überein, deren Mitglied der Computer ist.“

Was meine ich damit: Wenn der Rechnername: rechner1 ist, dann ist der vollständige Name (mit DNS-Suffix) im Samba rechner1.schule.lan. Auf den betroffenen Laptops ist er aber rechner1.SCHULE hier wird statt der Domäne als Suffix, die Workgroup eingetragen.

Dadurch schlägt die Kerberos-Authentifizierung fehl (aber bisher nur im WLAN ??)

Also habe ich im Image die Domäne verlassen, Neustart, Domäne beigetreten (und geprüft, dass der vollständige Namen korrekt ist), dann heruntergefahren und Image neu erstellt. Das lief dann genau für 23h. Was ich leider nicht gemacht habe, ist geprüft, wie der Rechnername in dieser Zeit auf den komplett neu bespielten Geräten war.

Nun zu deinen anderen Rückfragen:

Das hat unser Dienstleister so eingerichtet und war bisher auch kein Problem (Es hat ja bis vor kurzem noch funktioniert). Aber ich kann ja mal ausprobierne, was passiert, wenn ich das weglasse.

Ja: Formatiert. Rotstart. (Beim ersten Login danach funktioniert es dann manchmal; nach einem Neustart dann aber nicht mehr)
Rotsync behebt das Problem nicht.

Ich bin jetzt auch nochmal alle GPOs durchgegangen und habe diese bereinigt (altes raus geschmissen), die ADMX-Dateien sind auf dem neusten Stand (passend zu Win11).

Kann es sich um ein DNS Problem (in Kombination mit dem fehlerhaften Suffix) handeln?

Vielen Dank für die Gedankenanstöße, Weiter so :smile:

Simon