In diesem Beitrag beschreibe ich, wie ich FreeIPA als Zentrale für Authentifizierung verwende. Das betrifft sowohl User und Gruppen als auch Dienste untereinander in Form von SSL-Zertifikaten (Puppet, Postfix) und Kerberos. Andere Dienste wie Webanwendungen (Gogs etwa) oder Samba und NFS können das Setup ebenfalls nutzen.

Bisherige Beiträge in der Reihe:

Was ist denn FreeIPA?

FreeIPA ist ein Softwareprojekt von Red Hat. Es besteht aus verschiedenen für unser vorhaben nützlichen Komponenten:

LDAP-Server
Kerberos-Server
Radius-Server
DNS-Server
SSL-CA und Zertifikatsverwaltung
Verwaltung von Benutzerrechten anhand von sudo
Konfiguration von automatischen Mounts

Das sieht erst mal nach recht viel aus und man stellt sich zu Recht die Frage, ob das alles notwendig ist. Notwendig ist daher die Definition von Zielen, die man sich setzt und darauf aufbauend die Evaluation der Eignung:

Unterstützte Dienste

Sieht man sich an, welche Dienste alle zentral verwaltet werden können, ist die Liste der von FreeIPA vorausgesetzten Services plötzlich nicht mehr so überdimensioniert. Der DNS-Server hat keinen direkten Nutzen in meinem Setup, da macht das im Grunde schon unbound auf Grundlage der DHCP-Einträge, FreeIPA stützt sich wie auch vergleichbare Dienste stark auf DNS für Autokonfiguration und ähnliche Funktionen. Das könnte man zwar alles von unbound übernehmen lassen aber der Austausch von DNS-Informationen zwischen zwei Servern ist ein bereits gelöstes Problem und dazu nimmt man nun mal gerne DNS selbst.

Dienst	Nutzen
Proxmox	Benutzer- und Gruppenverwaltung per LDAP SSL-Zertifikat
pfsense	Benutzer- und Gruppenverwaltung per LDAP SSL-Zertifikat von pfsense angebotene Dienste profitieren auch davon, etwa OpenVPN
puppet	SSL-Zertifikate zur Authentifizierung der Nodes gegenüber dem Puppet Server die bereits im Vorfeld von FreeIPAs CA unterzeichnet wurden
postfix	SSL-Zertifikat zur Authentifizierung der VMs gegenüber dem Mail Relay, die bereits im Vorfeld von FreeIPAs CA unterzeichnet wurden
SSH	Benutzer- und Gruppenverwaltung per LDAP Verteilung der known_hosts und authorized_keys
NFS/Samba	Benutzer- und Gruppenverwaltung per LDAP und Kerberos automatisches Einhängen von Heimverzeichnissen auf VMs
sudo	Benutzerrechte können global verwaltet werden, etwa einem deploy-Nutzer auf allen Hosts die Rechte für entsprechende Skripten und `puppet` zuweisen

Zentrale Authentifizierung im Linux-Netzwerk selbst implementieren

Ich habe mir zuerst überlegt, dass ich doch „nur” zentrale Benutzernamen und Passwörter möchte. Dafür müsste doch LDAP selbst reichen oder das Verteilen der Accounts mit Puppet.

Das ist auch richtig, allerdings ist erstmal das Konfigurieren von LDAP und die Integration der Authentifizierung auf den Clients alles andere als intuitiv und trivial, außerdem gibt es da noch eine Menge weitere Probleme, auf die man nach und nach stößt:

