Migration von LDAP zu FreeIPA

© Volha Kavalenkava, 123RF

Wachhund

Die Umstellung einer zentralen Benutzer-Authentifizierung von einem reinen LDAP-Server auf die Identity-Managament-Lösung FreeIPA ist einfacher, als so mancher Admin denkt. Beachtet man einige wenige Punkte, so klappt der Umstieg in kürzester Zeit mit wenig Aufwand.
Mit den Tipps und Workshops im ADMIN-Magazin 03/2013 sichern Administratoren ihre Webserver und Netze gegen Angriffe ab: gegen Abhören sensibler Informationen, ... (mehr)

In vielen Umgebungen existiert ein LDAP-Server zur Verwaltung der Benutzer- und Gruppenkonten. Oft kommt dieser Server dann auch zum Einsatz, wenn es um die Authentifizierung der Benutzer geht. Dies setzt jedoch voraus, dass die Benutzerobjekte im LDAP über ein Passwort-Attribut verfügen. Dieses Attribut erfordert natürlich besonderen Schutz. So sollte es nur vom Benutzer selbst und von einem LDAP-Administ rator veränderbar sein. Über entsprechende Access-Control-Listen lässt sich sowas relativ einfach sicherstellen.

Problemkind Passwort

Trotzdem ist eine Benutzer-Authentifizierung auf Basis des Passwort-Attributes nicht ganz unkritisch. Sie findet im einfachsten Fall mittels eines sogenannten Simple Bind statt. Hierbei wandert das Passwort des Benutzers im Klartext zum LDAP-Server, der dann den Benutzer mit dem übermittelten Passwort zu authentifizieren versucht. Klappt dies, so ist der Benutzer auf dem Client-System angemeldet, ansonsten gibt es eine Fehlermeldung. Eine sichere Konfiguration erfordert also in jedem Fall auch eine Übertragung des Benutzerpasswortes über einen gesicherten Kommunikationskanal. Dieser könnte beispielsweise auf Applikationsebene mittels SSL/TLS realisiert werden.

Neben der Simple-Bind-Methode unterstützt LDAPv3 auch eine Authentifizierung auf Basis von SASL (Simple Authentication and Security Layer, RFC 4422). Darunter fallen eine ganze Reihe von Methoden zur Verifizierung eines Benutzers, zum Beispiel mit Hilfe eines Kerberos-Tickets oder eines X.509-Client-Zertifikates. Das Setup und die Konfiguration einer solchen Umgebung gestaltet sich jedoch nicht immer leicht. Dies liegt unter anderem auch daran, dass es ein korrektes Mapping zwischen dem Benutzerobjekt im LDAP, repräsentiert durch einen Distinguished Name (dn) und dem passenden Kerberos-Principal oder X.509-Client-Zertifikat geben muss.

Alternativ dazu besteht die Möglichkeit, die Authentifizierung direkt über einen Kerberos-Server durchzuführen und den LDAP-Server lediglich für die Account-Informationen des Benutzers abzufragen. Allerdings ist auch ein solches Setup recht komplex und unhandlich; jeder, der bereits einmal die Schmerzen beim Einsatz der Kerberos-Client-Tools gespürt hat, weiß, wovon ich rede.

Das bereits in der Admin-Story 03/2012 [1] erwähnte Open-Source-Projekt FreeIPA [2] hat es sich zum Ziel gesetzt, eine einfach zu konfigurierende, aber dennoch sichere Identity-Management-Lösung für Linux- und Unix-Umgebungen zu entwickeln. Doch wie gelingt der Umstieg von einem bereits vorhandenen LDAP-Server auf die Identity-Management-Lösung FreeIPA?

Bei der Migration sind einige Punkte besonders zu beachten:

  • Wie migriert man bestehende Benutzer- und Gruppenobjekte?
  • Wie werden die Benutzerpasswörter migriert?
  • Welche Clients sollen auf das neue Identity-Management-System zugreifen?

