FreeIPA installieren: Vom ersten Server bis zum angebundenen Linux-Client

Ziel dieses Beitrags

Dieser Beitrag macht Technikthema als praktisches Betriebsthema greifbar: Du erkennst den Nutzen, die wichtigsten Entscheidungen und die Prüfpunkte, die vor produktiver Nutzung stimmen müssen.

Die konkrete Lab-Basis für diese Reihe ist Fedora Linux 44 mit ipa01.example.test, client01.example.test und dem Realm EXAMPLE.TEST. Damit bleiben die FreeIPA-Beispiele über Installation, Clients, Policies, sudo, Keytabs, Updates, Backup, Recovery und Hochverfügbarkeit hinweg einheitlich nachvollziehbar.

Voraussetzungen

Plane DNS, Zeit, Hostnamen, Realm, Admin-Konten und Client-Zugriff vor der Installation. FreeIPA und Red Hat IdM reagieren empfindlich auf falsche Namensauflösung und Zeitdrift.

Was ist FreeIPA?

FreeIPA ist eine Identity-Management-Plattform für Linux-Umgebungen. Sie bündelt zentrale Benutzer, Gruppen, Hosts, Kerberos-Authentifizierung, Zertifikate, Client-Enrollment und Richtlinien in einer gemeinsamen Verwaltungsoberfläche. Wer von einzelnen lokalen Accounts, handgepflegten SSH-Zugängen oder gewachsenen LDAP-Insellösungen kommt, bekommt damit einen gemeinsamen Identity-Kern.

LDAP beantwortet, welche Objekte es gibt: Benutzer, Gruppen, Hosts und Services. Kerberos beantwortet, wie sich Benutzer und Dienste authentifizieren. SSSD ist die Brücke auf dem Linux-Client: Es sorgt dafür, dass zentrale Benutzer in `id`, `getent`, PAM und NSS erscheinen, obwohl sie nicht lokal in `/etc/passwd` stehen. HBAC regelt später, wer auf welchen Host darf. sudo regelt, was ein Benutzer dort privilegiert ausführen darf.

• Komponente Aufgabe
• LDAP / 389-DS Identitäten, Gruppen, Hosts und Directory-Daten speichern
• Kerberos KDC Authentifizierung über Tickets statt wiederholte Passworteingabe
• SSSD Linux-Client an FreeIPA anbinden, NSS/PAM nutzen und cachen
• Dogtag CA Interne Zertifizierungsstelle für FreeIPA-Zertifikate
• FreeIPA Management-Layer, der LDAP, Kerberos, CA, DNS-Optionen und Policies verbindet

Das Lab

Wir bauen ein kleines, nachvollziehbares Lab mit einem FreeIPA-Server und einem Linux-Client. Die Domain und der Realm sind absichtlich generisch. Verwenden Sie für eigene Tests keine produktive DNS-Zone und keine echte Kundendomain.

• Lab domain: example.test
• Realm: EXAMPLE.TEST
• ipa01.example.test FreeIPA server, CA, LDAP, Kerberos, Web UI
• client01.example.test Linux client enrolled into the IPA domain
• External DNS:
• ipa01.example.test -> server IP
• client01.example.test -> client IP
• server IP -> ipa01.example.test
• client IP -> client01.example.test

Dieses Lab installiert FreeIPA ohne integriertes DNS. Das ist in vielen Unternehmensumgebungen realistisch, weil DNS bereits separat betrieben wird. Integriertes FreeIPA-DNS ist trotzdem legitim und oft der einfachere Einstieg, besonders wenn die Lab-Zone komplett an FreeIPA delegiert wird.

Systemanforderungen und Plattformwahl

FreeIPA ist kein kleiner Daemon, sondern ein Verbund aus Directory Server, Kerberos, HTTPD, Dogtag CA, SSSD-naher Clientintegration und Management-API. Für ein Lab reichen typischerweise 2 vCPU, 4 GB RAM und 20 GB Disk komfortabel aus. Für produktive Umgebungen richtet sich die Dimensionierung nach Benutzerzahl, Gruppen, Hosts, Zertifikatsnutzung, Replikation und Betriebsmodell.

Dieser Beitrag verwendet durchgehend ein Fedora-Lab: ipa01.example.test als FreeIPA-Server und client01.example.test als angebundenen Linux-Client. Upstream nennt Fedora und Red Hat Enterprise Linux als unterstützte Plattformen. Fedora liefert sehr aktuelle FreeIPA-Pakete und eignet sich gut für nachvollziehbare Labs und technische Validierung. Für langfristigen Enterprise-Betrieb mit Hersteller-Support, Lifecycle und Security Advisory Handling sollte Red Hat Identity Management auf RHEL gesondert bewertet werden.

