Kurzüberblick

Part 1 hat den FreeIPA-Server aufgebaut. Part 2 beginnt dort, wo der eigentliche Linux-Betrieb anfängt: Ein Client wird an FreeIPA angebunden, löst zentrale Benutzer und Gruppen auf, erhält Kerberos-Tickets und erlaubt SSH-Logins mit zentralen Identitäten.

Getestet wurde in einem frischen Fedora-44-Lab mit FreeIPA 4.13.3, SSSD 2.13.1, SELinux Enforcing, funktionierendem Forward- und Reverse-DNS sowie einer getrennten Server-/Client-VM. Die Zeitversatz-Prüfung blieb im Lab nicht eindeutig reproduzierbar; Kerberos-Clock-Skew wird deshalb nur als dokumentierte Anforderung eingeordnet, nicht als hier bewiesener Fehlerfall.

Identity-Serie: Wo wir stehen

Dieser Beitrag ist Teil 2 der Identity-Serie mit FreeIPA und Keycloak. Teil 1 behandelt die Installation des ersten FreeIPA-Servers. Dieser Teil zeigt den praktischen Client-Weg: ipa-client-install, SSSD, NSS, PAM, Kerberos, SSH, Cache und Recovery.

https://ipa01.example.test/ipa/ui/

Der Test beginnt am FreeIPA Web UI. Der Screenshot zeigt nur die isolierte Labumgebung, keine produktiven Zugangsdaten.

https://ipa01.example.test/ipa/ui/

Nach der Anmeldung ist die FreeIPA-Administration erreichbar. Damit ist die Server-Seite für die Client-Prüfungen sichtbar.

Lab-Aufbau

Das Lab bestand aus ipa01.example.test als FreeIPA-Server und client01.example.test als angebundenem Linux-Client. Alle Screenshots und Befehle stammen aus dieser isolierten Testumgebung.

bash
Server:        ipa01.example.test
Client:        client01.example.test
Domain:        example.test
Realm:         EXAMPLE.TEST
Distribution:  Fedora 44
FreeIPA:       4.13.3
SSSD:          2.13.1
SELinux:       Enforcing
https://ipa01.example.test/ipa/ui/#/e/user/search

Der zentrale Benutzer testuser existiert in FreeIPA und wird später vom Linux-Client über SSSD/NSS aufgelöst.

https://ipa01.example.test/ipa/ui/#/e/group/details/lab-users

Die Gruppe lab-users belegt die zentrale Gruppenverwaltung und die später sichtbare POSIX-Gruppenauflösung am Client.

Was beim Client-Enrollment passiert

ipa-client-install ist nicht nur ein Paket-Setup. Der Client wird als Host in FreeIPA registriert, bekommt eine Host-Identität, Kerberos-Konfiguration, SSSD-Domain-Konfiguration und die Integration in NSS und PAM. Danach fragt Linux Benutzer- und Gruppeninformationen nicht mehr nur lokal ab, sondern über SSSD aus der zentralen Identity-Quelle.

  • NSS löst zentrale Benutzer und Gruppen für Linux-Werkzeuge wie id, getent oder ls auf.

  • PAM nutzt SSSD für Anmeldung, Passwortprüfung und optionales Home-Verzeichnis beim ersten Login.

  • Kerberos stellt Tickets für Benutzer und Dienste im Realm aus.

  • SSSD puffert Identitäten und, nach erfolgreicher Anmeldung, Authentifizierungsdaten für definierte Offline-Szenarien.

Voraussetzungen

Vor dem Enrollment müssen Name Resolution, Zeit und Paketbasis stimmen. Besonders wichtig sind der korrekte FQDN des Clients, erreichbare FreeIPA-DNS-Einträge und synchronisierte Zeit.

bash
hostnamectl
getent hosts ipa01.example.test
dig +short ipa01.example.test
dig +short -x <client-ip>
timedatectl
chronyc tracking
getenforce

FreeIPA Client installieren

Auf Fedora wird der Client über die FreeIPA-Client-Pakete installiert. Zusätzlich sind SSSD, Kerberos-Werkzeuge und oddjob-mkhomedir relevant, damit zentrale Benutzer sauber anmelden und Home-Verzeichnisse erhalten können.

bash
sudo dnf install -y freeipa-client sssd oddjob-mkhomedir krb5-workstation openssh-server

Linux-Client an FreeIPA anbinden

