Warum FreeIPA mehr als LDAP ist

Eine kleine FreeIPA-Installation ist schnell aufgebaut. In größeren Umgebungen ändern sich aber die Fragen: Was passiert bei einem Site-Ausfall? Wer ist Source of Truth? Wo werden technische Berechtigungen modelliert? Soll DNS in FreeIPA liegen? Welche PKI stellt welche Zertifikate aus? Wie verhindert man doppelte Rechtepflege in Keycloak?

Dieser Artikel setzt auf dem praktischen Einstieg FreeIPA installieren: Vom ersten Server bis zum angebundenen Linux-Client auf. Erst kommt der nachvollziehbare Aufbau, danach die Enterprise-Fragen: Betrieb, klare Verantwortungsgrenzen, Hochverfügbarkeit, HBAC, sudo, Keycloak, Monitoring und Recovery.

Red Hat Identity Management ist die kommerziell supportete Enterprise-Variante dieser Technologie für RHEL-Umgebungen. In Architekturentscheidungen ist deshalb wichtig zu trennen: FreeIPA beschreibt den offenen Technologie-Kern, Red Hat IdM die supportete Plattform mit Hersteller-Lifecycle und Enterprise-Support.

Architekturüberblick

In größeren Umgebungen sollte FreeIPA nicht als einzelner LDAP-Server gedacht werden. Es ist der Kern für Linux-Identitäten, Kerberos, Gruppen, Hostzugriff, HBAC und sudo. Andere Aufgaben können bewusst in getrennten Systemen bleiben.

Users / Admins
      |
      v
FreeIPA Multi-Primary Replicas
      |-- LDAP / LDAPS
      |-- Kerberos
      |-- HBAC / sudo
      |-- internal Dogtag PKI
      |
      +--> Linux clients via SSSD
      +--> Keycloak -> OIDC / SAML -> Applications
      +--> Monitoring and automation


External responsibilities:
      Knot DNS      -> authoritative DNS and service discovery
      Smallstep CA  -> service and infrastructure certificates
      Ansible/AWX   -> desired state, reviews and controlled rollout

Die Trennung ist keine akademische Übung. Sie verhindert, dass DNS, Service-Zertifikate, SSO-Claims und Linux-Zugriffe unkontrolliert ineinanderwachsen. Jede Komponente bekommt eine klare Aufgabe und kann getrennt überwacht, geändert und wiederhergestellt werden.

DNS bewusst auslagern

In kleinen Umgebungen ist integriertes FreeIPA-DNS bequem. In größeren Umgebungen kann es sinnvoll sein, autoritatives DNS separat zu betreiben, etwa mit Knot DNS. Dadurch bleibt DNS unabhängig von Identity, bestehende Enterprise-DNS-Prozesse können weiter genutzt werden und FreeIPA wird nicht zum Sammelbecken für jede Infrastrukturverantwortung.

Die Verantwortung verschwindet dadurch nicht. Externes DNS muss FreeIPA-Discovery zuverlässig liefern: A/AAAA, PTR, LDAP-SRV, Kerberos-SRV, kpasswd-SRV, Prioritäten, Gewichte, TTLs und Forward-/Reverse-Konsistenz. Besonders Kerberos reagiert empfindlich auf Namens- und Zeitprobleme.

_ldap._tcp.example.org.       SRV 0 100 389 idm-a.example.org.
_kerberos._udp.example.org.   SRV 0 100 88  idm-a.example.org.
_kerberos._tcp.example.org.   SRV 0 100 88  idm-a.example.org.
_kpasswd._udp.example.org.    SRV 0 100 464 idm-a.example.org.
_kpasswd._tcp.example.org.    SRV 0 100 464 idm-a.example.org.

Externes DNS ist also kein Fehler. Es ist eine bewusste Architekturentscheidung mit eigener Betriebspflicht. Wer FreeIPA-Replicas ändert, muss auch DNS-Discovery und Client-Verhalten prüfen.

Multi-Primary und Site-Design

FreeIPA arbeitet mit replizierenden Multi-Primary-Replicas. Es ist keine klassische Active/Passive-Architektur. Änderungen werden zwischen Replicas repliziert, und Clients können über DNS-Discovery passende Server finden.

