bionic-Client: adsso.conf, Icons und verschlüsselte Verbindung mit Zertifkat

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?

Grüße
Michael

Hallo,

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.

warum schreibt ihr dann den Server mit seiner internen IP nicht in die
/etc/hosts auf dem Client?

LG

Holger

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“! :wink:

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?

Viele Grüße,
Michael

Hej,

Ja, geteiltes Leid ist halbes Leid. :handshake:

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… :cold_sweat:

Grüße
Michael

Hallo, OK das sind doch gleich zwei wichtige Infos:

  • Das s bei der LDAP Verbindung ist scheinbar ein Problem, wenn man ein gültiges Zertifikat auf dem Server einsetzt.

  • Du hast im Gegensatz zu mir ein Ticket mit richtiger Uhrzeit beim Erstlogin.

Kannst du Deine vollständige smb.conf hier posten? Vielleicht gibt es ja doch einen markanten Unterschied??

Viele Grüße
Michael

Hej, na klaro:

root@server:/etc/samba# cat smb.conf
# /etc/samba/smb.conf.setup
#
# Don't edit this file!!!
# Add your stuff in /etc/samba/smb.conf.admin.
#
# thomas@linuxmuster.net
# 20200818
#

[global]
workgroup = #MEINE-SCHULE#
realm = #MEINE-SCHULE.DE#
netbios name = SERVER
server role = active directory domain controller
dns forwarder = 10.16.1.254  # Das ist bei uns die OpnSense
registry shares = yes
host msdfs = yes
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
ldap server require strong auth = no
rpc_server:spoolss = external
rpc_daemon:spoolssd = fork
spoolss:architecture = Windows x64
printing = cups
printcap name = cups
time server = yes
ntp signd socket directory = /run/samba/ntp_signd

[netlogon]
path = /var/lib/samba/sysvol/csg-tuebingen.de/scripts
read only = No
acl allow execute always = yes

[sysvol]
path = /var/lib/samba/sysvol
read only = No

[printers]
browseable = No
path = /var/spool/samba
printable = Yes
read only = No

[print$]
path = /var/lib/samba/printers
read only = No

# including custom admin stuff
include = /etc/samba/smb.conf.admin

Die drei Zeilen mit den Standard-Zertifikaten werden durch die /etc/samba/smb.conf.admin überschrieben.

root@server:/etc/samba# cat smb.conf.admin 
# modified by linuxmuster-setup at 20200722190310
# /etc/samba/smb.conf.admin
#
# thomas@linuxmuster.net
# 20180713
#
# add here your custom admin stuff
#
[global]
tls keyfile = /etc/linuxmuster/ssl/server.le.privkey.pem
tls certfile = /etc/linuxmuster/ssl/server.le.fullchain.pem
tls cafile = /etc/linuxmuster/ssl/server.le.chain.pem

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

Hej,

Ich habe leider keine Ahnung. Ich weiß noch nicht mal, warum das seit um Weihnachten herum plötzlich auftrat.

Grüße
Michael

Hallo Michael,

als das LE Zertifikat erneuert wurde, blieben da die richtigen Zugriffsrechte erhalten?

Viele Grüße
Christian

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?

Viele Grüße,
Michael

Hej Michael,

That rings a bell.
Wir hatten das schonmal: Linuxmuster-client-adsso funktioniert nicht (mehr) - #5 von foer

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? :face_with_raised_eyebrow:

Wenn ich es richtig verstanden habe, wird über linuxmuster-client-adsso-setup die Datei A auf den Client gebracht. So hat es jedenfalls @foer hier erklärt.

Das wäre aber maximal nervig, weil man ja nach dem adsso-setup-script jeweils ein neues Image schreiben müsste :unamused:

Wer weiß denn hierzu mehr?
Und wie kann man das so automatisieren, dass uns das nicht regelmäßig um die Ohren fliegt?

Danke für eure Hilfe und Grüße
Michael

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 :slight_smile:
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…

Viele Grüße,
Michael

Hallo,

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

  1. eine echte Domain intern benutzt
  2. 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?

LG

Holger

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 :slight_smile: … mal sehen, wann ich dazu komme.
Viele Grüße,
Michael

Hallo 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 :

ldbsearch -k yes -H ldaps://DOMAIN "(&(samaccountname=USER))"
ldbsearch --krb5-ccache=/tmp/krb5cc_TICKETHASH -H ldaps://DOMAIN "(&(samaccountname=USER))"

Vielleicht hilft es.

Gruß

Arnaud

Hej Arnaud,

Yes! Einen Schritt weiter…

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.

ldbsearch -k yes -H ldaps://DOMAIN "(&(samaccountname=USER))"

Genau auf der Spur war ich im Moment auch. Hatte die Fehlermeldung vorhin bei Login-Skript schon /etc/linuxmuster-client/scripts/login.sh gesehen.

ldbsearch --krb5-ccache=/tmp/krb5cc_TICKETHASH -H ldaps://DOMAIN "(&(samaccountname=USER))"

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…

Hast Du da einen Lösungsansatz?
Grüße
Michael

Hallo Michael,

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 :

  ticket=$(ls /tmp/krb5cc_$(id -u $USER)*)
  ldbsearch --krb5-ccache=$ticket -H ldaps://$servername.$ad_domain "(&(samaccountname=$USER))" | tee "$tmpuserinfo"

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.

Gruß

Arnaud

2 „Gefällt mir“

Hi. Nochmal als Erinnerung:

Also ich erhalte hier auf dem Focal Fossa Client auch weiterhin:

meinlogin@vm-fossa:$ ldbsearch --krb5-ccache=/tmp/krb5cc_1084201206_dUBkmI  -H ldaps://server.meine-domain.de:636 "(&(samaccountname=meinlogin))"
Failed to connect to ldap URL 'ldaps://server.meine-domain.de:636' - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to 'ldaps://server.meine-domain.de:636' with backend 'ldaps': LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to ldaps://server.meine-domain.de:636 - LDAP client internal error: NT_STATUS_INVALID_PARAMETER

Das Ticket existiert!

Hallo Michael,

Port 636 ?
Mein Linuxclient läuft auch unter Focal Fossa, Updatet am Samstag.

Gruß

Arnaud