Debian 12 | Fehler bei Domänenbeitritt

Ich versuche mich gerade an einem Debian-12-Image. Bin nach der Ubuntu-Installationsanleitung vorgegangen.

Bei der Installation von linuxmuster-linuxclient7 fehlt die Kerberos-Realm-Abfrage.

Anschließend läuft sssd.service nicht. Statusausgabe:

○ sssd.service - System Security Services Daemon
     Loaded: loaded (/lib/systemd/system/sssd.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/sssd.service.d
             └─override.conf
     Active: inactive (dead)
  Condition: start condition failed at Fri 2024-10-04 18:49:10 CEST; 2s ago
             ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met
             └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not met

Okt 04 18:43:39 c307-s01 systemd[1]: sssd.service - System Security Services Daemon was skipped because no trigger condition checks were met.
Okt 04 18:48:18 c307-s01 systemd[1]: sssd.service - System Security Services Daemon was skipped because no trigger condition checks were met.
Okt 04 18:48:18 c307-s01 systemd[1]: sssd.service - System Security Services Daemon was skipped because no trigger condition checks were met.
Okt 04 18:48:18 c307-s01 systemd[1]: sssd.service - System Security Services Daemon was skipped because no trigger condition checks were met.
Okt 04 18:48:18 c307-s01 systemd[1]: sssd.service - System Security Services Daemon was skipped because no trigger condition checks were met.
Okt 04 18:48:18 c307-s01 systemd[1]: sssd.service - System Security Services Daemon was skipped because no trigger condition checks were met.
Okt 04 18:48:18 c307-s01 systemd[1]: sssd.service - System Security Services Daemon was skipped because no trigger condition checks were met.
Okt 04 18:48:18 c307-s01 systemd[1]: sssd.service - System Security Services Daemon was skipped because no trigger condition checks were met.
Okt 04 18:48:19 c307-s01 systemd[1]: sssd.service - System Security Services Daemon was skipped because no trigger condition checks were met.
Okt 04 18:49:10 c307-s01 systemd[1]: sssd.service - System Security Services Daemon was skipped because no trigger condition checks were met.

Wahrscheinlich ist das die Ursache dafür, dass sudo linuxmuster-linuxclient7 setup folgenden Fehler liefert:

[INFO] #### linuxmuster-linuxclient7 setup ####
[INFO] Cleaning sssd cache.
[INFO] Stopping sssd
sh: 0: getcwd() failed: No such file or directory
[INFO] Deleting old kerberos tickets.
[INFO] Cleaning / leaving all domain joins
[INFO] -> Done!
[INFO] Deleting krb5.keytab if it exists ... 
[INFO] Deleting old CA certificate if it exists ... 
[INFO] Deleting /etc/linuxmuster-linuxclient7/network.conf if exists ...
[INFO] Trying to discover available domains...
[ERROR] Failed to discover available domains!
[ERROR] Could not discover any domain!

================================================================================
The setup FAILED, see previous errors!
Plase check your configuration and try again.
================================================================================

Was kann ich tun?

Update

  • Mit kubuntu 22.04 hatte der Domänenbeitritt funktioniert. Es scheint also am Client (Debian vs. kubuntu) und nicht am Server zu liegen.
  • Die Zeiten an Client und Server stimmen überein.
  • DNS funktioniert. nslookup lmn.ohgw.de liefert 10.0.0.1.
  • Mit der /usr/lib/x86_64-linux-gnu/sssd/conf/sssd.conf startet zwar der Service, aber die Domäne wird trotzdem nicht gefunden.
  • sudo realm discover liefert realm: Kein Standardbereich entdeckt als Ausgabe.

Hallo Matthias,

es gibt aus der Community einen Debian 12 Client mit allem drin.
Ich hab den in den letzten Wochen erst für meine Schule angepaßt, nach der Anleitung von Mathias.
Das ging wunderbar in einem durch.
Am Ende noch
linuxmuster-linuxclient7 setup
gemacht und der Domain beigetreten: läuft.
Willst du den mal versuchen?

Du kannst ihn hier downloaden (in einem .zip mit Anleitung dabei).
Link ist 2 Wochen gültig.

Ansonsten fallen mir zur Domänenaufnahme mit dem Linuxclient folgende Stolpersteine ein:

  1. Client muss aufgenommen sein in der devices.csv (und importiert)
  2. der Rechnernamen lokal muß übereinstimmen mit dem in der devices.csv (sowohl /etc/hosts als auch /etc/hosname )
  3. die Systemzeit muss mit der des Servers übereinstimmen stimmen
  4. die IP darf nicht im freien DHCP Lease des Servers liegen (auch wenn die IP Adresse so in der devices.csv steht).

LG

Holger

Hallo Holger,

vielen Dank für die ausführliche Antwort.

Den Client von Mathias kann ich wahrscheinlich nicht ohne Weiteres verwenden. Ich bin nämlich auf UEFI angewiesen, da ich an meinen Rechnern keinen Legacy-Modus mehr habe. Zudem habe ich NVME-SSDs. Ich vermute mal, das lässt sich nach der Debian-Installation auch nicht mehr so einfach umbiegen.

Ich sehe mir morgen nochmal /etc/hosts und /etc/hostname an. Alle anderen Stolpersteine kann ich schon ausschließen.

Viele Grüße
Matthias

Hallo Matthias,

das sehe ich beides anders.
NVME und SATA mische ich schon seit etlichen Jahren. Die Partitionen werden durch Linbo mit Labeln versehen und in der fstab stehen Label statt Devices /dev/sdaX oder /dev/nvme0n1pX, schon ist es dem Linux egal.
Früher hab ich noch den NVME Clients eigene fstabs hingesynct durch den Postsync: inzwischen ist da snicht mehr nötig.

Und Legacy und UEFI ist auch wurscht, solange Label da sind (bei UEFI gibt es Partitionen, die man bei Legacy eher nicht hat).
Wenn linbo kein Parameter wie „nowarmstart“ mitgegeben wird, dann wird das Linux sowiso ohne reboot von linbo direktgebootet.
Und wenn du den reboot willst/brauchst, dann klappt das vielelicht einfach so: falls nciht: einmal den Linuxboot mit der supergrubdisk reparieren, Image erstellen, sollte klappen.

„Versuch macht Kluch“ hätte ich gesagt :slight_smile:

LG
Holger

Hallo,

du erhälst als Fehlermeldung

Hast du mal geschaut was die Erkennung als Grundlage nimmt und was bei dir da an Werten auftauchen sollte und welche Werte stattdessen auftauchen? Du erwähnst eine sssd.conf, aber wir wissen nichts über den Inhalt oder ob du den überprüft hast.

Sind dir Domain join · linuxmuster/linuxmuster-linuxclient7 Wiki · GitHub und Troubleshooting · linuxmuster/linuxmuster-linuxclient7 Wiki · GitHub bekannt? Im Schritt 9 steht, dass /etc/sssd/sssd.conf angepasst/erstellt(?) wird. Hast du geprüft, ob die Zeitangaben der Ereignisse dazu passen? Das start condition failed at Fri 2024-10-04 18:49:10 beim sssd.service könnte ja von einem vorangegangen Durchlauf sein.

Ich habe bei SSSD bisher nur an der Oberfläche gekratzt durch Überfliegen der Dokumentation und ein Test-Setup (nicht im LMN-Umfeld). Aber soviel habe ich mitbekommen: Zum Auffinden der Domain kommt realmd zum Einsatz. Das braucht als Indiz eine DNS-Domain und dafür wird die genommen, welche in Konfigurationsdateien (von SSSD oder realmd, vielleicht auch andere) steht oder die, welche vom DHCP-Server in den Options für die Clients mitgeliefert wird. Auf Using with Active Directory - realmd - freedesktop.org gibt es ein Befehl für einen Test. Man kann SSSD auch vorab konfigurieren statt es raten zu lassen. Ubuntu hat auf How to set up SSSD with Active Directory - Ubuntu Server documentation ein How-To veröffentlicht. Dort ist auch noch eine Troubleshooting-Seite verlinkt, wo es ebenfalls um DNS geht.

Viele Grüße
Buster