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

Hallo – ich versuche es nochmal hier im Forum.
Unser bionic-Client (kommt hier aus der Liste) verlinkt auf dem Desktop der User die Shares nicht mehr. Es taucht kein Icon mehr auf…

Wenn ich mich da als Lehrer anmelde, sind zwar meine Server-Shares unter
/srv/samba/schools/default-school sowie unter
/var/lib/samba/sysvol
vorhanden und eingehängt aber auf dem Desktop gibt es keine Symbole/Links mehr zu den entsprechenden Verzeichnissen. Das funktionierte irgendwann schon mal und ich weiß nicht, warum es jetzt nicht mehr geht.

Kann es sein,

  • dass die Links für den Vorlagen-User „linuxadmin“ auch vorhanden sein müssen, damit sie wieder übernommen werden? Wer kann für mich ggf. nachsehen, wie diese Links im linuxadmin-Profil aussehen bzw wohin sie zeigen müssen (denn der linuxadmn selbst erhält ja keine Shares)

oder

  • dass meine # /etc/linuxmuster-client/adsso.conf vom 20181127 mittlerweile überarbeitet wurde und ich da die ganze Zeit eine veraltete Version habe??

Ich hatte auf dem gleichen Client die Icons zu meinen Shares jedenfalls schon mal – vorhin habe ich /home/cache geleert und mich neu angemeldet. Da erschien nichts mehr. Ein turnkey habe ich auch schon neu losgelassen. Ist zwar erfolgreich durchgelaufen – hat aber leider nichts geändert …

Gerade erst in der Orga-Übersicht gesehen: dieser Beitrag hätte vielleicht direkt an @Tobias gehen sollen!?? Kannst du hier dazu etwas sagen? Oder soll ich das unter github als issue anlegen?

Viele Grüße,
Michael

Hi.
… ich komme nochmal auf das Problem zurück.

Könnte jemand, bei dem die Verlinkung funktioniert, mir den Gefallen tun und bei sich nachsehen, wie die Rechte der Scripte unter /etc/linuxmuster-client/login.d aussehen müssen? Die Scripte sind hier alle nicht executable – vielleicht liegt es ja daran??

Hallo Michael,

ich schau Heute Nacht mal nach. Generell ist es schon seltsam, wenn
scripte kein X Bit gesetzt haben…

LG

Holger

Danke, Holger.
Mir ist gerade noch etwas anderes aufgefallen:

Laut Doku sollen beim Login alle möglichen Scripte ablaufen – unter anderem zunächst das Script
/etc/linuxmuster-client/login.d/00_userinfo.sh das dafür sorgt, dass ein paar Umgebungsvariablen unter /tmp/$USER gespeichert werden.
Das ist hier nicht der Fall. Es gibt dort aber eine Datei namens
-rw------- 1 meinlogin domain users 0 Dez 28 18:08 config-err-6E7uXd, die evtl stattdessen angelegt wurde?

Daher vermute ich mal sehr stark, dass alle weiteren Scripte schon deshalb nicht ausgeführt werden. Ich habe übrigens allen Scripten das +x Bit gegeben, um zu schauen, ob es daran liegt. Das hat bisher aber nichts geändert.

Wenn ich das richtig sehe, ist @Tobias für das adsso unter Bionic zuständig. Der ist aber leider AFK, wie es scheint??

Viele Grüße,
Michael

… und wieder etwas schlauer:
Beim Login eines Users wird das Script
/etc/linuxmuster-client/scripts/login.sh aufgerufen.
Das wiederrum ruft die anderen, oben genannten Scripte auf. Daher müssen die auch kein +x Bit besitzen!!!

Wenn ich das Script aber als User aufrufe, erhalte ich hier:

Executing /etc/linuxmuster-client/login.d/00_userinfo.sh ...
Failed to connect to ldap URL 'ldaps://server.linuxmuster.meine-domain.de' - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to 'ldaps://server.linuxmuster.meine-domain.de' with backend 'ldaps': LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to ldaps://server.linuxmuster.meine-domain.de - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
[...]

Es scheitert also an dem Befehl in Zeile 22 (ad_query):
ldbsearch -k yes -H ldaps://$servername.$ad_domain "(&(samaccountname=$USER))"

