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