Workshop: FreeIPA mit dem Active Directory integrieren

Brücken bauen

In vielen Unternehmen dient das Active Directory der zentralen Verwaltung vorhandener Systeme. Sollen auch Linux-Systeme in die Obhut des Verzeichnisdienstes genommen werden, ist einiges zu beachten. So gibt es verschiedene Formen der Integration. Wir zeigen, wie Sie das Identity-Management-Framework FreeIPA als Schnittstelle an eine Active Directory-Domäne anbinden.
Open Source-Software findet in immer mehr Unternehmen und Behörden ihren Einsatz. Im Juli widmet IT-Administrator daher seinen Heftschwerpunkt der quelloffenen ... (mehr)

Üblicherweise stellt ein Verzeichnisdienst neben klassischen Benutzer- und Gruppen-Accounts auch eine Vielzahl anderer Informationen zur Verfügung. Hierzu zählen etwa Maschinen- und Service-Konten, Sicherheitsregeln und eventuell auch DNS-Informationen sowie weitere Daten, die der Administrator gerne zentral vorhalten möchte, um sie von dort an die Clients in der Domäne auszuliefern.

Solche Daten lassen sich natürlich sowohl in einem Active Directory (AD) als auch jedem anderen Verzeichnisdienst ablegen – wobei es nicht unerheblich ist, welche Clients dann auf die Daten zugreifen sollen. So stellt ein AD für Windows-Clients eher eine native Schnittstelle zur Verfügung als für POSIX-Clients, was natürlich Auswirkungen darauf hat, wie gut die Integration der Clients funktioniert und welche Daten diese von dem Verzeichnisdienst abrufen, auswerten und umsetzen können.

Deshalb ist von großer Bedeutung, dass Sie unmittelbar am Anfang Ihrer Überlegungen definieren, welche Daten aus einem Windows-AD den Linux-Clients zur Verfügung stehen sollen. Geht es lediglich darum, AD-Benutzer zu authentifizieren, sodass diese auf Ressourcen eines Linux-Systems zurückgreifen können? Oder müssen diese auch entsprechende Security-Regeln auswerten können, damit der Zugriff auf die Ressourcen funktioniert? Und wo sollen diese Security-Regeln gespeichert werden? Das AD bietet hierfür zwar Funktionen an, allerdings orientieren sich die angebotenen Lösungen eher an Windows-Clients als an Linux-Systemen.

Letztendlich lassen sich zwei unterschiedliche Formen der Integration umsetzen. So besteht die Möglichkeit, Linux-Clients direkt in eine Windows-Domäne zu integrieren und diese komplett über einen AD-Domänencontroller zu verwalten. Variante 2 ist als eher indirekte Integration auf Basis einer Daten-Synchronisation oder eines Domänen-Trusts vorzunehmen. Bei der Daten-Synchronisation werden Benutzer-Accounts mit zuvor definierten Attributen auf einen anderen Verzeichnisdienst repliziert, der diese dann für Linux-Clients zur Verfügung stellt. Da diese Art der indirekten Integration allerdings mit einer Vielzahl von Nachteilen behaftet ist, gehen wir an dieser Stelle nicht näher auf diese Implementierung ein und verweisen lediglich auf die vorhandene Literatur zu dem Thema [1].

Direkte vs. indirekte Integration

Für eine direkte Integration kommt im Open Source-Umfeld oftmals das aus dem Samba-Projekt stammende Winbind zum Einsatz. Auch die manuelle Konfiguration der notwendigen PAM- und NSS-Module, die für den Zugriff auf den LDAP- und Kerberos-Server eines Windows-Domänencontrollers notwendig sind, wird von einigen Admins praktiziert. Heutzutage findet für ein solches Szenario in den allermeisten Fällen jedoch eher der System Security Services Daemon (sssd) [2] Verwendung. Zusammen mit der Software realmd [3] stellt dieser Ansatz die einfachste Methode dar, um Linux-Clients direkt in eine bestehende Windows-Domäne zu integrieren und somit über die vorhandenen Windows-Tools zu verwalten. Natürlich stehen auch proprietäre Tools für diese Aufgabe zur Verfügung. Die von Dell erhältlichen und ursprünglich von Quest entwickelten Authentication Services sind sicherlich auch dem einen oder anderen Administrator bekannt.

Für die direkte Integration spricht, dass in diesem Fall lediglich ein einzelner Identity-Store, das Active Directory, vorhanden ist und somit die einzige Quelle darstellt, aus der Benutzer-Informationen abgefragt werden können. Dies ist oftmals eine Anforderung von diversen Compliance-Richtlinien. Allerdings lassen sich gerade Security-relevante Informationen, die im Zusammenhang mit Benutzer- und Gruppen-Accounts stehen, die über ein Windows-AD verwaltet werden, oftmals nur ungenügend für Linux-Clients zur Verfügung stellen. Denken Sie nur an Konfigurationsdaten für sudo, SELinux Role-based Access-Control (RBAC)-Richtlinien oder andere infrastrukturrelevante Daten, beispielsweise für den Betrieb eines Automounters.

