Ok, ich bin allerdings nicht sicher, ob damit sämtliche Anmeldeprobleme gelöst sind, denn zuvor ist das auch schon an unterschiedlichen Tagen aufgetaucht, an denen keine Erneuerung der Zertifikate anstand … aber immerhin ist es evtl ein Anhaltspunkt, warum gerade hier ein Problem steckt?!?
Kann ich ri nicht genau sagen, aber die ganze Kommunikation zwoschen Kerberos und dem Samba ist zimlich komplex. Die mag es scheinbar einfach nich, wenn sich da plötzlich das Zertifikat ändert.
Ich glaube, mit einer internen CA für das AD macht man sich sehr, sehr vieles leichter…
VG, Dorian
Hallo Dorian,
Es geht aber nicht mehr, da einige externe Dienste ein gültiges Zertifikat brauchen.
Gruß
Arnaud
Hallo,
über das letzte Jahr hat Michael andauernd sehr seltsame Probleme: oftmals nur er und sonst niemand.
Schon oft haben wir vermutet, dass das mit dem LE Zertifikat für die AD zusammen hängt.
Für mich war schon vor Monaten der Punkt erreicht wo ich dachte: blos nicht den AD mit einem „echten“ Zertifikat betreiben.
Vor allem auch das wählen einer echten Domain für den AD scheint keine gute Idee zu sein: selbst MS empfiehlt genau das nicht zu tun, sondern dem AD eine subdomain der eigenen zu verpassen.
Das bringt mich nun aber in eine Zwickmühle, da auch ich einen Dienst habe, der einen AD mit echtem Zertifikat benötigt. Bei mir ist das bisher nur die PeerTube. Webuntis habe ich glücklicherweise nicht.
Aber ich muss raus aus dem Dilemma, und da tut sich in meinen Augen bisher nur ein Weg auf: der in den letzten Wochen hier beschriebene Weg des LDAP Proxys: einer Maschine, die die externen LDAP Anfragen annimmt und beim AD fragt, ob das OK ist. So bekommen die externen Dienste zertifizierte Aussagen, ohne dass ich am AD rumschrabbeln muss.
Das wird also mein Weg sein.
LG
Holger
Genau das ist der Weg, den ich auch gehen und empfehlen würde.
VG, Dorian
Hallo Jungs,
dann schreibt das bitte somit, damit wir das in der Doku genauso beschreiben können.
Unformatierter Text reicht eventuell mit Screenshots. Danke allen die das um/einsetzen.
Nachtrag: LDAP -> LDAPS Proxy
beschreibt es ja schon. Aber einwenig detaillierter dürfte es schon sein. Ich habe den Post in ein Wiki verwandelt. Also kann jeder seine Erfahrungen direkt in den Post einfließen lassen.
Beste Grüße
Thorsten
ich habe ja gar kein lmn 
deshalb ein neuer Post, @MachtDochNix . Aber Ergänzungen sind trotzdem willkommen.
Hallo hmt,
verstehe ich dich jetzt richtig, es wäre besser einen neuen Post zu nehmen für den Erfahrungsaustausch/Dokumentation-Sammlung?
LG
Thorsten
Nein, mein ldap-ldaps Post war allgemeiner Natur, gerne als Ergänzung zu diesem hier, aber unabhängig von einem bestimmten Server. Aber passt schon. Wer es sucht, wird es finden. Für mich ist dieses Forum auch die reinste Fundgrube geworden.
Hi Holger
Ja, das sehe ich mittlerweile genauso – leider war mir das aber zum Zeitpunkt der Installation 2019 nicht bekannt oder genauer gesagt war es damals sogar so, dass es genau umgekehrt empfohlen wurde. Sonst wäre ich natürlich gar nicht auf die Idee gekommen, intern den gleichen FQDN zu nehmen wie extern. Jetzt ist es leider zu spät, um nochmal von vorne zu beginnen.
Allerdings ist das Zertifikat auf dem Server seit gestern neu – es wurde mir heute aber berichtet, dass im Computerraum (der zwischendurch immer komplett ausgeschaltet war!) die Anmeldung NUR dann funktionierte, nachdem man JEDES Mal Sync+Start gewählt hat. Ohne ging es weiterhin nicht. Daher schließe ich das neue Zertifikat nun eigentlich doch wieder aus … da muss noch etwas anderes hinterstecken.
Das seltsame ist weiterhin, dass es unter Windows jedes Mal klappt und nur der Fossa-Client das Problem hat. Dual-Boot kann es weiterhin sein; da kann ich nicht sicher sagen, ob es zwischendurch einen Wechsel Linux ↔ Win10 ↔ Linux gab. Doch da wir Linux im Autostart mit 3 Sekunden haben, ist die Warscheinlichkeit, dass die Kollegen Win10 booten eher gering.
Daher müssen wir vermutlich entweder auf „Sync + Start per default“ wechseln oder aber die wirkliche Ursache bald finden …
Viele Grüße,
Michael
Das Problem ist, dass du keinen Weg nennen kannst, wie man das reproduzieren kann.
So ist es sehr schwer, das Problem einzugrenzen …
Was ich mir noch vorstellen könnte ist ein Problem mit dem patchen der Keytab Datei. Um das zu prüfen kannst du mal auf einem „kaputten“ client als Linuxadmin klist -k ausführen und die Ausgabe posten.
VG, Dorian
Hi. Ich würde ja liebend gerne etwas posten, was das Problem eingrenzt … ich finde die Situation auch nicht glücklich…
Die Ausgabe klist hatte ich Dir zwar schon mal geschickt … aber ich poste sofort noch eine per PM.
Bei unserer VM, die eigentlich als Vorlage für die Computerräume dient, tritt das Problem erstmals auch auf, so dass die Anmeldung da zur Zeit zwar funktioniert aber keine Shares liefert.
Nachtrag: Gerade nochmal einen re-join gemacht, dann mit prepare ein neues Image vorbereitet und direkt hochgeladen (so wie es vorgesehen ist). Im Moment läuft die Anmeldung wieder … mal sehen wie lange?!?
Hallo Michael,
ich hab es schon 100mal gesagt, aber vielleich ist es vergessen worden: achtest du auf die Systemzeit?
Ist dir bewußt, dass du beim DualBoot zwingend Windwos beibringen mußt nicht localtime in die RTC zu schreiben sondern UTC?
Seit ich auf diese beiden Dinge achte funktioniert die Anmeldung bei mir immer: auch beim DualBoot, und das seit über einem Jahr…
LG
Holger
Hi Holger,
ja, ist mir bewusst und das ist es nicht – leider.
Hallo!
Wenn ich ein Image habe (Danke Holger, Deines hat mir viele Stunden erspart), das ich verschlimmbessere und ein neues erstelle, danach aber wieder auf das alte zurück möchte:
früher konnte man einfach alle .cloop-Dateien umbenennen, bittorrent neu starten und gut wars.
Ist das immer noch so? Ich habe aktuell Probleme mit den Mounts, die schlagen alle fehl trotz dass der login klappt, weiß aber nicht, ob es daran liegt.
Danke für Tipps
LG
Max
Hallo Max,
ja, das geht so noch immer.
Und wegen des Mounterrors: schau mal hier:
Einfach die Drives.xml korrigieren…
LG
Holger
Hallo Holger,
bevor man das Image erstellt, habe ich das bisher immer mit bleachbit geputzt…im neuen Linuxclient, scheint bleachbit hier etwas zu viel zu löschen - zumindest ging danach die Anmeldung nicht mehr. Gehe ich richtig in der Annahme, dass der Befehl linuxmuster-linuxclient7 prepare-image das im Großen und Ganzen übernimmt?
Gruß
Daniel
Hallo Daniel,
ja, das macht ähnliches.
Ich verwende auch schon viele Jahre bleachbit und das mache ich auch aktuell noch.
Bei mir funktioniert es.
Ich lasse es als root und als linuxadmin laufen.
Die Defaulteinstellungen habe ichnicht geändert.
LG
Holger
Ok, dann habe ich wohl irgendeinen Haken gesetzt, den ich nicht setzen sollte.