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

Hej, na klaro:

root@server:/etc/samba# cat smb.conf
# /etc/samba/smb.conf.setup
#
# Don't edit this file!!!
# Add your stuff in /etc/samba/smb.conf.admin.
#
# thomas@linuxmuster.net
# 20200818
#

[global]
workgroup = #MEINE-SCHULE#
realm = #MEINE-SCHULE.DE#
netbios name = SERVER
server role = active directory domain controller
dns forwarder = 10.16.1.254  # Das ist bei uns die OpnSense
registry shares = yes
host msdfs = yes
tls enabled = yes
tls keyfile = /etc/linuxmuster/ssl/server.key.pem
tls certfile = /etc/linuxmuster/ssl/server.cert.pem
tls cafile = /etc/linuxmuster/ssl/cacert.pem
tls verify peer = ca_and_name
ldap server require strong auth = no
rpc_server:spoolss = external
rpc_daemon:spoolssd = fork
spoolss:architecture = Windows x64
printing = cups
printcap name = cups
time server = yes
ntp signd socket directory = /run/samba/ntp_signd

[netlogon]
path = /var/lib/samba/sysvol/csg-tuebingen.de/scripts
read only = No
acl allow execute always = yes

[sysvol]
path = /var/lib/samba/sysvol
read only = No

[printers]
browseable = No
path = /var/spool/samba
printable = Yes
read only = No

[print$]
path = /var/lib/samba/printers
read only = No

# including custom admin stuff
include = /etc/samba/smb.conf.admin

Die drei Zeilen mit den Standard-Zertifikaten werden durch die /etc/samba/smb.conf.admin überschrieben.

root@server:/etc/samba# cat smb.conf.admin 
# modified by linuxmuster-setup at 20200722190310
# /etc/samba/smb.conf.admin
#
# thomas@linuxmuster.net
# 20180713
#
# add here your custom admin stuff
#
[global]
tls keyfile = /etc/linuxmuster/ssl/server.le.privkey.pem
tls certfile = /etc/linuxmuster/ssl/server.le.fullchain.pem
tls cafile = /etc/linuxmuster/ssl/server.le.chain.pem

Hi, ich habe mit kdiff3 verglichen. Einziger relevanter Unterschied dürfte bei mir dieser Eintrag sein, den es bei dir nicht gibt:

#Protokoll geaendert: #ntlm auth = yes < deaktiviert und nur noch eingeschraenkt erlaubt: 02.07.2020
ntlm auth = mschapv2-and-ntlmv2-only

Ich fürchte, dass das ein ziemliches „im Nebel stochern“ bleibt … ?!
Wenn du aber sagst, dass deine User direkt bei der ersten Anmeldung ein gültiges Kerberos-Ticket erhalten, läuft bei Dir ja immerhin dieser Schritt richtig. Bei mir passt das immer erst, wenn ich es manuell anstoße.
Vielleicht sollte ich den Client doch nochmal aus der Domäne entfernen und neu hinzufügen!?
Viele Grüße,
Michael

Hej,

Ich habe leider keine Ahnung. Ich weiß noch nicht mal, warum das seit um Weihnachten herum plötzlich auftrat.

Grüße
Michael

Hallo Michael,

als das LE Zertifikat erneuert wurde, blieben da die richtigen Zugriffsrechte erhalten?

Viele Grüße
Christian

Hi Christian.
Ich lasse die OPNSense alle LE-Zertifikate verwalten. Die werden dann per Script auf den v7-Server übertragen. Das funktioniert alles seit mindestens einem Jahr fehlerfrei. Wenn ich intern im Browser
https://server.meine-domain.de oder auch https://firewall.meine-domain.de aufrufe, habe ich immer ein gültiges Zertifikat. Von daher würde ich sagen: Ja, das passt!

Mittlerweile habe ich gesehen, dass es auf dem v7-Server ein weiteres Zertfikat an dieser Stelle gibt:
/var/lib/samba/sysvol/linuxmuster.meine-domain.de/tls/cacert.pem
Das stammt hier von 2019 – wurde also direkt bei der Installation dort abgelegt. Wie es dahin gekommen ist und welche Funktion das dort hat, weiß ich nicht. Erklärt das evtl, warum Leute ohne FQDN keine Probleme haben? Wer kann etwas dazu sagen?

Viele Grüße,
Michael

Hej Michael,

That rings a bell.
Wir hatten das schonmal: Linuxmuster-client-adsso funktioniert nicht (mehr) - #5 von foer

Und das deckt sich mit meiner (und deiner…?) Situation:
Unter /etc/linuxmuster/ssl/ liegen die Let’s-Encrypt-Zertifikatsdateien (insbesondere: server.le.chain.pem (A)). Die Dateien wurden in meinem Fall am 31.12. über einen deploy-hook von certbot dort abgelegt.
Unter /var/lib/samba/sysvol/meine-domaene.de/tls liegt noch das cacert.pem (B) von September.
Eigentlich sollte A = B sein, isses aber nicht.

Kann es sein, dass daran die Einbindung unserer Homes scheitert? :face_with_raised_eyebrow:

Wenn ich es richtig verstanden habe, wird über linuxmuster-client-adsso-setup die Datei A auf den Client gebracht. So hat es jedenfalls @foer hier erklärt.

Das wäre aber maximal nervig, weil man ja nach dem adsso-setup-script jeweils ein neues Image schreiben müsste :unamused:

Wer weiß denn hierzu mehr?
Und wie kann man das so automatisieren, dass uns das nicht regelmäßig um die Ohren fliegt?

Danke für eure Hilfe und Grüße
Michael

Hi Michael … ja, das hatten wir alles schon mal. Und wieder bin ich froh, dass ich nicht der einzige bin, der hier im Nebel stochert :slight_smile:
Es scheint leider so zu sein, dass das adsso-Paket zZ keinen richtigen Maintainer hat →

Daher müssen wir selbst tiefer graben, bis wir die Stelle finden, wo es klemmt.
Hast du denn schon mal versucht, an der Stelle B einen Symlink zu erzeugen, der immer nach A auf das richtige cert zeigt?

Ich habe hier auch wieder das Problem, dass die Anmeldung an den Linux-Clients mal klappt – und mal nicht.

Eine andere Idee: Auf dem Server befindet sich im LINBO-Verzeichnis die .macct-Datei und auf dem Client die /etc/krb5.keytab. Vielleicht kann ja nochmal jemand erklären, wie diese beiden miteinander zusammenhängen, denn beide sind offenbar notwendig…

Viele Grüße,
Michael

Hallo,

suchen wir hier nicht das Problem am falschen Ende?
Ja: der linuxmuster-client hat noch Probleme, aber eure wurden ja nicht durch dieses Problem verursacht, sondern weil ich

  1. eine echte Domain intern benutzt
  2. diese durch ein LE Cert absichert

Würde es nciht reichen dem certbot bei zu bringen bei einem Update A=B wieder her zu stellen durch kopieren der certs zusätzlich an die richtige Stelle?

LG

Holger

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

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

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

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“

Hi. Nochmal als Erinnerung:

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!

Hallo Michael,

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

Gruß

Arnaud

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

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

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. :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