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

Clientpflege Linuxclient
41

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

42

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

43

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

44

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“
45

Hi. Nochmal als Erinnerung:

46

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!

47

Hallo Michael,

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

Gruß

Arnaud

48

hab’s auch ohne Port oder mit 3269 versucht … immer das gleiche … hast du denn intern einen FQDN oder nimmst du linuxmuster.lan?

49

Ich verwende einen Domänname mit TLD, aber die externe DNS zeigen nicht darauf. Du sollst überprüfen, ob die DNS bei dir stimmen.

Gruß

Arnaud

50

Hallo Arnaud,
also wenn ich vom focal fossa Client aus ping server oder auch dig server verwende, passt alles (analog für firewall). Die DNS-Einstellungen sehen mir daher richtig aus?!
Ich habe anstelle von ldbsearch auch schon ldapsearch ausprobiert – wenn ich da den global-binduser + Passwort mit angebe, funktioniert alles!

Viele Grüße,
Michael

51

Aha – gerade bemerkt, dass es erneut der gleiche Fehler ist wie bereits oben geschildert. Wenn ich intern einen Domänename mit TLD verwende, muss ich offenbar diese Syntax nehmen:

ldbsearch --krb5-ccache=/tmp/krb5cc_1084201206_dUxytz  -H ldap://server "(&(samaccountname=meinlogin))"

Das s darf dort bei mir nicht stehen … warum das bei anderen nicht zutrifft, weiß ich nicht – spricht aber erneut für das, was ich schon oben verlinkt hatte!?

Gerade nochmal getestet, ob das Zertifikat vom Client aus abrufbar ist: Ja, das klappt! Mit
openssl s_client -connect server:636 oder auch
openssl s_client -connect server:3269 sehe ich die vollständige Certificate chain von LE!

52

Hej,

ich musste gestern schnell nach Hause und kam erst heute Abend dazu mich darum zu kümmern.
Ich habe nun (vermutlich) zumindest die Ursache für mein Problem gefunden.

Vorweg: @Michael… bei mir funktioniert weiterhin nur ldap ohne (s)

Für mich gab’s ein paar Sackgassen: Ich habe zunächst lange geforscht und versucht, das hier:

in /etc/linuxmuster-client/login.d/00_userinfo.sh so unterzubekommen, dass es funktioniert. Wie @Arnaud geschrieben hat, ist es ein Problem aus dem root Kontext auf das richtige Ticket zuzugreifen. Das $USER im obigen Code evaluiert zu root…

Dann bin ich genervt durchs Haus geschlendert und habe dabei en passant herausgefunden, dass nicht alle Rechner von den fehlenden Homes betroffen sind! Trotz gleichem Image…
Auf dem einen Client funktioniert ldbsearch -k yes … auf dem anderen nicht. :thinking:

Und dann wollte der betroffene Client plötzlich automatisch herunterfahren, weil 22 Uhr… Und dabei war es in der Realität erst 21:53 Uhr. :astonished:
Langer Rede, kurzer Sinn: Bei mir war das - mal wieder - ein Zeitproblem!

@Michael Zurück auf Anfang: Bist Du sicher, dass die Uhrzeit stimmt?

Was mich wunderte: Wenn ich den Client in der Linbo-Console nach der Zeit fragte, war sie noch richtig. Im Ubuntu-Greeter nach dem Hochfahren ging die Uhr wieder 7 Minuten vor und die Homes waren wieder weg.
Stellt sich raus: Beim Reboot erhielten die Notebooks eine falsche Zeit vom Bios…

Soweit mal als Zwischenstand für heute.
Kommt man um den Reboot eigentlich inzwischen irgendwie herum?
Jemand eine Idee, wie ich sicherstellen kann, dass die Urzeit beim Anmelden stimmt?

Grüße
Michael

53

Hallo Michael,

sowas ist echt nervig und schwer nachzuverfolgen! Gut, dass Du den Grund gefunden hast.

Wenn in Linbo die Zeit stimmt, dann kannst Du ja im Postsync-Skript (oder dem neuen Prestart-Skript) die Hardwareuhr setzen.