Im Lab wurde das Enrollment automatisiert ausgeführt. Interaktiv sieht der zentrale Befehl so aus; reale Kennwörter gehören nicht in Skripte, Screenshots oder Artikel.

bash
sudo ipa-client-install \
  --domain=example.test \
  --realm=EXAMPLE.TEST \
  --server=ipa01.example.test \
  --mkhomedir \
  --enable-dns-updates

Enrollment auf dem FreeIPA-Server prüfen

Nach dem Enrollment muss der Client als Host in FreeIPA sichtbar sein. Das ist der schnellste Gegencheck, ob der Server die Host-Identität kennt.

bash
ipa host-show client01.example.test
https://ipa01.example.test/ipa/ui/#/e/host/search

client01.example.test ist als Host in FreeIPA eingetragen. Das ist der sichtbare Server-Nachweis für das abgeschlossene Enrollment.

SSSD: Die Verbindung zwischen Linux und FreeIPA

SSSD ist die zentrale Brücke zwischen Linux und FreeIPA. Es spricht mit der Identity-Quelle, stellt NSS- und PAM-Informationen bereit, verarbeitet Kerberos-Bezüge und verwaltet den lokalen Cache. Für den Betrieb sind systemctl und sssctl die wichtigsten ersten Werkzeuge.

bash
systemctl status sssd
sssctl domain-status example.test
sssctl user-checks testuser
bash
systemctl is-active sssd
sssctl domain-status example.test


active
Online status: Online


Active servers:
IPA: ipa01.example.test


Discovered IPA servers:
- ipa01.example.test

Benutzer über NSS auflösen

Wenn NSS korrekt über SSSD arbeitet, sehen Standard-Linux-Werkzeuge den zentralen Benutzer. Genau das unterscheidet ein funktionierendes Enrollment von einem bloß installierten Client-Paket.

bash
id testuser
getent passwd testuser
bash
id testuser
getent passwd testuser


uid=376600003(testuser) gid=376600003(testuser) groups=376600003(testuser),376600004(lab-users),376600005(linux-admins)
testuser:*:376600003:376600003:Test User:/home/testuser:/bin/sh
bash
getent passwd testuser


testuser:*:376600003:376600003:Test User:/home/testuser:/bin/sh

Gruppen und POSIX-Attribute

FreeIPA verwaltet POSIX-Attribute wie UID, GID, Login-Shell und Gruppenmitgliedschaften zentral. Der Client löst diese Werte über SSSD auf; lokale Dubletten mit identischen Namen sollten vermieden werden.

bash
getent group lab-users
id testuser

Kerberos-Anmeldung

Kerberos bestätigt, dass der Benutzer im Realm authentifiziert werden kann. kinit holt ein Ticket, klist zeigt das Ergebnis. Im Lab wurde die Ticket-Ausstellung für testuser erfolgreich belegt.

bash
kinit testuser
klist
bash
kinit testuser
klist


Password for testuser@EXAMPLE.TEST:
Ticket cache: KCM:1001
Default principal: testuser@EXAMPLE.TEST


Valid starting       Expires              Service principal
09/19/2026 13:54:16  09/20/2026 13:28:19  krbtgt/EXAMPLE.TEST@EXAMPLE.TEST

PAM, Home-Verzeichnis und SSH

Die Anmeldung am Linux-System läuft über PAM. Mit oddjob-mkhomedir bzw. entsprechender PAM-Integration entsteht das Home-Verzeichnis beim ersten Login. SSH nutzt dadurch denselben zentralen Benutzer wie die lokale Anmeldung.

bash
ssh testuser@client01.example.test
pwd
id
bash
ssh testuser@client01.example.test
pwd
id


testuser
/home/testuser
uid=376600003(testuser) gid=376600003(testuser) groups=376600003(testuser),376600004(lab-users),376600005(linux-admins)

Der zentrale Benutzer kann sich per SSH anmelden; PAM, SSSD und Home-Verzeichnis-Erstellung greifen zusammen.

SSSD Cache und Offline-Verhalten

SSSD kann bereits bekannte Identitäten und nach erfolgreicher Anmeldung auch Authentifizierungsdaten zwischenspeichern. Das bedeutet nicht, dass ein neuer, nie zuvor angemeldeter Benutzer beliebig offline funktioniert. Im Lab wurden Cache-Verhalten, Offline-Authentifizierung nach vorherigem Login sowie Wiederherstellung nach Dienst- und DNS-Problemen geprüft.