Ein anonymisiertes Beispiel: Site A betreibt drei Replicas, Site B eine Replica. Das kann als Gesamtarchitektur tragfähig sein, weil einzelne Node-Ausfälle nicht sofort die Identity-Plattform beenden. Trotzdem hat Site B lokal nur einen IdM-Knoten und damit keine site-lokale IdM-Hochverfügbarkeit.

  • Wenn Site B nur Edge-, DR- oder kleiner Außenstandort ist, kann eine einzelne Replica akzeptabel sein.

  • Wenn Site B autark weiterarbeiten muss, sollte eine zweite lokale Replica oder ein klar getestetes Failover-Modell geprüft werden.

  • Vier laufende Server bedeuten nicht automatisch gesunde Replikation. Topology, Serverrollen, Domain-Suffix, CA-Suffix und Replication Health müssen aktiv geprüft werden.

Replication ist kein Backup

Replication schützt gegen Node-Verlust. Sie schützt nicht gegen replizierte Löschungen, fehlerhafte Admin-Änderungen, logische Directory-Korruption, kompromittierte Credentials oder CA-/PKI-Probleme. Ein falscher Gruppen- oder Benutzerzustand kann sich sehr zuverlässig auf alle Replicas verteilen. Genau deshalb ist Replikation kein Backup.

Ein belastbares Betriebsmodell trennt drei Verfahren: Replication für Verfügbarkeit, Backup für Datenwiederherstellung und Replica-Rebuild für verlorene Knoten. Nicht jede verlorene Replica sollte restored werden; oft ist ein sauberer Rebuild mit anschließender Replikationsprüfung der bessere Weg.

Dogtag und Smallstep trennen

FreeIPA bringt mit Dogtag eine integrierte CA mit, weil interne FreeIPA-Funktionen Zertifikate benötigen. Daraus folgt aber nicht, dass Dogtag automatisch die allgemeine Enterprise-Service-PKI werden sollte. Für Web-, Service- und Infrastrukturzertifikate kann eine separate Smallstep CA sinnvoller sein.

Das wichtigste Prinzip lautet: kein Zertifikat darf versehentlich von zwei Renewal-Mechanismen gleichzeitig verwaltet werden. certmonger gehört in die FreeIPA-nahe Welt. Smallstep verwaltet seine eigenen Service-Zertifikate. CA-Bundles und Trust Stores werden bewusst verteilt, aber sie sind nicht selbst die Zertifikatsausstellung.

Certificate Type                Owner              Renewal Tool        Monitoring
FreeIPA internal CA             Dogtag / FreeIPA   certmonger/Dogtag   IPA health and expiry
FreeIPA LDAP/HTTP if IPA-owned  FreeIPA            certmonger          getcert and service checks
Service and web TLS             Smallstep CA       step / ACME client  expiry and renewal checks
Trust stores and CA bundles     Automation         Ansible            file and trust validation

Identity-Modell mit org, role, peg und hg

In größeren Umgebungen sollten Organisation, Verantwortung, technische Berechtigung und Zielsystem getrennt modelliert werden. Ein mögliches Modell nutzt vier Namensräume: `org.*` für organisatorische Zugehörigkeit, `role.*` für Verantwortlichkeiten, `peg.*` für technische Permission- oder Entitlement-Gruppen und `hg.*` für Hostgruppen.

User
  -> org.platform
  -> role.platform-admin
  -> peg.linux.production.login
  -> HBAC rule for sshd on hg.linux.production

Der kritische Punkt ist: Organisation ist nicht automatisch Authorization. Dass eine Person zum Platform-Team gehört, bedeutet nicht automatisch, dass sie Root-Rechte auf Produktionssystemen braucht. `peg.*` sollte deshalb die technische Authorization Boundary sein. Anwendungen, HBAC, sudo und Keycloak sollten möglichst `peg.*` konsumieren, nicht `org.*`.

Hostgroups als Gegenstück zu Permissions

Hostgroups sind die Zielseite des Modells. Statt Regeln pro Host zu bauen, werden Systeme nach Funktion, Risiko und Betriebsverantwortung gruppiert. Ein Host darf mehreren Hostgroups angehören, etwa `hg.linux.production`, `hg.identity`, `hg.monitoring` oder `hg.kubernetes.controlplane`.

Hostgroups sollten nicht explodieren. Zu grobe Gruppen sind riskant, zu viele Gruppen machen das Modell unbedienbar. Der beste Start ist ein kleines, stabiles Set für produktive Linux-Systeme, Staging, Identity, Monitoring, Bastion, Kubernetes-Control-Plane, Worker und Datenbanksysteme.

HBAC sicher einführen

HBAC beantwortet: Wer darf auf welchen Host über welchen Service zugreifen? Das Zielmodell kombiniert technische Permission-Gruppe, Hostgroup und Service. Für SSH-Zugriff sieht das abstrakt so aus:

