Hallo Michael,
zunächst mal vielen herzlichen Dank, dass Du das Problem mit den fehlenden Homes hier formuliert und dann auch selbst einen Workaround gefunden hast.
Wir haben gestern festgestellt, dass das Problem auch bei uns so aufgetreten ist - wegen Lockdown ist das seit Weihnachten nur niemandem aufgefallen.
Wir waren der Ursache soweit auf der Spur (hatten den Fehler bei der LDAP-Verbindung im 00_userinfo.sh Skript entdeckt) und sind dann auf diesen Thread gestoßen. Wir waren überglücklich, dass Du schon den Workaround hattest.
Aber gelöst ist das Problem damit ja nicht. Uns würde auch interessieren, warum die ldaps-Verbindung via ldbsearch-Befehl nicht funktioniert.
Deine Vermutung, dass es daran liegt, dass dein server intern wie extern den gleichen FQDN benutzt, könnte stimmen. Das ist bei uns auch so.
Und auch in unserer smb.conf steht ldap server require strong auth = no und das obwohl der erst im Sommer 2020 aufgesetzt wurde - wo das ja schon lange Standard gewesen sein müsste. Was ist dabei eigentlich Sache? @Michael : Hast Du das geändert? Hat das irgendwelche negativen Nebeneffekte?
Hi.
Zunächst mal: Ich bin immer etwas „erleichtert“, wenn andere das gleiche Problem haben – dann steigt die Chance, dass es ein Bug ist und er eines Tages behoben wird. Dass Du nun also auch über die fehlende Home_auf_Server-Verknüpfung gestolpert bist, „freut mich“!
Holger: Intern funktioniert die Namensauflösung problemlos.
Michael: Hast du auch diesen Thread entdeckt & mitverfolgt:
Ich weiß mittlerweile, dass fehlende Home_auf_Server bzw Tausch_auf_Server Icons mehrere Ursachen haben können: Das Anmeldescript muss natürlich vernünftig durchlaufen – aber auch die Sache mit Kerberos und den lokalen Systemzeiten muss passen. Da ich bisher immer auf einer VM (Proxmox) getestet habe, unterscheiden sich manche Dinge von realer Hardware (hwclock, Bios-Zeit …).
Was habt ihr denn ausprobiert?
Mir kommt es weiterhin so vor, als sei ldaps im Zusammenhang mit Kerberos überflüssig (wie schon in dem Thread erwähnt). 100%ig sicher bin ich da aber nicht – ich hatte mich da nur auf andere Webseiten berufen, wo das geschrieben steht.
Ich habe den Eintrag ldap server require strong auth = no hier auch – weiß aber nicht, ob das default ist und ob es Auswirkungen auf anderes gibt …
Eine bessere Lösung habe ich leider momentan nicht. Vielleicht liest ja eine @Entwickler mit?
Michael: Hast du auch diesen Thread entdeckt & mitverfolgt:
Bisher nicht. Scheint auch nicht auf die Situation bei uns zu passen. klist zeigt bei uns ein aktuelles Ticket.
Was habt ihr denn ausprobiert?
Nicht viel. Wir haben überprüft, ob die Shares unter /srv/samba/... gemountet sind (waren sie) und haben dann nachgeforscht, was da beim login schief läuft. also /etc/linuxmuster-client/scripts/login.sh ausgeführt und diese Fehlermeldung erhalten:
sed@r118-imagevm:/etc/linuxmuster-client/scripts$ sudo ./login.sh
Executing /etc/linuxmuster-client/login.d/00_userinfo.sh ...
Failed to connect to ldap URL 'ldaps://server.meine-domaene.de' - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to 'ldaps://server.meine-domaene.de' with backend 'ldaps': LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to ldaps://server.meine-domaene.de - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
...
Dann haben wir das Discourse angesurft und deinen Foreneintrag gefunden.
Haben dann das s bei ldaps entfernt und den login.sh nochmal ausgeführt. Nachdem das script so fehlerfrei durchlief und die Shares wieder vorhanden waren, haben wir schnell eine überarbeitete 00_userinfo.sh ins Postsync gelegt und uns dann wieder unserer eigentlichen Aufgabe zugewandt…
Eigentlich waren wir in der Schule, weil letzte Woche endlich unsere Corona-„Sofort“-Hilfe-Notebooks für die SuS angekommen sind…
Hi, ich habe mit kdiff3 verglichen. Einziger relevanter Unterschied dürfte bei mir dieser Eintrag sein, den es bei dir nicht gibt:
#Protokoll geaendert: #ntlm auth = yes < deaktiviert und nur noch eingeschraenkt erlaubt: 02.07.2020
ntlm auth = mschapv2-and-ntlmv2-only
Ich fürchte, dass das ein ziemliches „im Nebel stochern“ bleibt … ?!
Wenn du aber sagst, dass deine User direkt bei der ersten Anmeldung ein gültiges Kerberos-Ticket erhalten, läuft bei Dir ja immerhin dieser Schritt richtig. Bei mir passt das immer erst, wenn ich es manuell anstoße.
Vielleicht sollte ich den Client doch nochmal aus der Domäne entfernen und neu hinzufügen!?
Viele Grüße,
Michael
Hi Christian.
Ich lasse die OPNSense alle LE-Zertifikate verwalten. Die werden dann per Script auf den v7-Server übertragen. Das funktioniert alles seit mindestens einem Jahr fehlerfrei. Wenn ich intern im Browser https://server.meine-domain.de oder auch https://firewall.meine-domain.de aufrufe, habe ich immer ein gültiges Zertifikat. Von daher würde ich sagen: Ja, das passt!
Mittlerweile habe ich gesehen, dass es auf dem v7-Server ein weiteres Zertfikat an dieser Stelle gibt: /var/lib/samba/sysvol/linuxmuster.meine-domain.de/tls/cacert.pem
Das stammt hier von 2019 – wurde also direkt bei der Installation dort abgelegt. Wie es dahin gekommen ist und welche Funktion das dort hat, weiß ich nicht. Erklärt das evtl, warum Leute ohne FQDN keine Probleme haben? Wer kann etwas dazu sagen?
Und das deckt sich mit meiner (und deiner…?) Situation:
Unter /etc/linuxmuster/ssl/ liegen die Let’s-Encrypt-Zertifikatsdateien (insbesondere: server.le.chain.pem (A)). Die Dateien wurden in meinem Fall am 31.12. über einen deploy-hook von certbot dort abgelegt.
Unter /var/lib/samba/sysvol/meine-domaene.de/tls liegt noch das cacert.pem (B) von September.
Eigentlich sollte A = B sein, isses aber nicht.
Kann es sein, dass daran die Einbindung unserer Homes scheitert?
Wenn ich es richtig verstanden habe, wird über linuxmuster-client-adsso-setup die Datei A auf den Client gebracht. So hat es jedenfalls @foerhier erklärt.
Das wäre aber maximal nervig, weil man ja nach dem adsso-setup-script jeweils ein neues Image schreiben müsste
Wer weiß denn hierzu mehr?
Und wie kann man das so automatisieren, dass uns das nicht regelmäßig um die Ohren fliegt?
Hi Michael … ja, das hatten wir alles schon mal. Und wieder bin ich froh, dass ich nicht der einzige bin, der hier im Nebel stochert
Es scheint leider so zu sein, dass das adsso-Paket zZ keinen richtigen Maintainer hat →
Daher müssen wir selbst tiefer graben, bis wir die Stelle finden, wo es klemmt.
Hast du denn schon mal versucht, an der Stelle B einen Symlink zu erzeugen, der immer nach A auf das richtige cert zeigt?
Ich habe hier auch wieder das Problem, dass die Anmeldung an den Linux-Clients mal klappt – und mal nicht.
Eine andere Idee: Auf dem Server befindet sich im LINBO-Verzeichnis die .macct-Datei und auf dem Client die /etc/krb5.keytab. Vielleicht kann ja nochmal jemand erklären, wie diese beiden miteinander zusammenhängen, denn beide sind offenbar notwendig…
suchen wir hier nicht das Problem am falschen Ende?
Ja: der linuxmuster-client hat noch Probleme, aber eure wurden ja nicht durch dieses Problem verursacht, sondern weil ich
eine echte Domain intern benutzt
diese durch ein LE Cert absichert
Würde es nciht reichen dem certbot bei zu bringen bei einem Update A=B wieder her zu stellen durch kopieren der certs zusätzlich an die richtige Stelle?
Hi. Ja, das wäre natürlich schön (und könnte dann ggf auch per postsync erledigt werden?). Es muss „nur“ noch geklärt werden, ob das Problem damit tatsächlich behoben ist … mal sehen, wann ich dazu komme.
Viele Grüße,
Michael
Ich habe jetzt nicht alles gelesen, aber wenn ich richtig verstehe, ein USER kann sich einloggen, aber sieht nicht sein HOME in Home_auf_Server.
Entweder ist es nicht gemountet, oder da fehlt einfach den Link zur mounted device. Um es zu prüfen, einfach mount als eingeloggt USER ausführen und es sollte eine Zeile //DOMAIN/default-school geben.
Wenn diese Zeile nicht auftaucht, es wäre gut auf dem Linuxclient in /var/log/auth.log zu schauen, welche Fehlermeldungen es gibt.
Diese Fehlermeldung liegt nach meiner Meinung ( ich kann mich irren ) nicht am Zertifikat, sondern an die Option -k yes in ldbsearch die nicht unbedingt das richtige Ticket verwendet.
Bei der Anmeldung sucht ldbsearch die USERINFO per LDAP auf dem Server um die Umgebung auf den Linuxclient vorzubereiten.
Jeder USER erhält bei der Anmeldung ein Ticket in /tmp, in der Form /tmp/krb5cc_0123456789_ssfjdjf. Um meine Vermutung zu testen, probier mal as USER aus :
Du irrst dich nicht. Jedenfalls habe ich das Zertifikat auf dem Server ausgetauscht und linuxmuser-client-adsso ausgeführt. Neues Image geschrieben, gesynct und getestet… Hatte auf die Homes bei mir keine Auswirkungen.
Ja, das funktioniert!
Also: Vermutung bestätigt.
Nun ist nur noch die Frage, wie man /etc/linuxmuster-client/login.d/00_userinfo.sh den Weg zum richtigen Ticket zeigt…
Mir fehlt noch den Kontext : sind die Shares jetzt gemoutet und es fehlt nur die Links im Home-Verzeichnis ?
Erst mal soll ich die übliche Warnungen schreiben : das folgende muss getestet und bestätigt sein, Verwendung auf eigene Gefahr.
Das Problem ist, als Root kommt man nicht auf die Environments Var von einem eingeloggt USER, man erhält nur ein Teil davon ( mit z.B. sudo -u USER env ). Und die Login-Skripte sind als Root ausgeführt. Genauso ist es für klist.
Die gewünschte Variabel ist $KBRCCNAME, was den Ticketpfad enthält.
Als schlechte Lösung habe ich es mit ls gesucht … es gibt höchstwahrscheinlich besser dafür :
Vielleicht hat jemand eine bessere Idee. Ich habe es mit 2 Konten ausprobiert, ein in Cache, ein neu angelegt, und die Shares waren da. Aber das soll auf jedem Fall grundsätzlich getesten sein vor es in produktive Umgebung zu werfen.