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 AufgabeLDAP / 389-DS Identitäten, Gruppen, Hosts und Directory-Daten speichernKerberos KDC Authentifizierung über Tickets statt wiederholte PassworteingabeSSSD Linux-Client an FreeIPA anbinden, NSS/PAM nutzen und cachenDogtag CA Interne Zertifizierungsstelle für FreeIPA-ZertifikateFreeIPA 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.testRealm: EXAMPLE.TESTipa01.example.test FreeIPA server, CA, LDAP, Kerberos, Web UIclient01.example.test Linux client enrolled into the IPA domainExternal DNS:ipa01.example.test -> server IPclient01.example.test -> client IPserver IP -> ipa01.example.testclient 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.
Upstream nennt Fedora und Red Hat Enterprise Linux als unterstützte Plattformen. RHEL bringt planbaren Vendor Support und Enterprise Lifecycle. Fedora liefert sehr aktuelle FreeIPA-Versionen, hat aber einen kürzeren Lifecycle und damit mehr Upgrade-Disziplin. Rocky Linux und AlmaLinux sind Enterprise-Linux-kompatible Distributionen mit passenden Paketen, sollten aber als eigenes Supportmodell bewertet werden. CentOS Stream liegt vor RHEL im Entwicklungsfluss und sollte nicht pauschal wie RHEL behandelt 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: sehr aktueller FreeIPA-Stand, gut für Lab und frühe Features.
RHEL: bevorzugt, wenn Vendor Support, Lifecycle und Enterprise-Betrieb im Vordergrund stehen.
Rocky Linux / AlmaLinux: technisch kompatible Enterprise-Linux-Varianten; Support und Paketstand separat prüfen.
CentOS Stream: näher am kommenden RHEL als an einem klassischen stabilen Downstream; für Produktion bewusst bewerten.
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.testhostname -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 statushostname -fdig +short ipa01.example.test Adig +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
Die Paketnamen unterscheiden sich zwischen Fedora und RHEL-kompatiblen Plattformen. Fedora verwendet `freeipa-server`, RHEL verwendet `ipa-server`. Installieren Sie hier bewusst kein DNS-Paket, weil dieses Lab externes DNS nutzt.
sudo dnf upgrade --refreshsudo dnf install freeipa-server bind-utils chrony firewalld
sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-rpmssudo subscription-manager repos --enable=rhel-9-for-x86_64-appstream-rpmssudo dnf updatesudo dnf install ipa-server bind-utils chrony firewalld
sudo dnf updatesudo 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 chronydtimedatectlchronyc trackingchronyc 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 firewalldsudo firewall-cmd --permanent --add-service=freeipa-4sudo firewall-cmd --reloadsudo 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 0022sudo 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 statuskinit adminklistipa user-findipa 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.
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 adminipa user-add max.mustermann \--first=Max \--last=Mustermann \--email=max.mustermann@example.testipa passwd max.mustermannipa group-add linux-users --desc='Linux users'ipa group-add-member linux-users --users=max.mustermannipa group-show linux-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.testhostname -fdig +short ipa01.example.test Adig +short client01.example.test Adig +short -x <CLIENT-IP>sudo systemctl enable --now chronydchronyc 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 --refreshsudo dnf install freeipa-client bind-utils chrony oddjob-mkhomedir
sudo dnf updatesudo 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.kdestroykinit max.mustermannklist
id max.mustermanngetent passwd max.mustermannkinit max.mustermannklistsystemctl status sssd --no-pageripa 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.testpwdidklist
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 credentialvKerberos KDC|| Ticket Granting Ticket (TGT)vClient|| service ticketvService
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 einer kompatiblen Plattform folgt man dem jeweiligen Updatepfad der Distribution. Bei OS-Major-Upgrades oder Plattformwechseln ist in Enterprise-Umgebungen häufig ein Replica-Replacement das sauberere Muster. Red Hat dokumentiert für RHEL-IdM-Server-Migrationen explizit, dass In-place-Upgrades von IdM-Servern nicht unterstützt sind.
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
Identity & Access besprechen
Wenn FreeIPA nicht nur als Lab, sondern als zentrale Identity-Plattform für Linux-Umgebungen geplant, aufgebaut oder migriert werden soll, unterstützt ForgeOne bei Architektur, Implementierung, Betrieb und sauberer Übergabe.