die Authentifizierung gegenüber NFS geschieht entweder auf Basis der Netzwerkadresse oder anhand der verwendeten User ID, über die jeder Rechner in Standardkonfiguration heute allein selbst die Kontrolle hat, das ist also wirklich nicht sicher.
NFSv4 mit Authentifizierung anhand von Benutzeraccounts braucht Kerberos. Kerberos kann man auch ohne LDAP verwenden aber dann wird es schon unnötig umständlich.
öffentliche SSH-Schlüssel müssen irgendwo zentral gepflegt werden und auf die verschiedenen Systeme verteilt werden
Für den Versand von E-Mails von VMs aus braucht man an irgend einer Stelle SMTP-Auth gegenüber einem Smarthost (Sendgrid in meinem Fall). Entweder hinterlegt man jetzt auf jeder VM die Zugangsdaten zum Smarthost einzeln oder man richtet ein Mail-Relay ein, was die Kommunikation mit der Außenwelt übernimmt und lässt die internen VMs die Mails alle über dieses Relay schicken. Die internen VMs sollten sich aber auch gegenüber dem Mail-Relay authentifizieren, entweder über die Mitgliedschaft im internen Netzwerkbereich (im Fall von IPv6 nicht besonders trivial), Benutzername und Passwort (im Idealfall pro VM) oder gleich über ein SSL-Zertifikat.
Nicht alle Dienste können zuverlässig gegen normale Linux-Accounts authentifiziert werden. Manche Web-Anwendungen unterstützen zwar entweder direkte Authentifizierung gegen PAM, andere akzeptieren vom Webserver gesetzte HTTP-Header, die eine erfolgreiche Authentifizierung gegen PAM durch den Webserver anzeigen, so präsent wie LDAP ist allerdings keine andere Authentifizierungslösung.
Samba hat seine ganz eigenen Eigenheiten. Verwendet man nur Linux-Systeme, kann man natürlich auch NFS verwenden (siehe aber Punkt 1 und 2), möchte man Geräte wie Smartphones oder doch mal einen Windows-Client zum Zugriff auf die NAS-Inhalte unterstützen, braucht man Samba. Samba benötigt allerdings mehr Attribute für Accounts als es von Linux über PAM o.Ä. bekommt; es muss also seine eigene Datenbank mit Accounts pflegen und Benutzername und Kennwort müssen pro Account dann auch irgendwie synchron gehalten werden, wenn man nicht überall unterschiedliche Passwörter verwenden will. Das ist für gewöhnlich nicht problemlos möglich und erfordert meist sehr abenteuerliche Konstrukte.

Diese Schwierigkeiten lassen sich alle einzeln mit Hilfe von Workarounds lösen, irgendwann ist man allerdings bei einer schlechten Re-Implementierung der geläufigen Verzeichnisdienste angelangt und hat all die Fehler gemacht, die dort bereits schon lange gelöst wurden.

Das Aufsetzen von etwa FreeIPA ist vom Aufwand her relativ gering und die verwendeten Komponenten sind dann gleich aufeinander abgestimmt. Unter dem Strich rentiert sich das also auf jeden Fall.

Kompatibilität zwischen FreeIPA und Windows

Ich habe keinerlei Pläne, an irgend einer Stelle Windows mit in meine Infrastruktur einzubinden. Die Kompatibilität zu Windows ist mir daher recht egal. Drei Grundlagen allerdings:

Zugriff auf Dateifreigaben über Samba geht trotzdem, ebenso natürlich die Authentifizierung in Web-Anwendungen.
Möchte man Windows zentral verwalten, braucht man grundsätzlich Active Directory.
Nutzt man Active Directory, ist es möglich, einen Trust zwischen FreeIPA und Active Directory aufzusetzen.

Voraussetzungen

FreeIPA kommt in einem recht vollständigen Paket und installiert seine ganzen Komponenten selbst. Aus organisatorischen und sicherheitstechnischen Gründen ist es nicht verkehrt, eine eigene VM für FreeIPA zu verwenden - im Idealfall CentOS.

Während es zwar das Paket freeipa-server auch für Ubuntu gibt, ist es dort aber nur Teil des universe-Repositories. Das ist normalerweise nicht so wild, allerdings handelt es sich hier aber auch um eine zentrale und kritische Komponente der Infrastruktur und möglichst keine Probleme durch die unterschiedliche Struktur von Ubuntu dazukommen sollen, nutze ich hier trotz geringerer Erfahrung darin für die VM CentOS 7. Nachdem die meisten Komponenten ohnehin von FreeIPA selbst eingerichtet werden, reicht ja vielleicht schon zu wissen, dass man die Paket-Updates mit yum update einspielt.

Clients dürfen ruhig auf Ubuntu laufen, in meinen Tests gab es keine Probleme.

Installation

Die VM braucht nur eine CPU und im Betrieb nur wenig Arbeitsspeicher, für die Installation sind allerdings 2 Gibibyte notwendig, sonst schlägt währenddessen irgendwann zwangsläufig der OOM-Killer zu.

Installation von CentOS