Red Hat Identity Management ist die von Red Hat supportete Enterprise-Ausprägung dieser IdM-Technologie für RHEL-Umgebungen. Wer FreeIPA nicht nur im Lab, sondern mit Hersteller-Support, Lifecycle, Security Advisory Handling und Enterprise-Betrieb einsetzen will, sollte Red Hat IdM als Zielplattform prüfen.

• Fedora: Plattform dieses Labs, mit aktuellem FreeIPA-Stand und konsistentem Server-/Client-Aufbau.

• Red Hat IdM auf RHEL: prüfen, wenn Vendor Support, Lifecycle und Enterprise-Betrieb im Vordergrund stehen.

• Andere Distributionen: nicht Teil dieses Labs; vor produktiver Nutzung separat mit Paketstand, Supportmodell und Client-Verhalten validieren.

• Plattformwechsel: nicht mit diesem Installationslauf vermischen, sondern als eigenes Migrations- oder Replica-Szenario planen.

Server vorbereiten

Setzen Sie zuerst den festen Hostnamen. FreeIPA und Kerberos verlassen sich auf stabile Namen. Ein dynamischer DHCP-Hostname oder ein FQDN, der auf localhost zeigt, ist eine sehr häufige Fehlerquelle.

sudo hostnamectl set-hostname ipa01.example.test
hostname -f

Prüfen Sie Forward- und Reverse-DNS. Der FQDN muss auf die reale Serveradresse zeigen, und der PTR-Record sollte wieder genau diesen FQDN liefern. Wenn Sie im Lab `/etc/hosts` verwenden, darf der FreeIPA-FQDN nicht in der localhost-Zeile stehen.

hostnamectl status
hostname -f
dig +short ipa01.example.test A
dig +short -x <SERVER-IP>
getent hosts ipa01.example.test

• 127.0.0.1 localhost localhost.localdomain
• ::1 localhost localhost.localdomain
• <SERVER-IP> ipa01.example.test ipa01

Pakete installieren

Im Fedora-Lab werden die FreeIPA-Serverpakete direkt aus den Fedora-Repositories installiert. Installieren Sie hier bewusst kein DNS-Paket, weil dieses Lab externes DNS nutzt und Server sowie Client einheitlich auf Fedora basieren.

sudo dnf upgrade --refresh
sudo dnf install freeipa-server bind-utils chrony firewalld

sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-rpms
sudo subscription-manager repos --enable=rhel-9-for-x86_64-appstream-rpms
sudo dnf update
sudo dnf install ipa-server bind-utils chrony firewalld

sudo dnf update
sudo dnf install ipa-server bind-utils chrony firewalld

Zeit und Firewall prüfen

Kerberos toleriert nur begrenzte Zeitabweichung. Stellen Sie sicher, dass chronyd läuft und der Server eine saubere Zeitquelle nutzt. Zeit ist hier keine Nebensache, sondern Teil der Authentifizierung.

sudo systemctl enable --now chronyd
timedatectl
chronyc tracking
chronyc sources -v

Öffnen Sie auf dem Server die FreeIPA-Dienste. Ohne integriertes DNS reicht der Firewalld-Service `freeipa-4`; DNS-Port 53 wird nur benötigt, wenn der FreeIPA-Server selbst DNS bereitstellt.

sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=freeipa-4
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

FreeIPA Server installieren

Für den ersten Aufbau ist der interaktive Installer sinnvoll. Er fragt Domain, Realm, Hostname, Directory-Manager-Passwort, IPA-Admin-Passwort und CA-Optionen ab. Der Realm wird üblicherweise in Großbuchstaben geschrieben, also `EXAMPLE.TEST`.

sudo umask 0022
sudo ipa-server-install

Für spätere Wiederholung kann dieselbe Installation auch nicht-interaktiv beschrieben werden. Verwenden Sie in echter Automation keine Klartextpasswörter in Shell-History oder Git.

sudo ipa-server-install \
  --realm=EXAMPLE.TEST \
  --domain=example.test \
  --hostname=ipa01.example.test \
  --ds-password='<DIRECTORY-MANAGER-PASSWORD>' \
  --admin-password='<IPA-ADMIN-PASSWORD>' \
  --unattended

Installation validieren

Verlassen Sie sich nicht nur auf die Meldung des Installers. Prüfen Sie Dienste, Kerberos und die IPA-API. `kinit admin` holt ein Kerberos Ticket für den administrativen IPA-Benutzer; `klist` zeigt, ob dieses Ticket vorhanden ist.

