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

Clientpflege Linuxclient
10

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

11

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

12

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

13

@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…

14

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

15

Vielleicht meintest du diesen Beitrag von 2019?

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

16

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

Hab da leider auch nicht mega viel Ahnung von …

17

@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

18

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

19

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

20

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?

21

Hallo Michael,

Nur als Ergänzung noch ein Querverweis auf

Server-Appliance
<https://ask.linuxmuster.net/t/server-appliance/3312> v7-Betatest
<https://ask.linuxmuster.net/c/server-v7/v7-betatest/47>

Hi! Es gibt eine aktualisierte Version der Server-Appliance
<https://github.com/linuxmuster/linuxmuster-base7/wiki/Die-Appliances#server>
auf Basis von Ubuntu Server 18.04.2. VG, Thomas

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?

in meiner steht das auch auf „no“.
Laut dem Thread solltest du das da ändern: das wird nciht per
distupgrade geändert.

Ich dachte damals wohl: " das machste mal in den Ferien und schaust ob
noch alles geht" … und habs dann vergessen … jetzt sind aber gerade
Ferien … da kann ich wohl gleich nochmal ran an die Boulette :slight_smile:

LG

Holger

22

Hallo Holger,
also, wenn du „yes“ setzt, sind nur noch verschlüsselte Verbindungen über TLS bzw LDAPS erlaubt – auch auf Port 389, ja?
Wäre ja interessant zu erfahren, welches Cert. bei Dir dann ausgeliefert wird – es gibt ja „nur“ das SnakeOil-Cert der Installation, nehme ich an? Hast du das irgendwann mal auf dem Client hinzugefügt, damit der Client dem Cert. vertraut??

Viele Grüße
Michael

23

Hallo Michael,

also, wenn du „yes“ setzt, sind nur noch verschlüsselte Verbindungen
über TLS bzw LDAPS erlaubt – auch auf Port 389, ja?
Wäre ja interessant zu erfahren, welches Cert. bei Dir dann ausgeliefert
wird – es gibt ja „nur“ das SnakeOil-Cert der Installation, nehme ich
an? Hast du das irgendwann mal auf dem Client hinzugefügt, damit der
Client dem Cert. vertraut??

ich hab da nix gemacht: ich hab nur irgend wann mal
linuxmuster-client-adsso ausgeführt.
Ich denke, da passiert das.

LG

Holger

24

Ja, so hieß es geht am Anfang, jetzt aber

linuxmuster-cloop-turnkey
25

… hat nur indirekt mit diesem Thread zu tun … aber wie groß ist bei Euch das Vorlagenverzeichnis von /home/linuxadmin?

Ich habe hier insgesamt 258MB im Profil:
Screenshot_20201229_174033

… entsprechend dauert die Erstanmeldung eines neuen Users an den Client.
(Unter Win10 ist es noch größer und nerviger … aber unter Linux sollte man das doch ordentlich nach unten drücken können?)

26

Hallo Michael,

… hat nur indirekt mit diesem Thread zu tun … aber wie groß ist bei Euch
das Vorlagenverzeichnis von |/home/linuxadmin|?

Ich habe hier insgesamt 258MB im Profil:
Screenshot_20201229_174033

bei mir sind es 182MB

… entsprechend dauert die Erstanmeldung eines neuen Users an den Client.
(Unter Win10 ist es noch größer und nerviger … aber unter Linux sollte
man das doch ordentlich nach unten drücken können?)

da hab ich schon rumgespielt: arg viel hab noch nicht erreicht. Ich
nutze lmlcc und bleachbit als root und als linuxadmin vor der
Imageerstelltung.
Leider macht ubuntu anscheinend inzwischen Ähnliches wie Windows beim
Login: also nicht nur das Vorlagenprofil kopieren.
250MB sollten für eine SSD nicht der Schocker sein.

Und wegen der Anmeldezeiten unter Windows: aufgrund eines Supportfalls
ist mir bewußt geworden, dass dein GPO Zeug auch andere Nebenwirkungen
hat: die Loginzeit kann das sehr beeinflussen.
Darauf wollte ich dich noch hinweisen :slight_smile:
Also mal GPOs abschalten und Loginzeit vergleichen (unter Windows… hat
nix mit ubuntu zu tun).

LG

Holger

27

Ja, ist klar, dass es etwas länger dauert – ich hatte ja extra die GPO „auf Netzwerk warten“ aktiviert. Aber das ist es in dem Fall wert …

Die Anmeldung am Bionic-Client geht hier schneller als unter Windows … aber der alte Xenial-Client war noch schneller…

28

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

29

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