CentOS ist die OpenSource-Variante von Red Hat Enterprise Linux, nur eben auch ohne Support durch Red Hat. Dadurch ist so ziemlich jedes Paket in CentOS uralt, aber dafür auch einige Jahre lang stabil und Probleme werden zuverlässig behoben. Nachdem auf dem Authentifizierungshost bitte auch nichts aufregendes passieren soll, ist das ideal. Davon abgesehen ist, wie eingangs schon erwähnt, FreeIPA ein Red Hat-Projekt und am besten für CentOS geeignet.

Die Installation ist wenig kompliziert: Nach dem Anlegen einer neuen VM (ich hatte leichte Schwierigkeiten mit dem Anlegen eines Containers für CentOS) folgt man einfach den Anweisungen des Installers. Einen lokalen Nutzeraccount habe ich hier nicht angelegt, da auf dem System sowieso nicht gearbeitet wird und der Zugang über SSH nicht erlaubt ist. Zur Verwaltung des Systems dienen die Weboberfläche oder die IPA admin tools, die auch auf Workstations installiert werden können. Ein direkter Zugang zur VM ist also nur über die SPICE-Konsole möglich.

Nach dem Reboot in das installierte System gilt es erst mal, die Paketquellen und die installierten Pakete zu aktualisieren:

yum update

DNS-Aufteilung für FreeIPA

Für das Funktionieren von FreeIPA und der meisten anderen vergleichbaren Lösungen ist ein korrekt arbeitendes DNS-System notwendig. Das heißt, alle Hosts im Netzwerk brauchen einen FQDN und die Reverse DNS-Einträge für IPs müssen richtig auflösen. FreeIPA liefert für seine Zwecke einen DNS-Server mit, mit dem es seine Zone verwaltet. Das reicht schon mal aus, insgesamt ist das System aber auch kompatibel zum Betrieb neben einem anderen Nameserver, wie in meinem Fall unbound auf der Firewall.

Man muss sich für den Betrieb ein Realm oder eine Domäne heraussuchen, was in etwa einer DNS-Domain entspricht. Dabei sollte man nicht unbedingt .local verwenden, wie es früher bei Microsoft-Setups üblich war, weil man damit Probleme mit avahi und anderen Zeroconf-Diensten bekommt. Ansonsten sollte man ausschließen, dass bereits oder später mal existierende Domains eine Kollision mit der intern verwendeten Domain verursachen. Also nicht einfach unregistrierte Domainnamen verwenden - nachher registriert das noch wer und alle möglichen Schwierigkeiten mit DNS treten auf. Man kann eine eigene TLD erfinden, wenn man sich ganz sicher ist, dass die niemals doch noch registrierbar ist. Am sichersten ist man aber, wenn man die Domain auch tatsächlich registriert hat und so selbst mit Sicherheit sagen kann, dass es keine Kollision geben wird. Mein Beispiel verwendet also die Domain domain.tld, in Realität habe ich aber einfach eine Domain registriert verwende die.

Sinnvoll ist die Verwendung einer Subdomain als Realm/Domäne, damit man bei der Vergabe der DNS-Zonen flexibel bleibt. Ich nehme also ipa.domain.tld, was ich auch gleich in meiner Firewall als Domain override in den Einstellungen für unbound eintrage. DNS-Anfragen für *.ipa.domain.tld gehen an meine FreeIPA-VM, die sie mit ihrem eigenen Nameserver beantwortet.

Installation von FreeIPA

Die ganze Domain ist unterhalb der ipa.domain.tld-Zone erreichbar. Der Host, auf dem FreeIPA erreichbar sein soll, braucht aber auch einen eigenen DNS-Eintrag. Ich nehme dafür auth.domain.tld. Zuerst nochmal nachsehen, ob auch der FQDN auflösbar ist:

# Datei /etc/hosts
10.0.0.10 auth.domain.tld auth

Die Installation hat zwei Schritte: Die Pakete werden installiert, dann wird der IPA-Server konfiguriert:

yum install freeipa-server
ipa-server-install

Die anfallenden Fragen beantwortet man einfach und lässt das Script machen.

