Hallo Michael,
Das ist eine komplizierte Frage, da die Kommunikation zwischen Samba und Kerberos nicht besonders dokumentiert sind.
Nur um etwas zu überprüfen, kannst du bitte testen mit einem Login der nicht funktioniert, was das folgende ergibt ?
KRB5_TRACE=/dev/stdout kinit LOGIN
Gruß
Arnaud
Ich schicke es Dir per PM,ok? Da steht zuviel Zeug drin, was ich lieber nicht veröffentlichen will…
Yep, ich schaue mal an.
Arnaud hat reingeschaut – daran lag es offenbar nicht.
Du hast doch ein LE-Zertifikat. Kann es sein, dass es immer nach einer Erneureung Probleme gibt?
VG, Dorian
Hi Dorian!
Jawollllll – das Zertifikat wurde tatsächlich heute erneuert – und ja, da gab es ein paar Effekte, wie z.B, dass die Nextcloud angeblich plötzlich kein gültiges Zertifikat mehr hatte, obwohl es ja gerade erneuert wurde.
Der Server hatte ebenfalls Probleme, obwohl es erneuert wurde. Wenn hier der Zusammenhang steckt, müssten die entsprechenden Webserver (apache2 für die NC bzw ajenti für die WebUI) vermutlich eher neu starten als sie es jetzt tun!??
Viele Grüße,
Michael
Hallo Michael,
Klar.
Gruß
Arnaud
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?!?