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
Hallo Dorian!
Das ist doch ungefähr das gleiche wie damals zu v6.x Zeiten, als man den Win-Clients beibringen musste, dass von nun an 12345678 das Maschinen Passwort ist und dass dieses auch nicht mehr geändert werden darf, richtig?
Wie kann man denn (evtl in den Samba-Settings?) prüfen, ob das der Fall ist? Und falls Du Recht hast (was ich sehr hoffe): warum sind dann nicht alle davon betroffen?
Viele Grüße
Michael
Hallo Dorian,
daran dachte ich Heute Mittag auch.
@Michael: genau, wie bei Windowsclients die nicht den Regpatch mit der Anweisung: „kein neues Passwort mit dem Domänencontroller aushandeln“ eingespielt hatten.
Allerdings denke ich, dass das nicht geht:
denn genau das ist es ja, was Alex gemacht hat.
Dass die Anmeldung nach einem sync wieder geht, kann ich erklären: Cleint (durch den Sync) und Server (durch den durch den sync angestoßenen Prozess auf dem server, der das Maschinenpasswort aus der macct Datei in den AD schreibt) haben wieder das selbe Maschinenpasswort.
Das ist das eine Ende.
Das andere ist aber nicht so einfach.
Was Dorian meint:
wenn der Client ein neues Passwort aushandelt, dann wissen das Client und server solange, bis linbo mal gestartet wurde: das geht nicht, wie Alex ja getestet hat, weil er immer über grub an linbo vorbei bootet.
Also warum handelt der Client ein neues Passwort aus und dann geht das garnicht? …
Also: es ist eine Richtung zum Nachdenken: „sehen“ kann ich da noch nicht klar.
Vielelciht helfen euch ja meine Gedanken dabei 
LG
Holger
Hi Holger,
Danke, gut erklärt 
Ich hatte Alex so verstanden, dass er direkt über Grub booten möchte, es aber noch nicht macht.
Oder hab ich das falsch verstanden? @dsjiern
@Michael und Alex:
Es gibt einen Befehl mit dem man sich den Schlüssel anzeigen lassen kann klist -k mit noch einem Argument glaube ich. Das sollte den Schlüssel als Hex ausspucken. Den kannst du dann auf einem frisch gesyncten Client wegspeichern und später mit einem nicht funktionierenden Client vergleichen. Sind sie unterschriedlich, liegt es daran. (Zwischendrin natürlich kein neues Image erstellen)
VG, Dorian
Hallo @alle
da ist nichts installiert auf den Clients. (Allerdings wird doch die Zeit auch von Linbo schon gesynct?)
puh, irgendwie bin ich froh, dass ich nicht der einzige mit dem Problem bin. Jetzt müssen wir „nur“ noch herausfinden, was wir beide im System haben, was in allen anderen Schulen nicht ist
ja, haben wir genauso! Wobei das LE-Zertifikat nur für die Schulkonsole und für unseren UniFi-Controller eingerichtet ist und mit Samba eigentlich nichts zu tun haben sollte…
das kann ich nicht beurteilen, da wir generell keine Shares nutzen.
Wir auch, aber unsere neuesten Laptops (die in jedem Raum stehen) haben die langsamsten SSDs verbaut…
Jein. Aktuell booten wir wieder durch Linbo hindurch, weil sonst bei einigen Laptops der Kartenleser als sda eingebunden wird und dann natürlich das System darauf nicht gefunden wird. (Hatte dazu schonmal einen anderen Thread). Deswegen haben wir das umgestellt auf Linbo-Boot, dort wird zuverlässig die SSD als sda und der Kartenleser als sdb eingebunden. Warum das unterschiedlich ist: keine Ahnung…
Allerdings hatten wir das im letzten Schuljahr permanent über Grub (alte Linbo-Version, da wurde die SSD immer als sda erkannt) und hatten auch da hin und wieder Probleme!
Zum zeitlichen Ablauf: wir hatten in den letzten Sommerferien (=Anfang August) den Server komplett mit v7 neu installiert. Etwa 3 Monate später Mitte Oktober gab es das Problem dann zum ersten Mal (damals auf jeden Fall Grub-Boot). Damals hab ich einfach ein neues Image gemacht und dann hat’s wieder für ca. 3 Monate funktioniert bis ca. Januar. Und ab da sind die Zeiträume immer kürzer geworden! Zwischendurch mal nach 2-3 Wochen, inzwischen sind’s nur wenige Tage…
Vielleicht auch das noch ein Ansatz: Ich hatte zwischendurch auch versucht, bei jedem Boot die Laptops rejoinen zu lassen. Dazu hatte ich ein Skript geschrieben, was die Domänenaufnahme nach dem Booten automatisch gemacht hat (nicht über den linuxmuster-Befehl, sondern manuell über adcli, da nach dem linuxmuster-Befehl ein Neustart nötig gewesen wäre) Das hat soweit aber auch nur teilweise funktioniert, teilweise konnten sich die Clients trotzdem nicht zur Domäne verbinden…
Interessanterweise funktioniert es aber auch, wenn ich Linbo offline starte und dann synchronisiere! Also da kann auf dem Server ja definitiv nichts geändert werden.
Ja, siehe oben. Aktuell nicht, aber hatten wir im letzten Schuljahr. Und dort hatten wir die Probleme ebenfalls schon.
klist -k -t -K ist’s. Das werde ich jetzt mal beobachten, danke für den Tipp.
Danke und Grüße
Alex
Grad noch getestet (bin per SSH in der Schule um diese Uhrzeit ) Ein Laptop, heute Mittag neu synchronisiert, hat funktioniert. klist -k -t -K hat die Schlüssel ausgespuckt (das hintere sind doch die Schlüssel, oder?)
klist -A hat folgendes angezeigt:
Da dachte ich, ob es evtl. was mit dem „Expires“-Eintrag zu tun hat. Hab dann den Laptop neu starten lassen (eben durch Linbo hindurch) → danach keine Anmeldung mehr möglich! (Und auch schon vor dem angegebenen expires-Zeitpunkt um 1:14 Uhr)
klist -k -t -K zeigt jedoch noch die exakt identischen Werte an!
Grüße
Alex
Hallo Alex, wow – Arbeit bis spät in die Nacht 
Wenn ich das richtig sehe, ist die Möglichkeit, dass es am LE Zertifikat liegt, weiterhin nicht ganz ausgeräumt?
Habt ihr evtl auch den freeRadius-Dienst auf dem v7 installiert? (Nur um alle Gemeinsamkeiten herauszufinden)
Unter dem Stichwort „Samba Kerberos Key Rotation“ habe ich bisher nur dies gefunden – aber ob das hilfreich ist… 
Samba Security Documentation - SambaWiki und dort nach „Rotation“ suchen.
Ich hoffe, dass wir die Ursache dieses Problems noch gemeinsam ermitteln können.
Viele Grüße
Michael
@dsjiern kannst du bitte nochmal einen client ohne Netz frisch syncen und dann sofort nochmal die Schlüssel anschauen?
Vielleicht hat sich der Schlüssel bei deinem Test von gestern schon vor dem Neustart geändert gehabt. Ich weiß leider nicht, wie schnell/oft das passiert - wenn es denn passiert …
VG, Dorian
Hallo Alex!
Das ist schon mal gut! Dann eine letzte Frage, besser eine Bitte, poste doch mal folgende Datei:
/etc/systemd/timesyncd.confBeste Grüße
Thorsten
Hallo Dorian,
Aber warum konnte ich mich dann VOR dem Neustart noch anmelden (nein, es war kein Nutzer aus dem Cache!)
ohne Netz kann ich nur, wenn ich physisch vor Ort bin. Hab aber grad per SSH schnell den selben Laptop wie gestern Abend neu online syncen lassen, da haben sich die Keys auf jeden Fall geändert!
Aber das LE-Zertifikat sollte doch rein gar nichts mit dem Samba zu tun haben?
Volltreffer Ich kann ja mal auflisten, was mir aktuell einfällt und wir sonst noch verändert haben:
- keine Firewall, dafür nutzen wir ein UniFi-Security Gateway
- deswegen gibt es auch keinen Proxy, wurde in den letzten ~15 Jahren nie gebraucht und wenn immer mehr Schüler private iPads haben werden die Einsatzmöglichkeiten auch immer weniger
- kein Docker-Host (wir nutzen für Nextcloud, Moodle,… einen bei Hetzner angemieteten Server)
- Privatgeräte werden über Radius in verschiedene VLANs gepackt, davon bekommt der Server aber eigentlich auch (außer der Authentifizierung über freeradius) nix mit, DHCP und alles andere läuft dann direkt über UniFi.
- DHCP für’s Schulnetz wollten wir ursprünglich auch über UniFi machen, das hat aber wegen PXE nicht funktioniert (bzw. war mir zu aufwändig, die ganzen Parameter dort einzurichten) deshalb läuft das DHCP der Schulgeräte über den Server (aber da wurde nix verstellt)
Aber meines Erachtens dürfte das alles keine Auswirkung haben auf die Domäne.
[Time]
NTP=10.16.1.1
(Kommentarzeilen hab ich entfernt)
Vielleicht noch ein ganz anderer Ansatz: Kann es vielleicht sein, dass irgendein anderer Client im Netz versucht, sich neu zu joinen und dadurch alle anderen Clients aus der Domäne geworfen werden? (Wobei ich mich dann frage, warum ein einfacher Sync wieder hilft…)
Grüße und schänes Wochenende
Alex
Also bei der Einrichtung des freeRadius-Dienstes mussten meines Wissens alte Protokolle reaktiviert werden… Wer weiß?!? Ich sehe es eigentlich auch so, dass das nichts mit Samba/AD zu tun haben sollte… Aber irgendwas haben wir offensichtlich anders gemacht als alle anderen …
Habt ihr migriert oder neu installiert?
Hallo Alex,
meine lmn7 ist auch migriert (Sommer 2019) und ich habe auch den freeradius auf dem Server laufen.
Ich habe kein LE Cert auf dem Server und verwende den linuxmuster-client-adsso Client auf meinen Möhren: da ist in den 2 Jahren kein einziger aus der Domäne gefallen (ca. 150 Linuxclients).
Das mit dem „der Join eines anderen Clients hat die Probleme bewirkt“ halt ich für interessant: es könnte die Chaotik erklären … und dass es nach einem sync wieder geht.
LG
Holger
Ha! Dann ist es das auf jeden Fall!!
Alles Symptome passen. Ist mir grad ein bisschen zu kompliziert um es zu erklären, aber das ist es zu 99%
Dann müssen wir jetzt nur noch rausbekommen, wie man es abschaltet …
Ich hab schon ein paar Ideen für Hacks, aber bin ja noch im Urlaub, kann also nicht testen.
Dann könnt ihr erstmal aufhören nach anderen Ursachen zu suchen!!
VG, Dorian
1 „Gefällt mir“
Da bin ich aber happy, dass es das vermutlich ist.
Das – und warum es offenbar nicht bei jedem auftritt
Ich vermute mal, dass das daran liegt, dass viele (@baumhof soweit ich weiß zum Beispiel) ihre Clients automatisch jede Nacht synchronisieren.
Und Andere (ich zum Beispiel) haben Sync als default.
VG, Dorian
Hallo Dorian,
in dem Ordner befindet sich (vor dem Update):
- 01-locale-fix.sh
- 99-linuxmuster-linuxclient7.sh
- apps-bin-path.sh
- bash_completion.sh
- cedilla-portuguese.sh
- gawk.csh
- gawk.sh
- im-config_wayland.sh
- linuxmuster-proxy.sh
- vte.csh
- vte-2.91.sh
- xdg_dirs_desktop_session.sh
Falls noch weitere Informationen brauchst, gib einfach Bescheid!
Liebe Grüße,
Wolfgang