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
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!
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. 
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. 
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
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
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 …
… 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:
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
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
Hallo,
Schnell gelesen kann das Skript nicht so funktionieren : zumindest soll samba neu starten um das veränderte Zertifikat neu zu laden.
Gruß
Arnaud
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“…
Hallo,
Ich habe mal ein LE-Zertifikat bei mir getestet, und ich kann folgende bestätigen :
smb.conf auf dem Server, muss der Samba Service neu gestartet sein,privkey.pem müssen 0600 sein, ansonstens „startet“ LDAPS nicht,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,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
Super, dass du das nachvollziehen konntest und den Fehler finden konntest.
Hallo,
sprach ich … und machte ich.
Dummerweise hab ich ein echt schlechtes Gedächtnis: so war ich doch überrascht, als mir Ende Januar gemeldet wurde, dass sich niemand mehr in der Schulkonsole(WebUI) anmelden konnte …
Da ging dann das Suchen los. Zum Glück half mir Arnaud und nach ein paar Tagen fanden wir dann den Eintrag.
Ich hab wieder „no“ reingeschrieben und die WebUI funktionierte wieder…
… für euch zur Info: nur falls auch mal jemand da auf „yes“ stellen will …
LG
Holger
Hi.
Dieser Thread wird „allmählich“ etwas unübersichtlich … aber ich versuche mein Glück.
Holger (@baumhof) , ich habe bei mir auch weiterhin „No“ in der smb.conf stehen. Das ist in Ordnung so.
Arnaud (@arnaud),
systemctl restart samba-ad-dc.service erweitert. Das Script läuft hier nachts einmal im Monat.ldbsearch mit gültigem LE-Cert das s nicht mehr verträgt, ist nicht so schlimm – wenn man es weiß. Aber es wäre schon interessant zu erfahren, ob die Anmeldescripte in der Paketverwaltung da künftig das s drin haben sollten oder nicht? Ich weiß nicht, wie viele Installationen hier mit und wie viele ohne TLD als Domainname installiert wurden. (Als ich die v7 Ende 2019 installiert habe, hieß es, dass man ein paar Vorteile hat, wenn man das so macht – aber im Nachhinein betrachtet, hätte ich das besser lassen sollen…)chain.pem nochmal genauer sagen?Jetzt habe ich hoffentlich alle offenen Fragen erwischt.
Bis später – viele Grüße,
Michael
Hallo Michael,
ldbsearch verwendet sein eigener Mechanismus um die Ldapverbindung aufzubauen und soll das Zertifikat überprüfen, dafür braucht er den CAFile von Let’s Encrypt, d.h. chain.pem.
Das funktioniert wahrscheinlich mit dem Snake-Oil ( ich weiß nicht genau was Snake-Oil ist ), weil es auch ein Art selbst-signiert ist, und dafür reicht vielleicht den cacert.pem als CAfile.
Man kann die Anfrage per ldap anstatt ldaps machen, aber muss es per Kerberos-Authentifizierung laufen, ansonstens ist es nicht sicher.
Gruß
Arnaud
Hallo Michael,
SSH-Tunnel + VNC machen es möglich von zu Hause, aber da steht die Gefahr, seine Wochenende zu zerschiessen.
Gruß
Arnaud
Hej,
Ich denke, den Punkt verstehe ich. Das heißt die CA-Zertifikatstkette von LE muss auf den Client.
Das passiert bei einer Domänenaufnahme automatisch, da wird die Datei vom Server (/var/lib/samba/sysvol/meine-schule.de/tls/cacert.pem) auf dem Client abgelegt (als /var/lib/samba/private/tls/meine-schule.pem).
Bitte korrigiert mich, wenn ich das falsch verstanden habe.
Das cacert sollte sich eigentlich nicht sehr oft ändern, tut es aber halt zumindest manchmal.
Deshalb wäre es vermutlich sinnvoll, dass man das richtige Zertifikat noch direkt auf den Client bringt.
Entweder manuell, was @Arnaud empfiehlt, oder vielleicht automatisiert per Postsync…
Ich habe gerade meine Version des Scripts um diese Zeilen ergänzt
# Make copies of the CA-certificate for the client
cp chain.pem /var/lib/samba/sysvol/$domain/tls/cacert.pem
if [ ! -d "/srv/linbo/linuxmuster-client/$cloopname/var/lib/samba/private/tls/" ]; then
mkdir -p /srv/linbo/linuxmuster-client/$cloopname/var/lib/samba/private/tls/
fi
cp chain.pem /srv/linbo/linuxmuster-client/$cloopname/var/lib/samba/private/tls/$domain.pem
Bitte um Kontrollblick. Funktioniert so natürlich erst mal nur mit einem einzelnen cloop. Sind die Dateiberechtigungen hier wichtig? Auf dem Client hat die /var/lib/samba/private/tls/$domain.pem derzeit 755.
Grüße
Michael
Hej, kurz OT:
Da sagst Du was! Das ist die nächste Baustelle. Im Moment tunnele ich mich per SSH zu einem XOA im grünen Netz durch und habe dort einen virtuellen Testclient. Aber das zeigt ganz komische Effekte (Z.B. kann ich den Client nicht mit Linbo syncen, weil der abrupt und unvermittelt aufhört sich das Image zu holen)
Langer Rede kurzer Sinn. Sobald Zeit ist, will ich das VNC aufsetzen.
Grüße und nochmal Danke für die Antworten.
Michael
Hier steht, woher der Begriff kommt
Hallo,
für Arnaud:
https://woerterbuch.reverso.net/deutsch-franzosisch/Schlangenöl
Also: remède miracle
LG
Holger