Für die Migration der Benutzer und Gruppen stellt FreeIPA ein eigenes Kommando zur Verfügung:

ipa migrate-ds ldap://ldap.tuxgeek.de:389

Dieser Aufruf migriert sämtliche Benutzer und Gruppen aus den beiden Containern »ou=People« und »ou=Group« in das lokale FreeIPA-System. Sind die Benutzer und Gruppen in anderen Containern untergebracht, so lassen sich diese über die beiden Optionen »--user-container« und »--group-container« mit übergeben. Sollen nur Objekte mit einer bestimmten Objektklasse auf das neue System übertragen werden, so existieren hierfür die Optionen »--user-objectclass« und »--group-objectclass« . Dies ist besonders dann sinnvoll, wenn in den Containern Gruppen oder Benutzer existieren, die man nicht auf dem neuen System haben möchte und diese anhand einer bestimmten Objektklasse identifizieren kann. Hier ein etwas komplexeres Beispiel:

ipa migrate-ds --user-container=emea-users --group-container=emea-groups --user-objectclass=employee --group-objectclass=groupOfNames,groupOfUniqueNames ldap://ldap.tuxgeek.de:389

Wer einzelne Benutzer oder Gruppen ausschließen möchte, kann dies auch auf Basis der Benutzer- und Gruppennamen tun. Hierfür existieren die Optionen »--exclude-users« und »--exclude-groups« . Eine weitere interessante Option lautet »--user-ignore-objectclass« beziehungsweise »--user-ignore-attribute« , womit einzelne Attribute respektive Objektklassen von der Migration ausgeschlossen werden. Dies ist besonders dann sinnvoll, wenn diese Informationen auf dem FreeIPA-System nicht mehr benötigt werden. Für Gruppen existieren entsprechende Parameter. Eine Übersicht der Optionen liefert »ipa help migrate-ds« .

Als etwas komplexer stellt sich die Migration der Benutzerpasswörter auf das FreeIPA-System dar. Auf dem LDAP-Server existieren diese üblicherweise als Hash im »userPassword« -Attribut, manchmal liegen die Passwörter auch im Klartextformat vor. FreeIPA verwendet jedoch Kerberos zur Authentifizierung der Benutzer. Um einen korrespondierenden Kerberos-Hash zu den migrierten Benutzerkonten zu erzeugen, gibt es wieder mehrere Möglichkeiten:

  • Die Benutzer werden gezwungen, ihre Passwörter nach der Migration zu ändern. Hierbei wird dann auf Basis des geänderten Passwortes ein passender Kerberos-Hash angelegt.
  • Die Benutzer werden aufgefordert, eine Migrationswebseite auf dem FreeIPA-System aufzurufen und dort ihr Passwort einzugeben. Im Anschluss wird hieraus dann ebenfalls ein Kerberos-Hash generiert und im Directory-Server gespeichert.
  • Clients, auf denen der System Security Services Daemon (SSSD) als Client-Komponente läuft, können auf den FreeIPA-Migrationmodus zurückgreifen, um einen Passwort-Hash für ihren Kerberos-Principal zu erzeugen. Der Migrationmode ist auf dem FreeIPA-Server wie folgt aktivierbar:
ipa config-mod --enable-migration=TRUE

Auf dem Client-System meldet sich der Benutzer dann regulär über das FreeIPA-System an, das für die Authentifizierung Kerberos verwendet. Diese schlägt natürlich fehl, da das migrierte Benutzerkonto zu diesem Zeitpunkt noch über keinen Kerberos-Hash verfügt. Der SSSD-Client führt dann selbstständig eine LDAP-Simple-Bind-Anmeldung am FreeIPA-System mit dem vom Benutzer zuvor eingegebenen Passwort durch. Dies erfolgt über einen sicheren TLS-Kanal. Die Konfiguration hierfür erfolgt bei der Konfiguration des SSSD-Clients. Das FreeIPA-System fängt das übermittelte Passwort ab, stellt fest, dass der Benutzer zwar über ein Kerberos-Principal, nicht jedoch über einen Kerberos-Passwort-Hash verfügt, und erzeugt diesen. Die Verbindung wird getrennt und SSSD führt selbstständig und für den Benutzer komplett transparent eine Kerberos-basierte Anmeldung durch ( Abbildung 1 ).