peg.linux.production.login
  + hg.linux.production
  + sshd
  = allowed host access

Der wichtigste Betriebsfehler ist, globale Default-Regeln vorschnell abzuschalten. Ein sicherer HBAC-Rollout ist additiv und getestet: Hosts inventarisieren, Hostgroups bauen, Permission Groups definieren, HBAC-Regeln anlegen, `ipa hbactest` ausführen, Testhosts verwenden, Break-Glass und AWX-Service-Account prüfen und erst danach Default-Regeln reduzieren.

sudo zentral, aber ehrlich modellieren

sudo sollte in größeren Linux-Umgebungen nicht dauerhaft über lokale `/etc/sudoers`-Dateien wachsen. Zentrale sudo-Regeln reduzieren Drift, beschleunigen Offboarding und machen Berechtigungen auditierbarer. Das Muster ist ähnlich wie bei HBAC:

peg.linux.production.sudo
  + hg.linux.production
  + sudo command group
  = central sudo rule

Command Groups sind hilfreich, aber kein Allheilmittel. Befehle wie `vim`, `less`, `bash`, `sh`, `python` oder unscharfe `systemctl`-Regeln können indirekte Privilege Escalation ermöglichen. Für eng begrenzte echte Admin-Gruppen kann `ALL` ehrlicher und kontrollierbarer sein als eine lange, fehlerhafte Whitelist.

Lokale Accounts und Break Glass

Lokale Human-Accounts sollten nicht parallel zur zentralen IdM-Welt wachsen. Normale Admins und Engineers gehören in FreeIPA. Lokal bleiben nur klar begründete Sonderfälle: root, Break Glass, Bootstrap, Recovery und technische Accounts, die aus betrieblichen Gründen nicht zentralisiert werden können.

Break Glass ist kein Alltagszugang. Ein belastbares Modell nutzt starke zufällige Credentials oder streng kontrollierte SSH-Keys, sichere Ablage in einem Vault oder Password Manager, Protokollierung, regelmäßige Tests, Rotation nach Verwendung und klare Ownership.

Keycloak als Consumer, nicht als zweite Source of Truth

Keycloak sollte FreeIPA nicht ersetzen, sondern FreeIPA-Gruppen in OIDC- oder SAML-Claims übersetzen. FreeIPA bleibt Source of Truth für Identity und Entitlements. Keycloak übernimmt Federation, Protokollübersetzung, Client Scopes und Claims. Anwendungen konsumieren nur die Berechtigungen, die sie wirklich brauchen.

FreeIPA group
  -> peg.observability.zabbix.admin
  -> Keycloak client-specific mapper
  -> SAML/OIDC claim for Zabbix only
  -> Zabbix role mapping

Nicht alle `peg.*` gehören in jedes Token. Token-Minimierung reduziert Größe, Informationsweitergabe und Governance-Risiko. Ein Zabbix-Client braucht keine Kubernetes-, Linux-sudo- oder GitLab-Gruppen im Token. Client-spezifische Mapper und Scopes sind hier die sauberere Architektur.

Deprovisioning realistisch prüfen

User deaktivieren reicht nicht immer. In einer kombinierten FreeIPA-/Keycloak-Welt muss geprüft werden, wie schnell Zugriff tatsächlich endet: FreeIPA-Status, Gruppenmitgliedschaften, Keycloak-Sync, Cache, Access Tokens, Refresh Tokens und Anwendungssessions.

Die Leitfrage lautet nicht nur: Ist der User im Directory deaktiviert? Die Leitfrage lautet: Kann diese Person jetzt noch irgendwo ein bestehendes Token oder eine Anwendungssession nutzen? Erst diese Sicht macht Offboarding auditierbar.

Ansible, AWX und Desired State

Deklarative IdM-Verwaltung ist sinnvoll, weil Benutzer, Gruppen, Memberships, HBAC, sudo und Hostgroups nachvollziehbar versioniert werden können. In größeren Umgebungen muss Automation aber zwischen Directory State und Node-local State unterscheiden.

  • Directory State: users, groups, memberships, HBAC, sudo, hostgroups. Diese Objekte sind globale LDAP-Objekte und müssen nicht logisch gegen jede Replica geschrieben werden.

  • Node-local State: Pakete, Service-Konfiguration, lokale Dateien, Trust Stores, OS-Konfiguration und hostnahe Zertifikatsdateien. Diese Änderungen gehören auf die jeweiligen Nodes.

  • Change Control: Git Review, Merge, AWX-Ausführung und anschließende Verification. Für privilegierte Gruppen, HBAC, sudo, CA und Keycloak-Rollen ist ein Four-Eyes-Prozess sinnvoll.