sudo ipactl status
kinit admin
klist
ipa user-find
ipa config-show

Danach öffnen Sie die Web UI über `https://ipa01.example.test/ipa/ui/`. Melden Sie sich mit `admin` an. In der Oberfläche sehen Sie Users, Groups, Hosts, HBAC, sudo und Certificates. Für diesen Einstieg reichen Users, Groups und Hosts.

ipa01.example.test/ipa/ui/

ipa01.example.test/ipa/ui/#/e/user/search

Ersten Benutzer und erste Gruppe anlegen

Ein FreeIPA-Benutzer ist ein zentrales Directory-Objekt. Er steht nicht lokal auf jedem Server, kann aber nach Client-Enrollment auf Linux-Systemen sichtbar werden. Eine Gruppe bündelt Benutzer für spätere Berechtigungen, Rollen oder Zugriffskonzepte.

Wichtig: Ein Passwort, das ein Administrator für einen Benutzer setzt, ist ein Initialpasswort. FreeIPA fordert den Benutzer beim ersten Kerberos-Login zur Änderung auf. Das ist gewollt und sollte im Lab bewusst einmal getestet werden.

kinit admin
ipa user-add max.mustermann \
  --first=Max \
  --last=Mustermann \
  --email=max.mustermann@example.test
ipa passwd max.mustermann

ipa group-add linux-users --desc='Linux users'
ipa group-add-member linux-users --users=max.mustermann
ipa group-show linux-users

ipa01.example.test/ipa/ui/#/e/user/search

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

Client vorbereiten

Der Client braucht ebenfalls einen stabilen FQDN, funktionierendes DNS, korrekte Zeit und Netzwerkzugriff zum FreeIPA-Server. Wenn Discovery über DNS-SRV-Records nicht eingerichtet ist, geben wir Server, Domain und Realm beim Client-Installer explizit an.

sudo hostnamectl set-hostname client01.example.test
hostname -f
dig +short ipa01.example.test A
dig +short client01.example.test A
dig +short -x <CLIENT-IP>
sudo systemctl enable --now chronyd
chronyc tracking

Client-Pakete installieren

Auf dem Client installieren Sie `ipa-client`. Dieses Paket bringt die nötigen Clientwerkzeuge und Abhängigkeiten wie SSSD mit. `oddjob-mkhomedir` ist praktisch, damit beim ersten Login ein Home-Verzeichnis erzeugt werden kann.

sudo dnf upgrade --refresh
sudo dnf install freeipa-client bind-utils chrony oddjob-mkhomedir

sudo dnf update
sudo dnf install ipa-client bind-utils chrony oddjob-mkhomedir

Client Enrollment ausführen

Beim Enrollment wird der Host in FreeIPA registriert. Der Installer konfiguriert Kerberos, SSSD, CA Trust, NSS/PAM-Integration und die Host-Keytab. Danach ist der Client Mitglied der IPA-Domain.

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

Client testen

Jetzt muss der zentrale Benutzer auf dem Client sichtbar sein. `id` und `getent` prüfen die Linux-Namensauflösung über NSS/SSSD. `kinit` prüft Kerberos. `ipa host-show` zeigt, dass der Client als Host-Objekt in FreeIPA existiert.

Wenn Sie das Benutzerpasswort zuvor als Administrator gesetzt haben, ändern Sie es zuerst einmal als Benutzer. Danach holen Sie mit dem neuen Passwort erneut ein Kerberos-Ticket.

kinit max.mustermann
# Initialpasswort eingeben, das der Administrator gesetzt hat.
# Wenn FreeIPA zur Änderung auffordert, das neue Benutzerpasswort setzen.
kdestroy
kinit max.mustermann
klist

id max.mustermann
getent passwd max.mustermann
kinit max.mustermann
klist
systemctl status sssd --no-pager
ipa host-show client01.example.test

Der Login-Test ist der Moment, in dem FreeIPA praktisch greifbar wird: Der Benutzer meldet sich auf einem Linux-Host an, obwohl er dort nicht lokal angelegt wurde.

ssh max.mustermann@client01.example.test
pwd
id
klist

ipa01.example.test/ipa/ui/#/e/host/search

client01.example.test

SSSD verstehen

SSSD verbindet den Linux-Client mit FreeIPA. NSS beantwortet Fragen wie: Welche UID hat dieser Benutzer? PAM hilft beim Login. Kerberos übernimmt die Authentifizierung. Der IPA Provider in SSSD spricht mit der FreeIPA-Umgebung und cached Identitäten sowie je nach Konfiguration auch Credentials.