Beste Grüße

Jörg

54

Moin.
Auszuschließen ist das Zeitproblem natürlich nicht… Ich habe die Anpassungen bzgl ntpd seinerzeit so gemacht, wie es hier diskutiert wurde.

Dass das Image nun auf alter Hardware, die schon jahrelang mit anderen Images bestückt wurde, aber jetzt überhaupt nicht läuft (s. Parallelthread) nervt schon gewaltig …

55

… ach ja:

Das ist doch gut zu wissen und spricht wirklich dafür, dass man das s in Kombination mit Kerberos weglassen sollte!? Ich verstehe aber trotzdem nicht, warum das s bei selbst signierten Zertifikaten scheinbar funktioniert?!

Meinst du mit diesem Reboot den zwischen LINBO- und Ubuntu-Start? Der wurde imho extra eingeführt, um div. Problemen aus mit div. Hardware aus dem Weg zu gehen, oder?

Was die Uhrzeit angeht: Hier nochmal der (lange) Thread, den Gerd begonnen hatte … ich hatte das hier so eingestellt wie dort angegeben:

56

Hallo,

Das ist nicht richtig : wenn einen User sich anmeldet, dann sollte $USER den Username sein. Das obige Code kann man nicht als root/linuxadmin verwenden, das sollte nur im 00_userinfo.sh funktionieren, bei der Anmeldung.

ldbsearch -k yes wird nicht funktionieren, wenn die Zeit nicht stimmt, aber mit dem Pfad zur Ticket geht es.

Kannst du bitte genau beschreiben, ob und wie du ein Zertifikat installiert hast ? ( LE einfach auf dem Server in /etc/samba/smb.conf bei tls ... eingetragen ? )
Wenn ich Zeit finde, probiere ich auf meine Testumgebung.

Gruß

Arnaud

57

Hej,
ich bin jetzt wieder zu Hause. Und kann den ersten Teil (Anpassung der 00_userinfo.sh) von hier aus schlecht testen. Ich habe aber gestern viel dazu ausprobiert - und das mit den Kontexten war auch ein Problem wenn ich das Skript dadurch ausgeführt habe, dass ich mich ab- und wieder angemeldet habe.
Ich fand dann jeweils Dateien. /tmp/krb5cc_0_rAndOM , also mit der Null für root in der Mitte…

BTW: Ich bekomme über sudo -u USER env die Variable $KBRCCNAME. Es sind zwar deutlich weniger Umgebungsvariablen per sudo, aber $KBRCCNAME war dabei. Habe das aber nicht weiter verfolgt.

Egal stellen wir das mal beiseite, weil das ja auch nicht @Michael s Problem zu sein scheint.

Danke, dass Du dich der Sache annehmen willst.

Also: Ich habe externe Domain = interne Domain. Ich lasse das LE-Zertifikat mit certbot direkt auf dem pädagogischen Server erstellen. Ein deploy-hook (/etc/letsencrypt/renewal-hooks/deploy/copy_certs.sh) schiebt die Zertifikate an die richtige Stelle. Das Script habe ich von @Michael für meine Zwecke angepasst…

#!/bin/bash
#set -x

################################################
# Scriptname :    copy_certs.sh
# Author     :    Michael_Hagedorn, Michael Sedding
# Date       :    2020-09-05
# Category   :    geeignet für linuxmuster 7.x
# Version    :    VER='1'

# Dieses Script kopiert die vom certbot erstellten Zertifikatsdateien in das Standard-LMN-Verzeichnis für Zertifikate.
# Anschließend wird die WebUI neu gestartet, so dass eine gesicherte Verbindung zum Server mit gültigem Zertifikat möglich ist.
# Das Skript sollte beim von certbot als "deploy-hook" aufgerufen werden.
# Dafür sollte es reichen, das Script in /etc/letsencrypt/renewal-hooks/deploy/ abzulegen
# Altenativ kann man auch den Cronjob anpassen.  /etc/cron.d/certbot ist so anzupassen:
# 0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew --deploy-hook /path/to/the/script/copy_certs.sh