bzw ohne Variablen:
ldbsearch -k yes -H ldaps://server.linuxmuster.meine-domain.de "(&(samaccountname=meinlogin))"

Vielleicht kann ich meine Bitte von oben also abändern? Holger (oder gerne auch andere), könntest Du diesen Befehl bei Dir als User testen?
Funktioniert das bei Dir?
Die Option -k yes versucht die Abfrage über ein Kerberos-Ticket. Mit klist kann man sich (als User!) den Ticketzwischenspeicher ansehen.

Danke nochmal.
Viele Grüße,
Michael

Ok, jetzt weiß ich (wieder), was da faul ist (unter Punkt 2):

Es ist so: Wenn man eine ldap-Abfrage via Kerberos macht, MUSS man ldap und nicht ldaps verwenden. Das ist in dem Script 00_userinfo.sh also ein Bug! Da steht es falsch, da die Abfrage zusammen mit -k yes UND ldaps durchgeführt wird. Wenn man das s entfernt, laufen die Scripte durch und die Links zu den Shares werden auch wieder richtig angzeigt!

Also: In Zeile 22 in dem Script muss das s bei ldaps entfernt werden!!

Ergänzung: Gut möglich, dass dieser Fehler nur dann auftaucht, wenn man dem v7-Server einen FQDN und ein gültiges Zertifikat gegeben hat!

1 Like

Hallo Michael,

Ok, jetzt weiß ich, was da faul ist (unter Punkt 2):

kania-online.de https://www.kania-online.de/ldb-tools-nach-badlock/amp/

  ldb-tools nach Badlock | Stefan Kania
  <https://www.kania-online.de/ldb-tools-nach-badlock/amp/>

Es ist so: Wenn man eine ldap-Abfrage via Kerberos macht, MUSS man ldap
und nicht ldaps verwenden. Das ist in dem Script |00_userinfo.sh| also
ein Bug! Da steht es falsch, da die Abfrage zusammen mit |-k yes| UND
ldaps durchgeführt wird. Wenn man das s entfernt, laufen die Scripte
durch und die Links zu den Shares werden auch wieder richtig angzeigt!

Also: In Zeile 22 in dem Script muss das s bei ldaps entfernt werden!!

OK: krass.
Dann muss ich das also nicht mehr ausprobieren?

Ich hab jetzt einen Client in der Schule laufen und schau nach, wie das
in meiner Datei drin steht.

Bei mir steht die Zeile in Zeile 23 und enthält ein „s“ hinter dem http.

Ich hab jetzt also diese Zeile als „ich“ (Usernamen geändert) am Cleint
angemeldet in einem Terminal abgesetzt:

ldbsearch -k yes -H ldaps://server.meinedomain.lan „(&(samaccountname=ich))“

das funktioniert: es kommen etliche Angaben aus dem LDAP zurück:
Gruppenzugehörigkeiten usw.

Meine Domain hab ich aus der /etc/hosts des Clients geholt.

Irgend wie hab ich das Gefühl, dass bei dir was am DNS nicht stimmt…
der ist immer Schuld, wenn es ganz seltsam wird :slight_smile:

LG

Holger

Kann es auch sein, dass es bei dir klappt, da du intern keine „echte Domain“ verwendest, während ich auch intern unseren FQDN durchgereicht habe?! Jedenfalls funktioniert der Befehl bei mir mit ldaps:// nicht – während er mit ldap:// durchläuft und die gewünschte Ausgabe liefert.

Guck mal hier – da steht das auch nochmal. Über diese Seite bin ich irgendwann schon mal gestolpert und hatte es zwischenzeitlich wieder aus dem Kurzzeitgedächtnis gelöscht:

Hi Michael,

Dass es mit ldaps nicht klappt riecht für mich irgendwie nach einem Zwertifikatsproblem …
Kann es sein, dass dein Client dem (selbstsigierten?) Serverzertifikat nicht vertraut?
Nur so ein Gedanke … :man_shrugging:

VG
Dorian

Hi Dorian … ich glaube, dass eher das Gegenteil der Fall sein könnte?? Ich habe auf unserem v7 Server auch intern unseren FQDN benutzt. Zudem hat der v7-Server ein gültiges LE-Cert, was vom Client auch bestätigt wird:

