Dem kann ich mich nur anschließen. Vielen Dank Thomas für deine super Arbeit.
Mathias
Hi Thomas,
hast du schon probiert, die Nummer clientseitig zu patchen? Geht es dann wieder?
VG
Dorian
Hallo Dorian,
nein, ich denke nicht, dass das geht. Die KVNO wird ja automatisch hochgezählt und muss synchron zum Server sein. Könnte man die so einfach patchen, wäre dieses Sicherheitsfeature wertlos. Die einzige Möglichkeit die KVNO zu manipulieren ist IMO das Clientpasswort zu ändern (oder der Domäne neu beizutreten), wobei das neue Passwort sich vom alten unterscheiden muss, sonst wird nicht hochgezählt.
Es gibt aber die Möglichkeit die clientspezifische keytab auf dem Server aus dem AD zu exportieren und auf den Client zu schicken. Das funktioniert. Eine Lösung ist also in Sicht. 
VG, Thomas
Doch, das geht sogar ziemlich einfach. Ich habe damals eine Library geschrieben, die das keytab direkt verändern kann. Damit wird ja auch der Hostname gepatcht. Ich kann dir gerne ein kleines Python script schreiben, das die Nummer setzt.
Siehe hier:
Und hier:
…dort, wo der entry.principal geändert word, könnte man auch entry.keyVersion ändern.
VG,
Dorian
Okay. Bleibt das Problem die Server-KVNO aus dem AD abzufragen, wenn clientseitig die Authentifizierung kaputt ist.
VG, Thomas
Ist ja nur eine Idee. Wenn du eine bessere hast, dann mach es gerne anders. Aber bist du dir sicher, dass es an der KVNO liegt? Weil eigentlich hatte ich das schon berücksichtigt und den entsprechenden Check deaktiviert (siehe Domain join · linuxmuster/linuxmuster-linuxclient7 Wiki · GitHub Punkt 9.3)
VG,
Dorian
Claude sagt ja. In auth.log wird auf die unterschiedliche kvno verwiesen. Samba-Entwickler diskutierten das Problem auch schon und lösten es auf dem Server, in dem sie durch eine entsprechende Anzahl von Passwortänderungen die kvno hochzählten. Ist aber fehleranfällig und rückwärtszählen geht auch nicht.
krb5_validate = False wirkt nur für sssd, nicht für krb5.
VG, Thomas
Also ich habe jetzt mal einen neuen Debian-13 Client aufgesetzt, mit dem linuxclient setup den Domainjoin gemacht und diese kleine Änderung vorgenommen:
Damit funktioniert bei mir beim Master-Client alles einwandfrei. Die ganzen Änderungen, die du im Ticket beschrieben hast, leuchten mir nicht ein. Kannst du das noch einmal erklären? Oder hat Claude da halluziniert?
Ich probiere jetzt mal zu clonen und die KVNO zu patchen.
VG,
Dorian
Ich hab es jetzt zum Laufen gebracht. Ich verstehe aber die Lösung noch nich ganz…
Das ist die Lösung:
sudo systemctl edit sssd.service
Dort in der [Service] Section folgendes einfügen:
AmbientCapabilities=CAP_SETUID CAP_SETGID CAP_DAC_READ_SEARCH
SecureBits=
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_DAC_READ_SEARCH
Danach:
sudo systemctl daemon-reload
sudo systemctl restart sssd
Damit funktioniert der login und auch das Einbinden der shares bei mir einwandfrei. Hat jemand eine Idee, wieso diese Änderung auf einem geclonten Client nötig ist, auf dem Masterclient aber nicht?
Darauf gekommen bin ich weil es in /var/log/sssd/krb5_child.log diese Fehlermeldung gab:
privileged_krb5_setup: Failed to set real GID: 1
VG,
Dorian
Ahaaaa! @thomas kann es sein, dass LINBO die extended attributes (xattrs) beim Sync unterschlägt?
Auf dem funktionierenden master-client:
root@server-test01:/home/linuxadmin# getcap /usr/libexec/sssd/krb5_child
/usr/libexec/sssd/krb5_child cap_dac_read_search,cap_setgid,cap_setuid=p
Auf dem geclonten client:
root@server-test03:/var/log/sssd# getcap /usr/libexec/sssd/krb5_child
(leerer Output)
Das würde die Problematik erklären!
Edit: Jawoll, das ist das Problem! Ich habe eben auf meinem Masterclient einen rotstart gemacht und jetzt fehlen dort die caps auch.
Also: das Problem ist, dass LINBO die extended file attributes beim Sync liegen lässt und sie so im Image fehlen. Dadurch hat das sssd krb5_child nicht die nötigen capabilities, um unter den erhöhten Sicherheitsvorkehrungen in systemd zu starten. Mit kerberos oder KVNO hat das Ganze nichts zutun.
@thomas du musst also in LINBO einbauen, dass die xattrs auch synchronisiert werden
VG,
Dorian
Hallo Dorian,
danke für die Info. Krass, rsync & extended attributes hatte ich eh auf der Liste, aber dass das in dem Fall eine Rolle spielt, fiel mir halt nicht im Traum ein. 
Dann muss ich ja meinen Ansatz nicht mehr weiterverfolgen. Habe aber auf jeden Fall ne Menge dabei gelernt.
Neues Linbo-Paket mit rsync fix ist im Zulauf.
VG, Thomas
2 „Gefällt mir“
Super 
Dann werd ich mal noch die Kleinigkeiten fixen und das Problem im Check integrieren.
VG,
Dorian
2 „Gefällt mir“
Hallo Thomas, hallo Dorian,
ich habe das neue Linbo installiert, meinen Musterclient mit linuxmuster-linuxclient7 setup neu aufgenommen, mit linuxmuster-linuxclient7 prepare-image das Image vorbereitet und ein neues Image erstellt.
Was soll ich sagen, auf meinen beiden Proxmox-Clients in der Schule klappts
Demnächst teste ich, ob ich das Image auf eine lmn73 auf meinem Laptop installieren kann…
Euch beiden schon jetzt vielen Dank…
Gruß
Mathias
1 „Gefällt mir“
Hallo zusammen,
Vielen Dank euch drei für die tolle Zusammenarbeit !
Gruß
Arnaud
Version v1.0.12 ist veröffentlicht, siehe: LMN 7.3 Updates - #47 von dorian
Ich habe alles ausgiebig getestet und keine Probleme finden können. Falls doch noch was auftaucht, sagt Bescheid.
VG
Dorian
2 „Gefällt mir“
Hallo zusammen,
ja, auch bei sind die letzten Tests abgeschlossen. Läuft alles
Gruß
Mathias
Hey ihr drei !
Das ist ja mal wieder eine super Klasse Zusammenarbeit.
Bravissimo 
Grüße Ralf
Ganz Herzlichen Dank, @thomas, @dorian und @rettich, dass Ihr so hartnäckig drangeblieben seid. Ich habe die neuen Pakete auf dem Server installiert, meinen Debian-Trixie-Client vom Ende der Sommerferien aktualisiert, das Paket sssd-krb5-common neu installiert, den Domain-Join via linuxmuster-linuxclient7 setup wiederholt, ein Image erstellt und das auf einen anderen Rechner übertragen. Auch an dem geklonten Rechner war die Anmeldung möglich.
Lediglich die Netzlaufwerke waren nicht mehr verbunden, da ich ja manuell versucht hatte, die Leerzeichen in den Pfaden loszuwerden. Mein Verzeichnis sieht so aus:
$ ls -al media
insgesamt 8
drwxr-xr-x 8 root root 4096 10. Nov 09:28 **.**
drwx------ 16 eb domain users 4096 10. Nov 09:34 **..**
drwx------ 2 eb domain users 0 20. Aug 11:14 **'eb (H:)'**
drwx------ 2 eb domain users 0 17. Sep 2020 **'ISO (R:)'**
drwx------ 2 eb domain users 0 17. Sep 2020 **'Programs (K:)'**
drwx------ 2 eb domain users 0 20. Aug 13:59 **'Projects (P:)'**
drwx------ 2 eb domain users 0 10. Jan 2022 **'Shares (T:)'**
drwx------ 2 eb domain users 0 9. Sep 16:31 **'Students-Home (S:)'**
Kann man mittlerweile offiziell alle Pfade konfigurieren, um die Laufwerksbuchstaben und die Leerzeichen loszuwerden?
Hallo @ebert ,
bei den Laufwerken, die per GPP eingebunden werden, kannst du in der WebUI unter Client-Konfiguration > Laufwerke den Haken bei „Buchstabe anzweigen“ entfernen, dann werden die Buchstaben nicht mehr gesetzt:
Beim Home-Verzeichnis gibt es noch keinen offiziellen Weg. Siehe daszu issues #33 und #32
VG
Dorian
Vielen Dank, @dorian, für den Hinweis bezüglich der Laufwerksbuchstaben.
Jetzt scheint sich aber doch noch ein anderes Problem aufgetan zu haben. Ich habe ein weiteres Basisimage nach linuxmuster-linuxclient7 prepare-image erstellt und auf den zweiten Client verteilt. Auf dem Muster-Client funktioniert die Anmeldung danach noch, auf dem zweiten Client aber nicht. In der Konsole liefert die Überprüfung:
~$ sudo linuxmuster-linuxclient7 status
[sudo] Passwort für linuxadmin:
[INFO] #### linuxmuster-linuxclient7 status ####
[INFO] Linuxmuster-linuxclient7 is setup!
[INFO] Checking sssd krb5_child capabilities...
[INFO] Testing if domain is joined...
[INFO] Checking joined domains
[INFO] Joined domains:
[INFO] * lmn.ohgw.de
[INFO] Testing if the domain join actually works
[INFO] * Checking if the group "domain users" exists
[ERROR] The "domain users" group does not exists! Users wont be able to log in!
[ERROR] This is sometimes related to /etc/nsswitch.conf.
===============================================================================================
This Computer is joined to a domain, but it was not possible to authenticate
to the domain controller. There is an error with your domain join! The login WILL NOT WORK!
Please try to re-join the domain using 'linuxmuster-linuxclient7 setup' and create a new image.
===============================================================================================
Was kann da schief gelaufen sein?