################################################

#Variablen:
host="server.meine-domain.de"
lepath="/etc/letsencrypt/live/"
lmncertpath="/etc/linuxmuster/ssl"
filenameprefix="server.le"

# Let's go:
cd $lepath/$host/

# Make bundle for ajenti
cat fullchain.pem privkey.pem > $lmncertpath/$filenameprefix.cert.bundle.pem

# Make copies of the relevant files for samba
cp fullchain.pem $lmncertpath/$filenameprefix.fullchain.pem
cp chain.pem $lmncertpath/$filenameprefix.chain.pem
cp privkey.pem $lmncertpath/$filenameprefix.privkey.pem
#cp chain.pem /var/lib/samba/sysvol/$host/tls/cacert.pem

# Adjust group and filepermissions
chown root:ssl-cert $lmncertpath/$filenameprefix.*
chmod 640 $lmncertpath/$filenameprefix.cert.bundle.pem
chmod 640 $lmncertpath/$filenameprefix.fullchain.pem
chmod 640 $lmncertpath/$filenameprefix.chain.pem
chmod 600 $lmncertpath/$filenameprefix.privkey.pem



# Restart WebUI
systemctl restart linuxmuster-webui

#EOF

Die Zertifikate sind über die /etc/samba/smb.conf.admin-include-Datei in Samba eingetragen. Siehe oben: bionic-Client: adsso.conf, Icons und verschlüsselte Verbindung mit Zertifkat - #33 von sedding

In der WebUI hatte ich das damals auch „scharfgeschaltet“. In der /etc/ajenti/config.yml steht deshalb u.a. das:

ssl:
  certificate: /etc/linuxmuster/ssl/server.le.cert.bundle.pem
  client_auth:
    certificates: []
    enable: false
    force: false
  enable: true
  fqdn_certificate: /etc/linuxmuster/ssl/server.le.cert.bundle.pem

Was nicht automatisch passiert, ist dass die chain.pem auch noch nach /var/lib/samba/sysvol/[FQDN]/tls/cacert.pem kopiert wird. Weil:
a) war mir nicht klar, dass sich das CA-Zertifikat manchmal ändert.
b) kommt das m.W. eh nur auf den Client, wenn man ein linuxmuster-client-adsso-setup ausführt… Korrekt?

Soweit viele Grüße
Michael

58

Hallo,

Schnell gelesen kann das Skript nicht so funktionieren : zumindest soll samba neu starten um das veränderte Zertifikat neu zu laden.

Gruß

Arnaud

59

Das wäre natürlich suuuuper, wenn es daran liegt!! Kann es gerade nicht ändern – bin afk.
Aber das würde manche Seltsamkeit erklären, auch das „mal geht’s und mal nicht“…

60

Hallo,

Ich habe mal ein LE-Zertifikat bei mir getestet, und ich kann folgende bestätigen :

  • nach Änderung von smb.conf auf dem Server, muss der Samba Service neu gestartet sein,
  • die Rechte von privkey.pem müssen 0600 sein, ansonstens „startet“ LDAPS nicht,
  • mit dieser Änderung ist ldbsearch nicht mehr fähig ein Ldaps Anfrage am Server zu machen : als Konzequenz sind die Share gemountet, aber adsso kann nicht die symbolische Linke erstellen, und die Shares tauchen nicht mehr auf im User’s Home,
  • um es zu korrigieren, soll man chain.pem auf dem Linuxclient als /var/lib/samba/private/tls/DOMAIN.pem kopieren mit richtigen Rechte. Dieser Datei chain.pem ändert sich bei LE kaum, kann man im cloop lassen.

Natürlich müssen auch die Uhrzeit + DNS stimmen.

Damit hat bei mir alles geklappt.

Letztens : das ist nach meiner Meinung kein Bug von adsso, aber eher eine persönnliche Anpassung, die nicht richtig konfiguriert ist.

Gruß

Arnaud

1 „Gefällt mir“