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

baumhof · 29. Dezember 2020 um 15:12

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

LG

Holger

Michael · 29. Dezember 2020 um 15:30

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

baumhof · 29. Dezember 2020 um 15:51

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

Michael · 29. Dezember 2020 um 16:11

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

linuxmuster-cloop-turnkey

Michael · 29. Dezember 2020 um 16:42

… 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?)

baumhof · 29. Dezember 2020 um 17:18

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
Also mal GPOs abschalten und Loginzeit vergleichen (unter Windows… hat
nix mit ubuntu zu tun).

LG

Holger

Michael · 29. Dezember 2020 um 18:06

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…

sedding · 24. Januar 2021 um 13:47

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

baumhof · 24. Januar 2021 um 15:01

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

Michael · 24. Januar 2021 um 16:08

Hi.
Zunächst mal: Ich bin immer etwas „erleichtert“, wenn andere das gleiche Problem haben – dann steigt die Chance, dass es ein Bug ist und er eines Tages behoben wird. Dass Du nun also auch über die fehlende Home_auf_Server-Verknüpfung gestolpert bist, „freut mich“!

Holger: Intern funktioniert die Namensauflösung problemlos.

Michael: Hast du auch diesen Thread entdeckt & mitverfolgt:

Ich weiß mittlerweile, dass fehlende Home_auf_Server bzw Tausch_auf_Server Icons mehrere Ursachen haben können: Das Anmeldescript muss natürlich vernünftig durchlaufen – aber auch die Sache mit Kerberos und den lokalen Systemzeiten muss passen. Da ich bisher immer auf einer VM (Proxmox) getestet habe, unterscheiden sich manche Dinge von realer Hardware (hwclock, Bios-Zeit …).

Was habt ihr denn ausprobiert?
Mir kommt es weiterhin so vor, als sei ldaps im Zusammenhang mit Kerberos überflüssig (wie schon in dem Thread erwähnt). 100%ig sicher bin ich da aber nicht – ich hatte mich da nur auf andere Webseiten berufen, wo das geschrieben steht.

Ich habe den Eintrag ldap server require strong auth = no hier auch – weiß aber nicht, ob das default ist und ob es Auswirkungen auf anderes gibt …

Eine bessere Lösung habe ich leider momentan nicht. Vielleicht liest ja eine @Entwickler mit?

Viele Grüße,
Michael

sedding · 25. Januar 2021 um 06:22

Hej,

Ja, geteiltes Leid ist halbes Leid.

Michael: Hast du auch diesen Thread entdeckt & mitverfolgt:

Bisher nicht. Scheint auch nicht auf die Situation bei uns zu passen. klist zeigt bei uns ein aktuelles Ticket.

Was habt ihr denn ausprobiert?

Nicht viel. Wir haben überprüft, ob die Shares unter /srv/samba/... gemountet sind (waren sie) und haben dann nachgeforscht, was da beim login schief läuft. also /etc/linuxmuster-client/scripts/login.sh ausgeführt und diese Fehlermeldung erhalten:

sed@r118-imagevm:/etc/linuxmuster-client/scripts$ sudo ./login.sh 
Executing /etc/linuxmuster-client/login.d/00_userinfo.sh ...
Failed to connect to ldap URL 'ldaps://server.meine-domaene.de' - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to 'ldaps://server.meine-domaene.de' with backend 'ldaps': LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to ldaps://server.meine-domaene.de - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
...

Dann haben wir das Discourse angesurft und deinen Foreneintrag gefunden.
Haben dann das s bei ldaps entfernt und den login.sh nochmal ausgeführt. Nachdem das script so fehlerfrei durchlief und die Shares wieder vorhanden waren, haben wir schnell eine überarbeitete 00_userinfo.sh ins Postsync gelegt und uns dann wieder unserer eigentlichen Aufgabe zugewandt…

Eigentlich waren wir in der Schule, weil letzte Woche endlich unsere Corona-„Sofort“-Hilfe-Notebooks für die SuS angekommen sind…

Grüße
Michael

Michael · 25. Januar 2021 um 07:32

Hallo, OK das sind doch gleich zwei wichtige Infos:

Das s bei der LDAP Verbindung ist scheinbar ein Problem, wenn man ein gültiges Zertifikat auf dem Server einsetzt.
Du hast im Gegensatz zu mir ein Ticket mit richtiger Uhrzeit beim Erstlogin.

Kannst du Deine vollständige smb.conf hier posten? Vielleicht gibt es ja doch einen markanten Unterschied??

Viele Grüße
Michael

sedding · 25. Januar 2021 um 08:13

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

Michael · 25. Januar 2021 um 13:36

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

sedding · 26. Januar 2021 um 16:53

Hej,

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

Grüße
Michael

Blair · 29. Januar 2021 um 07:35

Hallo Michael,

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

Viele Grüße
Christian

Michael · 29. Januar 2021 um 08:14

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

sedding · 16. Februar 2021 um 22:14

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?

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

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

Michael · 17. Februar 2021 um 08:26

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

baumhof · 17. Februar 2021 um 08:44

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

eine echte Domain intern benutzt
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