Während der Installation wurden zwei Passwörter angelegt, die man nicht vergessen sollte - aber auch nicht verwechseln: Einmal gibt es das Passwort für den LDAP directory manager - dabei handelt es sich um den root-Account des LDAP-Servers. Der wird im Betrieb normalerweise nicht abgefragt, damit wird nur der LDAP-Server verwaltet. Weiterhin wurde ein Admin user angelegt. Das ist ein User, der innerhalb der LDAP-Datenbank angelegt wurde und in FreeIPA den root-Account darstellt, der weitere Accounts anlegen darf etc.

Firewall-Einstellungen für FreeIPA (Ports öffnen)

Damit die verschiedenen Netzwerkdienste aus dem Netzwerk erreichbar sind, müssen verschiedene Ports in den Firewalls geöffnet werden. Zum einen erstmal auf der VM selbst und zum anderen auch in der vorgeschalteten Firewall, in meinem Fall pfsense, falls außerhalb des internen Netzwerks ebenfalls die Dienste von FreeIPA in Anspruch genommen werden sollen:

Port Protokoll Dienst ————————— ————- ———————— 53 TCP und UDP DNS 80 TCP HTTP für Webinterface 88 TCP und UDP Kerberos 123 UDP NTP 389 TCP LDAP 443 TCP HTTPS für Webinterface 464 TCP und UDP Kerberos 636 TCP LDAPS

Auf der VM geht das mit zwei Befehlen:

firewall-cmd --permanent --add-port={\
  80/tcp,\
  443/tcp,\
  389/tcp,\
  636/tcp,\
  88/tcp,\
  88/udp,\
  464/tcp,\
  53/tcp,\
  53/udp,\
  123/udp}
firewall-cmd --reload

Client in die FreeIPA-Domäne aufnehmen

Um einen Host in die Domäne aufzunehmen, muss dieser zunächst ebenfalls funktionierendes DNS haben, d.h. zum einen muss der FQDN des Hosts auflösbar sein und der dazugehörige reverse DNS-Eintrage bestehen, zum anderen muss der Host den DNS-Eintrag für auth.domain.tld auflösen können.

Meine Clients sind alle Ubuntu- oder Debian-Hosts. Auch dort findet man FreeIPA in den Paketquellen und kann deswegen den Client problemlos installieren:

sudo apt-get install freeipa-client
sudo freeipa-client-install --mkhomedir

Der Schalter --mkhomedir weißt das Script an, beim Login eines Nutzers auch direkt ein Heimverzeichnis anzulegen. Ansonsten wird das nicht gemacht. Nutzt man lokale Heimverzeichnisse für die Nutzer, macht das Sinn - hat man stattdessen aber welche etwa per NFS eingebunden, kann man den Schalter weglassen.

Wiederum beantwortet man die Fragen des Scripts und wartet ab. Das Realm ist in meinem Beispiel ipa.domain.tld und die beiden erfragten Server sind jeweils auth.domain.tld. Der Nutzer, der den Client in die Domäne aufnehmen darf, heißt admin und das Kennwort hat man vorhin selbst ausgesucht.

Auswirkungen

Mit der Aufnahme des Clients in die Domäne werden verschiedene Einstellungen auf dem Host vorgenommen:

SSH wird zum einen für die Verwendung von Kerberos zur Authentifizierung und zum anderen zum Ermitteln der authorized_keys über LDAP konfiguriert.
Die Fingerabdrücke aller im IPA registrierten Hosts mit SSH-Server werden in die ssh_known_hosts eingetragen.
PAM wird natürlich so konfiguriert, dass im IPA angelegte Nutzer sich am System anmelden dürfen.
Die CA des IPA-Servers wird auf dem System installiert, so dass von ihr signierten Zertifikaten vertraut wird.
Einige Tools werden installiert, mit denen Funktionalität auf den Clients bereitgestellt wird, die sich an den FreeIPA-Server wenden. Darunter auch ipa-getcert, mit dem durch die CA signierte Zertifikate zur Verwendung für lokale Dienste angefordert werden können.
Für sudo wird eingerichtet, dass Rechte auch durch das IPA konfiguriert werden können.

Verwaltung

Um Einstellungen für Hosts vorzunehmen, Benutzer und Gruppen anzulegen, neue Dienste (als Kerberos-Prinzipale) und Zertifikate anzulegen oder Regeln für sudo einzurichten, kann man sich auf der Weboberfläche einloggen, die über HTTPS unter https://auth.domain.tld zu erreichen ist. Dafür gilt das Kennwort des admin-Nutzers.