openssl  s_client -connect server:636    (oder auch :3269)

---
Certificate chain
 0 s:CN = server.linuxmuster.<meine-domain>.de
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3

Daher vermute ich, dass bei Holger die Anfragen auf Port 636 bzw 3269 auch ohne Cert abgenickt werden? Ist die Option

TLS_REQCERT  never

evtl bei Euch gesetzt? Ich bin nicht ganz sicher, ob das auf dem v7-Server noch relevant ist – auf dem alten v6-Server war es das auf jeden Fall…

Ach ja – auch die verschlüsselte Abfrage via ldapsearch ... -H ldaps://server.... -U username funktioniert problemlos.

Viele Grüße,
Michael

Moin!

Ich würde die letzten 5 Beiträge (ab der Lösung) gerne in einen neuen verschieben. Was wäre eine passende Überschrift?

Beste Grüße

Thorsten

@MachtDochNix: Warum? Es ist ja noch nicht abschließend geklärt, warum das bei mir ohne s sein muss, während es woanders auch mit funktioniert
Ich würde das hier zusammen lassen…

Hi Michael,

Kann es sein, dass standardmäßig nur dem selbstsignierten Zertifikat, das vom Linuxmuster setup generiert wird, vertraut wird?
Ich kenn mich damit ehrlich gesagt nicht gut genug aus, aber es gab mal irgendwo einen Wiki Eintrag (oder einen Forenbeitrag?) in dem es um den Zertifikatskram ging, vielleicht steht da ja mehr.

VG
Dorian

Vielleicht meintest du diesen Beitrag von 2019?

Den kenne ich zufällig – kam von mir :slight_smile:

Nein, der war es nicht, aber ich finde ihn leider auch nich mehr :confused:

Hab da leider auch nicht mega viel Ahnung von …

@MachtDochNix: Warum? Es ist ja noch nicht abschließend geklärt, warum das bei mir ohne s sein muss, während es woanders auch mit funktioniert
Ich würde das hier zusammen lassen…

Weil du die Überschrift schon als gelöst markiert hast, vielleicht?! siehe post #6 :wink:

Ein Problem --> ein neuer Thread und bei dem eine möglich treffende Überschrift! Erleichtert auch das wiederfinden.

Beste Grüße

Thorsten

… dann nehme ich doch lieber das „Gelöst“ wieder raus, meine ich?

Die Frage, wer von wo über welche Verschlüsselung auf den Server zugreifen darf, scheint jedenfalls der Kern des Problems zu sein?!

Ich habe dazu diese Seite gefunden:

Hier ist es so: Wenn ich auf dem Server den Befehl mit TLS-Verschlüsselung (also mit der Option -Z) verwende:

 ldapsearch -H ldap://server -b "ou=default-school,ou=SCHOOLS,dc=linuxmuster,dc=meine-domain,dc=de" -D global-binduser@linuxmuster.meine-domain.de -w supergeheimesPasswort -Z

läuft die Anfrage durch; versuche ich das gleiche vom Client aus, erhalte ich:

ldap_start_tls: Connect error (-11)
        additional info: (unknown error code)
ldap_result: Can't contact LDAP server (-1)

Wenn ich es stattdessen mit SSL-Verschlüsselung und ohne die Option -Z über ldaps:// versuche, klappt es sowohl vom Server als auch vom Client aus! Das könnte ein Anhaltspunkt sein!?

Mir ist aber nicht klar, welche Verschlüsselung denn nun gewählt wird!?
Bisher war ich von SSL ausgegangen, da in o.g. Script ldbsearch -k yes -H ldaps:// stand, was dann über Port 636 bzw 3269 läuft…!?

Wer blickt da besser durch?
Vielleicht @mdt?

Viele Grüße,
Michael

Nur als Ergänzung noch ein Querverweis auf

Seltsamerweise steht in meiner smb.conf:

[root@server:]$  cat /etc/samba/smb.conf | grep strong
ldap server require strong auth = no

Laut dem Thread sollte da aber yes stehen – könnte das jemand mit seinen Settings vergleichen und hier posten?