bash
sssctl user-checks testuser
sudo systemctl stop sssd
sudo systemctl start sssd
sssctl domain-status example.test

DNS-Ausfall, SSSD-Ausfall und Recovery

Im Lab wurden DNS- und SSSD-Ausfälle kontrolliert geprüft und anschließend zurückgenommen. Erwartbar ist: DNS-Probleme treffen neue Auflösungen und Serverkontakte, während SSSD-Cache nur begrenzte lokale Kontinuität gibt. Nach Wiederherstellung von DNS bzw. SSSD müssen id, getent, kinit und SSH wieder sauber funktionieren.

bash
getent hosts ipa01.example.test
id testuser
kinit testuser
ssh testuser@client01.example.test
sssctl domain-status example.test

Troubleshooting

ipa-client-install findet den Server nicht

Prüfung
dig, getent hosts, SRV Records prüfen
Typische Ursache
DNS oder Suchdomain falsch

id testuser liefert nichts

Prüfung
systemctl status sssd und sssctl domain-status
Typische Ursache
SSSD-Domain nicht aktiv oder FreeIPA nicht erreichbar

kinit schlägt fehl

Prüfung
Realm, Passwort, Zeit und KDC-Erreichbarkeit prüfen
Typische Ursache
Kerberos-Konfiguration, Uhrzeit oder Credentials

SSH-Login funktioniert nicht

Prüfung
PAM, sshd_config, HBAC und Logs prüfen
Typische Ursache
PAM/HBAC/SSHD blockiert die Anmeldung

Home-Verzeichnis fehlt

Prüfung
oddjobd und PAM mkhomedir prüfen
Typische Ursache
Home-Verzeichnis-Erstellung nicht aktiv

Ergebniskontrolle

Client Enrollment

Prüfung
Host client01.example.test in FreeIPA sichtbar
Erwartetes Ergebnis
Host ist zentral registriert
Status
PASS

SSSD

Prüfung
sssctl domain-status example.test
Erwartetes Ergebnis
Domain ist erreichbar und nutzbar
Status
PASS

NSS

Prüfung
id/getent für testuser
Erwartetes Ergebnis
Zentrale Identität wird aufgelöst
Status
PASS

Kerberos

Prüfung
kinit und klist
Erwartetes Ergebnis
Ticket im Realm EXAMPLE.TEST vorhanden
Status
PASS

PAM/SSH

Prüfung
SSH-Login mit testuser
Erwartetes Ergebnis
Zentraler Benutzer kann sich anmelden
Status
PASS

Cache/Recovery

Prüfung
SSSD/DNS-Störungen und Rückkehr
Erwartetes Ergebnis
Nach Recovery funktionieren Auflösung und Login wieder
Status
PASS

Security und Betriebsaspekte

Für Produktion reichen die Lab-Befehle allein nicht aus. Wichtig sind saubere DNS-Zonen, Zeitquellen, SELinux, restriktive Administratorrechte, dokumentierte Enrollment-Prozesse, Logging, Backup des FreeIPA-Servers und ein klares Verfahren für Client-Reenrollment.

Kerberos ist zeitkritisch. Die MIT-Kerberos-Dokumentation beschreibt Clock-Skew als Sicherheitsgrenze. Dieser konkrete Fehlerfall wurde in diesem Lab jedoch nicht zuverlässig reproduziert und wird deshalb nicht als Lab-Nachweis bewertet.

Grenzen dieses Labs

  • Getestet wurde Fedora 44 als Server- und Client-Plattform, keine Cross-Distribution-Matrix.

  • Es wurde kein FreeIPA-Replica- oder HA-Aufbau getestet.

  • HBAC, sudo-Regeln, Passwort-Policies und Lifecycle-Workflows folgen in späteren Lab-Teilen.

  • Der Zeitversatz-Fehlerfall blieb inconclusive und wird nicht als PASS behauptet.

Wie es in der Identity-Serie weitergeht

Der nächste fachliche Schritt ist der zentrale Identity-Lifecycle: Benutzer anlegen, aktivieren, deaktivieren, Gruppen sauber pflegen, Passwort- und Ablaufverhalten testen und diese Zustände auf einem angebundenen Linux-Client nachweisen. Dieser Folgebeitrag ist noch nicht veröffentlicht und wird deshalb hier nicht verlinkt.