Abbildung 1: Eine Anwendung verwendet zur Authentifizierung den SSSD, der mit den Backends über eine sichere Verbindung kommuniziert.

Die zuletzt aufgeführte Variante ist die eleganteste Lösung für die Migration der Benutzerpasswörter auf das Identity-Management-System. Einzige Voraussetzung dafür ist, dass auf dem Client-System der System Security Services Daemon (SSSD) zum Einsatz kommt.

Client-Software

Der SSSD [1] stellt die bevorzugte Möglichkeit dar, Linux-Systeme an das Identity-Management-System anzubinden. Dies gilt nicht nur wegen der sehr einfachen Migration der Passwörter. Der SSSD bietet daneben eine Vielzahl von Vorteilen. So hält er beispielseise die vom FreeIPA-System erhaltenen Informationen in einem lokalen Cache vor. Eine Anmeldung am System ist damit also auch dann möglich, wenn der Client offline ist. Der Cache enthält dabei nicht nur Benutzer-, sondern auch Sudo- und Automounter-Informationen.

Mit Hilfe des SSSD ist es ebenfalls möglich, Host-based-Access-Control-Regeln und andere sicherheitsrelevante Einstellungen auf einem Client umzusetzen. Dazu zählt beispielsweise die Auswertung von SELinux-User-Mappings oder SSH-Host- und User-Keys. Der Client stellt hierfür im Frontend eine PAM-Schnittstelle ( »pam_sss« ) und eine NSS-Schnittstelle ( »nss_sss« ) zur Verfügung (siehe Abbildung 1 ). Im Backend kann er mit unterschiedlichen Providern kommunizieren, in diesem Fall mit dem FreeIPA-System. Die Konfiguration des Clients erfolgt mit »ipa-client-install« .

Sollen auch ältere Linux-Systeme, für die der SSSD nicht verfügbar ist, oder andere Unix-Maschinen an das Identity-Management-System angeschlossen werden, besteht die Möglichkeit, die Anbindung über die reguläre LDAP- und Kerberos-Schnittstelle zu realisieren. Dabei kommen die klassischen PAM- und NSS-Bibliotheken »pam_krb5« und »nss_ldap« ins Spiel. In diesem Fall stehen die erweiterten Features des SSSD, wie das Caching der Account-Informationen, nicht zur Verfügung.

Ich hoffe, der Artikel hat gezeigt, dass die Migration von einer rein LDAP-basierten Benutzer-Authentifizierung hin zu einem modernen und leicht zu verwaltenden Identity-Management-System kein Hexenwerk ist. Wer nähere Information zu dem besprochenen System sucht, der findet diese unter [1] .

Infos

  1. Thorsten Scherf, Der System Security Services Daemon, ADMIN 03/2012, http://www.admin-magazin.de/Das-Heft/2012/03/Der-System-Security-Services-Daemon
  2. FreeIPA: http://www.freeipa.org/page/Main_Page

Der Autor

Thorsten Scherf arbeitet als Principal Consultant für Red Hat. Er ist oft als Vortragender auf Konferenzen anzutreffen. Wenn ihm neben der Arbeit und Familie noch Zeit bleibt, nimmt er an Marathonläufen teil.

comments powered by Disqus
Mehr zum Thema

Mapping von Benutzer-IDs

Posix-Attribute sind fest an ein Benutzerkonto gebunden und helfen bei der Identifikation des Benutzers. Bei der Migration von einem Identity-Management-System zu einem anderen kann jedoch gerade dieser Umstand zu Problemen führen. Mit Hilfe von ID-Views lassen sich diese jedoch recht leicht in den Griff bekommen.
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023