Das erklärt, warum `id max.mustermann` funktioniert, obwohl `max.mustermann` nicht in `/etc/passwd` steht. Der Client fragt SSSD, SSSD fragt FreeIPA oder nutzt seinen Cache. Dieser Cache hilft bei kurzen Netzwerkproblemen, ersetzt aber keine saubere Hochverfügbarkeit.

Kerberos in diesem Lab

Kerberos vermeidet, dass Dienste immer wieder Passwörter sehen müssen. Ein Benutzer authentifiziert sich gegen den KDC und erhält ein Ticket Granting Ticket. Daraus können Service Tickets abgeleitet werden. `kinit` fordert ein Ticket an, `klist` zeigt es an.

• User
• | password or credential
• Kerberos KDC
• | Ticket Granting Ticket (TGT)
• Client
• | service ticket
• Service

Kann ich später einfach das OS wechseln?

Einen FreeIPA-Server sollte man nicht wie einen stateless Webserver behandeln. FreeIPA speichert Directory-State, Kerberos-Daten, CA-State, Host- und Service-Principals, Serverrollen, Zertifikate und Replikationsbeziehungen. Das System merkt sich nicht einfach nur eine Distribution, aber viele Komponenten sind an Hostname, Rollen, Zertifikate, Topology und installierte Plattformpakete gekoppelt.

Bei normalen Paketupdates innerhalb des Fedora-Labs folgt man dem Fedora-Updatepfad und prüft danach FreeIPA, Kerberos, SSSD und Client-Login erneut. OS-Major-Upgrades oder ein Wechsel der Zielplattform gehören nicht in denselben Installationslauf, sondern in ein eigenes Migrations- oder Replica-Replacement-Szenario.

• Existing FreeIPA replica
• add new replica on target platform
• wait for replication
• transfer and verify roles
• run health checks
• cleanly remove old replica

Wenn ein Servername wiederverwendet werden muss, entfernen Sie den alten Server zuerst sauber aus der Topology, warten Replikation ab, prüfen, dass keine alten Rollen oder Segmente übrig sind, und installieren danach die neue Replica. Einfach denselben Hostnamen neu installieren und hoffen, dass FreeIPA den Zustand korrekt überschreibt, ist riskant.

Was kommt nach diesem Lab?

Ein einzelner FreeIPA-Server ist gut zum Lernen, aber noch keine Enterprise-Hochverfügbarkeit. In weiteren Tech-Beiträgen zeigen wir FreeIPA-Replicas und Multi-Site-Design, HBAC und sudo, deklarative Verwaltung mit Ansible/AWX, Keycloak-Anbindung, Backup/Restore, Monitoring und PKI-Design.

Lesen Sie chronologisch weiter mit FreeIPA in großen Umgebungen: Architektur, Hochverfügbarkeit, HBAC, sudo und Keycloak. Dort geht es um den Schritt vom ersten Lab zu einer belastbaren Enterprise-Architektur.

Der wichtigste nächste Schritt ist nicht sofort Automation. Bauen Sie zuerst manuell ein Lab, verstehen Sie Benutzer, Gruppen, Hosts, Kerberos, SSSD und Enrollment. Danach ist Automation wesentlich leichter zu prüfen, weil klar ist, welche Directory-Objekte erzeugt und verändert werden.

Professionelle Unterstützung

Betrieb und Validierung

Für den produktiven Betrieb reicht eine erfolgreiche Installation allein nicht aus. Prüfe Dienste, Logs, Netzwerk, Anmeldung, Updates, Backup und Wiederherstellung so, dass der Zustand wiederholbar und für andere Administratoren nachvollziehbar bleibt.

Produktionscheckliste

• Ziel, Scope und Verantwortlichkeiten sind dokumentiert.
• DNS, TLS, Netzwerk, Accounts und Berechtigungen sind geprüft.
• Installation oder Änderung wurde mit UI- und CLI-Signalen validiert.
• Backup, Monitoring, Updates und Rollback sind vor produktiver Nutzung geklärt.
• Lizenzen, Supportwege und Professional Services sind für den Betrieb eingeplant.

Technische Abnahme

Die Installation ist erst abgeschlossen, wenn Server, Realm, Web-UI, Kerberos und der erste Client technisch nachgewiesen sind. Ein erreichbares Web-UI allein reicht nicht als Abnahme.

Was nicht übersprungen werden sollte

• Keine produktive Kundendomain für Labs verwenden.

• DNS und Zeit vor der Installation prüfen, nicht erst bei Fehlern.

• Den ersten Client als Pflichtnachweis behandeln.

• Admin-Zugang, Recovery-Zugang und Backup-Pfad bereits ab Teil 1 mitdenken.