Wichtig ist außerdem Drift: Was passiert, wenn jemand manuell in FreeIPA ändert? Überschreibt Automation den Zustand, meldet sie Drift oder gibt es einen Ausnahmeprozess? Ohne Antwort entsteht mit der Zeit ein zweites, unsichtbares Berechtigungsmodell.

Monitoring ist mehr als Portchecks

Port 389 offen bedeutet nicht, dass LDAP gesund ist. Port 88 offen bedeutet nicht, dass Kerberos Tickets korrekt funktionieren. HTTP 200 bedeutet nicht, dass FreeIPA, CA, Replikation und API wirklich in Ordnung sind. Enterprise-Monitoring braucht mehrere Schichten.

  1. Infrastructure: CPU, RAM, Disk, Inodes, Load, Netzwerk und Zeit.

  2. Process: Directory Server, Kerberos, HTTPD, Dogtag, certmonger und Custodia.

  3. Protocol: LDAP, LDAPS, Kerberos, HTTPS.

  4. Functional: LDAP Search, Kerberos Ticket, IPA API Read.

  5. Replication: Topology, Lag, Konflikte und Suffix-Gesundheit.

  6. Certificates: Dogtag, LDAP/HTTP, certmonger und Smallstep-Zertifikate.

  7. End-to-End Identity: synthetischer Test mit minimal privilegierter Monitoring Identity.

`ipa-healthcheck` ist dafür ein zusätzlicher Health Layer. Es ersetzt keine funktionalen Tests, hilft aber, FreeIPA-spezifische Fehlerbedingungen sichtbar zu machen. Monitoring-Credentials dürfen keine Human-Admin-Credentials sein.

Backup, Restore und Runbooks

FreeIPA braucht ein eigenes Backup-/Restore-Konzept. VM-Snapshots und Replikation beantworten nicht dieselbe Frage. Ein gutes Modell behandelt `ipa-backup`, Full vs. Data-only, Verschlüsselung, Off-host Storage, Retention, Site-Trennung, benötigte Secrets und regelmäßige Restore-Tests.

Runbooks sollten mindestens Replica Failure, Replica Rebuild, Site Failure, Replication Failure, Kerberos Failure, LDAP Failure, CA Renewal, Certificate Expiry, Backup, Restore, Emergency Access, Keycloak Federation Failure und Rolling Upgrades abdecken.

Lifecycle und Rolling Maintenance

Tier-0-Identity braucht eine planbare Plattformstrategie. Kurzlebige Distributionen sind nicht automatisch falsch, bedeuten aber häufigere Upgrades, höhere Change Rate, mehr Rehearsal und mehr Wartungsdisziplin. Wenn Hersteller-Support, Lifecycle, Security Advisories und klare Verantwortlichkeit entscheidend sind, ist Red Hat IdM auf RHEL die naheliegende Enterprise-Ausprägung. Das ist eine Architektur- und Betriebsentscheidung, nicht nur eine Paketfrage.

1. Check IdM health before maintenance
2. Patch or upgrade one replica
3. Verify LDAP, Kerberos, CA and replication
4. Wait until the cluster is clean
5. Continue with the next replica

Vor jeder Wartung steht Health. Nach jeder einzelnen Replica folgen LDAP-, Kerberos-, CA-, Replikations- und Login-Prüfungen. Erst danach kommt die nächste Replica.

Warum diese Trennung hilft

Die Architektur hat klare Vorteile: weniger Kopplung, bessere Ownership, sauberere Change Control, bessere Auditierbarkeit, weniger Drift, schnelleres Offboarding und klarere Recovery-Pfade. Sie macht FreeIPA nicht kleiner, aber beherrschbarer.

Die Trade-offs sind real: mehr Komponenten, mehr Dokumentationsaufwand, abgestimmtes DNS und PKI, mehr Monitoring, mehr Runbooks und höhere Anforderungen an Automation. Genau deshalb lohnt sich das Modell vor allem dort, wo Linux-Identitäten, mehrere Standorte, SSO, Compliance und zentrale Betriebsprozesse zusammenkommen.

Professionelle Unterstützung

Identity & Access Architektur besprechen

Wenn Sie FreeIPA, Keycloak, Linux-Zugriffe, HBAC, sudo, DNS, PKI und Automation als belastbare Identity-Plattform aufbauen, migrieren oder härten möchten, unterstützt ForgeOne bei Architektur, Umsetzung und Betrieb.

IdM-Architektur besprechen