Bei einem Neustart wird das Maschinen Passwort im AD von Linbo zurückgesetzt. Dadzrch hat der Rechner keinen Zugriff mehr aufs AD.
Ist ein bisschen kompliziert, aber inzwischen nicht mehr relevent. Ich sollte den Hinweis entfernen.
VG, Dorian
Hej,
wir haben hier das gleiche Problem - wir wollten eigentlich strukturiert auf den neuen Linuxclient umsteigen. Sonntag Abend hat dann aber (nach einem kleinen Update) die Anmeldung an unserem alten linuxmuster-client-adsso-Client nicht mehr funktioniert.
Rückspielen des Imagebackups (incl. macct-Datei) hat ebenso das Problem nicht behoben, wie erneute Aufnahme des Imagesmasters mit linuxmuster-cloop-turnkey oder linuxmuster-client-adsso-setup + neues Image.
Anfänglich habe ich das update für den Vollausfall verantwortlich gemacht, aber dann habe ich gesehen, dass auch bei einem anderen linuxmuster-client-adsso-Client (Hatten wir für die Migration vorbereitet. Mit eigener Gruppe, eigener start.conf, eigenem cloop/macct) die Anmeldung nicht mehr funktioniert.
Hängt also wohl nicht am Client-Image/macct - Irgendwas muss da auf dem Server anders sein als vor Sonntag Abend.
Letztlich mussten wir auch überhastet auf den linuxmuster-linuxclient7 umsteigen. Haben den nun weitestgehend unangepasst und ohne Hinweise zu Veränderungen unters Volk geworfen. Das ist nicht schön - mich würde schon interessieren, was da los ist. Ich verstehe es einfach nicht.
Die Frage, die mich (und vermutlich auch @dsjiern) noch mehr interessiert: Können wir unseren alten Client migrieren, auch wenn die AD-Anmeldung nicht geht? Die AD-Anbindung wird bei der Migration doch eh erst mal gelöscht und dann linuxmuster-linuxclient7-Style neu angelegt, oder?
Grüße
Michael
Hi Michael,
ja, das kannst Du, anleitung dazu hier im Forum oder ich glaube auch auf der github-seite von linuxmuster-linuxclient7.
LG
Max
Hallo,
ich hab auch meine alten Clients migriert.
Doku ist hier:
LG
Holger
Hallo,
Da habe ich mir ehrlich gesagt gar keine Gedanken dazu gemacht 
Ich bin gestern einfach hingegangen, hab das linuxmuster-linuxclient7-Paket installiert* (dabei wurde das adsso-Paket deinstalliert/ersetzt) und dann einmal linuxmuster-linuxclient7 setup und anschließend linuxmuster-linuxclient7 prepare-image, dann beim Neustart direkt das Image gezogen → funktioniert 
(* dazu einfach das Repository hinzufügen, s. https://docs.linuxmuster.net/de/latest/clients/linux-clients/linux-client-current-method.html)
Was sollte man sonst noch migrieren müssen? 
Vielen Dank soweit mal, jetzt können die Lehrer wieder an die Computer 
.
Eine kleine Frage hätte ich allerdings noch: das neue Skript lädt jetzt automatisch auch die GPOs und mounted die Netzlaufwerke nach /home/USER/media. Wo kann man die Netzlaufwerke komplett deaktivieren? Muss ich da über einen Windows-Client in die AD-GPOs rein oder geht das auch irgendwie einfacher? („einfacher“, weil wir aktuell keinen Windows-Client mehr haben…)
Hintergrund ist der, dass wir ausschließlich unsere (extern gehostete) Nextcloud nutzen und diese schon automatisch mounten lassen. Dort haben wir auch Tausch-Ordner, die sich automatisch mit dem LDAP synchronisieren. Wenn da dann zwei Orte angezeigt werden, dann weiß ich schon, dass einige meiner Kollegen (und Schüler) Probleme haben, bzw. das was sie in der Schule abgespeichert haben zu Hause nicht mehr in ihrer Nextcloud finden 
Viele Grüße
Alex
Hallo Alex,
schau dir den Tread an, da steht es wie man die Laufwerke abschaltet:
LG
Holger
Hallo miteinander,
sieht der Fehler zufällig so aus oder bin ich auf ein anderes Problem gestoßen?
Wenn ich bei unserem Musterclient
prepare-image ausführe und direkt danach ein Update mache, kann ich mich danach zwar als normaler Nutzer anmelden, aber dann kommt diese Fehlermeldung und ich hab keinen Zugriff auf die Home-Verzeichnisse.Melde ich mich aber als linuxadmin an, meldet
linuxmuster-linuxclient7 status, dass mit der Domäne alles in Ordnung sei.
Werde das Cloop (mal wieder) zurücksetzen…
Liebe Grüße,
Wolfgang
Hallo Wolfgang,
diese Fahlermeldung kommt nicht vom linuxclient7. Was für Dateien befinden sich in /etc/profile.d?
VG, Dorian
So, zu früh gefreut: 2 Tage hat’s problemlos funktioniert auf allen PCs, jetzt seit heute wieder ohne dass wir irgendwas verändert haben wieder das selbe Problem 
Wie kann es bitte sein, dass es urplötzlich nach 2 Tagen wieder nicht funktioniert? Wo ist da der Fehler? Zumal auf ca. der Hälfte der PCs funktioniert es noch, auf der anderen Hälfte nicht mehr…
Wieder selbe Fehlermeldung:
failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed
Wir haben in der Zwischenzeit kein neues Image gemacht…
Jemand eine Idee??
Grüße
Alex
Hallo Alex,
Verwendest du ein besonderes Zertifikat mit Samba ?
Man kann es mit grep tls /etc/samba/smb.conf sehen.
Gruß
Arnaud
Hallo Alex,
wie oft wurde den schon auf die Systemzeit hingewiesen und ihre Differenz zu der des Servers?
Mich wundert, dass in deinem Post nicht drin steht: „An der Systemzeit kann es nicht liegen: die habe ich geprüft“
Deswegen bleibt mir nur die Bemerkung: wie steht es den mit der Systemzeit?
LG
Holger
Hallo Holger!
Nur dreimal und zwar in deinem Post. Bevor ich den gelesen hatte, kam mir der gleiche Gedanke.
Ich überlege ob wir nicht irgendwie eine Standard-Antwort setzen können.
Beste Grüße
Thorsten
Hallo Holger,
Serverzeit und Cleintzeit haben eine Differenz von 0 Sekunden…
daran kann es also nicht liegen.
Viele Grüße
Alex
Hallo Arnaud,
nein, alles Standard:
tls enabled = yes
tls keyfile = /etc/linuxmuster/ssl/server.key.pem
tls certfile = /etc/linuxmuster/ssl/server.cert.pem
tls cafile = /etc/linuxmuster/ssl/cacert.pem
tls verify peer = ca_and_name
Grüße
Alex
Hallo Alex,
ohne, dass ich eine Lösung hätte … aber mich beruhigt Deine Fehlerbeschreibung, denn sie zeigt mir, dass ich mit dem Problem nicht alleine bin!!! Wir haben das Problem ja auch und helfen uns zur Zeit so, dass alle Clients immer synchronisiert starten. Dadurch „verlieren“ wir zwar eine Minute oder so beim Systemstart – dafür funktioniert die Anmeldung überall. Damit können die Kollegen immerhin arbeiten; auch wenn der Systemstart langsamer läuft als bisher.
Warum es vorher immer und immer wieder zu dem gleichen Phänomen kam, konnte ich nicht ermitteln. Die Zeit war bei uns jedenfalls ebenfalls synchron – zudem hatte ich extra noch ein zusätzliches „ntpdate -s 10.16.1.1“ eingebaut, um das auch wirklich vor der Anmeldung zu garantieren… geholfen hat es aber nichts! Daher gehe ich auch davon aus, dass das Problem tiefer liegt … nur wo?
Viele Grüße,
Michael
Hallo Michael!
Nur ein Schuss ins Blaue:
Was sagt ein:
timedatectl statusBeste Grüße
Thorsten
Hallo Thorsten,
bei mir folgendes:
Local Time: Fr 2021-09-17 16:25:18 CEST
Universal Time: Fr 2021-09-17 14:25:18 UTC
RTC Time: Fr 2021-09-17 14:25:18
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTZ in local TZ: no
sieht in meinen Augen alles normal aus.
das beruhigt mich ebenfalls, dass auch andere das selbe Problem haben
interessant finde ich, dass das funktioniert… Was bei der Synchronisation verursacht, dass dann die Domänenanmeldung wieder funktioniert?? Interessanterweise funktioniert es dann aber auch wieder nicht nur beim nächsten Start, sondern wieder einige Zeit (wie lange genau kann ich nicht sagen, hab’s auf einem Computer ausprobiert und mehrfach unsynchronisiert neu gestartet, da hat’s dann funktioniert)
D.h. die Frage ist doch: Wann wird die Domänenanbindung von einem PC zerstört und durch was? Und wie kann man das unterbinden, so dass die Anmeldung dauerhaft funktioniert?
Permanent synchronisiert zu starten ist keine gute Lösung, zumal wir einige Laptops mit recht langsamer SSD haben, hier dauert eine Synchronisierung ca. 3 Minuten, das würde ich gerne vermeiden… Zumal wir bisher das System auch immer direkt aus GRUB gestartet haben, ohne Umweg über LINBO, damit waren unsere PCs in ca. 30 Sekunden einsatzbereit. Mit Umweg über LINBO und einer Synchronisierung liegen wir hier im Bereich von ca. 5 Minuten und das ist in meinen Augen alles andere als gut…
Vielleicht finden wir ja noch, wo genau der Fehler liegt. Ich gebe die Hoffnung noch nicht auf 
Danke und Grüße
Alex
Hallo Alex,
und was ein:
dpkg -l | grep ntpBeste Grüße
Thorsten
Hallo Alex!
Das, was du beschreibst, ist exakt das, was ich auch alles versucht habe … und an exakt den gleichen Stellen habe ich mir auch schon jede Menge Frust geholt …
Bisher war bei mir ja die Vermutung, dass es „irgendwie“ (?) mit dem verwendeten LE-Zertifikat zusammenhängen könnte – habt ihr intern wie extern den gleichen FQDN und nutzt ihr ein LE-Cert auf dem v7-Server?
Wenn nicht, muss der Grund für die Anmeldeschwierigkeiten noch woanders liegen …
Auch ich hatte erst heute wieder einen Client, der unsynchronisiert gestartet ist: Anmeldung möglich (da ich schon mal angemeldet war) aber keine Shares – danach neu Synchronisiert: Anmeldung + Shares ok … es ist also das gleiche Problem wie bei Dir!
Im Computerraum war es so, dass man überhaupt nicht vorhersagen konnte, welcher Client am nächsten Tag noch laufen würde und welcher nicht … ein paar Kollegen habe ich dann zunächst gezeigt, wie sie einen synchronisierten Start manuell erzwingen. Das war aber derartig nervig und kostete unter’m Strich noch mehr Zeit, dass wir es auf den „Starte immer synchronisiert!“-Modus umgestellt haben. Wir haben in den Clients überall SSDs – es dauert aber dennoch etwas länger als ein unsynchronisierter Start…
Viele Grüße,
Michael
Hi,
Ich hatte grade eine neue Idee woran es es liegen könnte:
An der Kerberos Schlüsselrotation. Das hätte genau diese Symptome. Eigentlich sollte sie abgeschaltet sein, aber wenn sie aus irgendeinem Grund an ist, dann würde genau das passieren was ihr beschreibt.
„Umgehen“ ließe sich das in der Theorie, wenn ihr direkt über Grub startet, also ohne Linbo und ohne Sync. Könnt ihr das bitte mal testen?
VG, Dorian