Diese Art von Daten lässt sich nur sehr eingeschränkt und sehr umständlich in einem Windows-AD ablegen, sodass eine Verteilung der notwendigen Konfigurationsdaten bei der indirekten Integration von Linux-Clients dann eher über andere Management-Tools wie beispielsweise Puppet, Foremann, Chef oder ähnlichen Werkzeugen stattfindet. Dieser Ansatz skaliert bei einer überschaubaren Menge an Client-Systemen sicherlich in ausreichendem Maße, stellt in großen Umgebungen aber bestimmt keine zufriedenstellende Lösung dar. In solchen Fällen sollten Sie sich eher mit der indirekten Integration auf Basis eines Kerberos-Trusts auseinandersetzen. Im Folgenden stellen wir Ihnen ein beispielhaftes Setup auf Basis des Identity-Management Frameworks FreeIPA [4] vor.

Vertrauensstellungen ermöglichen Datentransfer

Bei einem Domänen-Trust handelt es sich um eine Vertrauensstellung, die zwischen mindestens zwei Domänen hergestellt wird. Eine solche Vertrauensstellung wird beispielsweise immer dann eingerichtet, wenn sich Domänen in einer gemeinsamen AD-Struktur (Forrest) befinden. Hier lassen sich Benutzer aus der einen Domäne von einem Domänencontroller (DC) der anderen Domäne authentifizieren. Verantwortlich sind hierfür die sogenannten bidirektionalen und transitiven Vertrauensstellungen zwischen den Domänen, die Windows standardmäßig einrichtet. Als Protokolle kommen hierfür entweder Kerberos V5 oder NTLM zum Einsatz, wobei Kerberos den Standard für Active Directory-Domänen darstellt.

Das Open Source Identity-Management Framework FreeIPA stellt ebenfalls einen Kerberos-Realm zur Verfügung und kann diesen gegenüber einem Windows-AD als Teil einer eigenständigen Kerberos-Struktur präsentieren. Windows wiederum ist in der Lage, eine Vertrauensstellung zu einem solchen Kerberos-Realm herzustellen – auch wenn dieser nicht zu einer Windows-Domäne gehört. Wir sprechen in einem solchen Fall von einem Cross-Realm Trust. Windows-Benutzer bekommen dadurch die Möglichkeit, auf Ressourcen eines Linux-Systems zurückzugreifen, das Teil des Kerberos-Realms ist, zu dem eine Vertrauensstellung eingerichtet wurde. Da FreeIPA aktuell keinen Global Catalog Server bereitstellt, handelt es sich daher effektiv um einen unidirektionalen Trust, sodass Benutzer aus der FreeIPA-Domäne umgekehrt nicht auf Ressourcen der Windows-Domäne zurückgreifen können.

Das Windows-Konto ist dabei nach wie vor lediglich auf dem Windows-Domänencontroller gespeichert. Dieser kümmert sich auch im Weiteren um die Authentifizierung dieses Kontos. Anders als bei der Linux-Integration auf Basis einer Daten-Synchronisation, ist keine zusätzliche Software auf den Domänencontrollern zu installieren. Da eine Vertrauensstellung zwischen dem Windows-Realm und dem FreeIPA-Realm herrscht, können somit von Hause aus erst einmal alle Konten, die der DC verwaltet, auf Linux-Ressourcen im FreeIPA-Realm zurückgreifen. Dies gilt übrigens auch für Win­dows-Konten aus anderen Domänen, zu denen transitive Vertrauensstellungen existieren. Natürlich lässt sich der Zugriff auch einschränken, dazu später mehr.

Da FreeIPA (mittels PAM, NSS und diversen Hilfsanwendungen) eine native Schnittstelle für Linux- und andere Unix-Clients zur Verfügung stellt, eignet es sich hervorragend dazu, andere Domänen-relevante Daten an zentraler Stelle vorzuhalten und den Linux- und Unix-Clients bei Bedarf zur Verfügung zu stellen. Hierzu zählen insbesondere die bereits am Anfang des Artikels genannten, sicherheitsrelevanten Richtlinien, aber auch SSH-Benutzer- und Host-Schlüssel, SELinux-Benutzer-Mappings und andere Daten. Über den AD-Trust findet somit lediglich eine Authentifizierung von Benutzern der AD-Domäne statt. Alle anderen Daten stellt das FreeIPA-Framework seinen eigenen Client-Systemen zur Verfügung.

Mit einem Trust zwischen einem Windows-AD- und FreeIPA-Realm können Benutzer aus dem Active Directory auf Ressourcen der FreeIPA-Domäne zurückgreifen.
comments powered by Disqus
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