Ein virtuelles Directory mit dem Fedora 389 Directory Server aufsetzen

Auf der Liste

,
Wie man Linux mithilfe des Fedora 389 Servers in mehrere Active-Directory-Domänen integriert und dabei Chaining und Pass-Through-Authentication nutzt.
Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL. Der Schwerpunkt vom ADMIN 06/2011 überprüft, wer schneller ist und gibt einen ... (mehr)

Geht es nur um eine einfache Betriebssystemumgebung, ist es relativ leicht, ein Identity-Management-System aufzusetzen. Kommen aber mehrere Betriebssysteme ins Spiel, werden die Dinge sehr schnell komplizierter. Dieser Artikel zeigt, wie man Linux-Clients in eine Umgebung mit mehreren Domänen des Active Directory (AD) integriert.

Das Problem kennt verschiedene Lösungen (siehe dazu den Kasten "Identity-Management-Lösungen" ), von denen sich der vorliegende Beitrag auf den Fedora 389 Directory Server (389 DS) konzentriert. Das ist ein hoch skalierbarer LDAP-Server mit vielen fortgeschrittenen Features einschließlich Multi-Master-Replikation, Synchronisierung von Usern und Gruppen mit dem Active Directory und der Fähigkeit, andere LDAP-Verzeichnisse zu virtualisieren.

Identity-Management-Lösungen

Typischerweise benutzen Linux-Clients das NSS-LDAP-Modul, um von LDAP-Servern Informationen über Benutzer und Gruppen abzufragen. Dieses Modul bietet allerdings keinerlei Möglichkeiten, um mehrere LDAP-Server zu kontaktieren und die zusammengefassten Ergebnisse zurück an den Client zu übermitteln. Für diese Aufgabe gibt es stattdessen drei erfolgversprechende Lösungsansätze: Replikation, virtuelle Directories und spezielle Clients.

Viele Directory Server, darunter OpenLDAP, 389 DS oder das Oracle Internet Directory haben eingebaute Features für eine Synchronisation von Einträgen aus einem Active Directory. Obwohl die Replikation von User- und Gruppenobjekten in der Regel gut funktioniert, hat sie doch einige Beschränkungen. So lässt sich nur eine kleine Untermenge der Attribute replizieren. Besonders die Synchronisation von Passwörtern aus dem AD kann mühsam sein, speziell in großen Umgebungen. Als eine Alternative bietet sich immer die Umleitung der Authentification Requests via SASL oder LDAP Binds an, wie in diesem Beitrag beschrieben.

Wo die Replikation nicht möglich oder angezeigt ist, kommen virtuelle Directories infrage, die als Proxies ein zentralisiertes Repository bilden. Der 389 DS bietet zwar einige Ansätze für virtuelle Directories, doch fehlen ihm fortgeschrittenere Features wie das Attribut-Mapping.

Schließlich enthalten spezielle Clients Samba/Winbind, um Windows-Controller zusammenzuschließen.

Dazu gehören Softwareprodukte wie Likewise Enterprise, das es auch in einer freien Open-Source-Version gibt [8] . Likewise hat den zusätzlichen Vorteil, dass es die AD Gruppen-Policen integriert, um Identity-Management-Aspekte von Linux, Windows und Mac zu kontrollieren.

Architektur

Abbildung 1 gibt einen Überblick über die Architektur, um die es in diesem Beitrag geht. Wie man sieht, sind zwei Windows-Domänen-Controller im Spiel mit den voneinander verschiedenen Namens-Kontexten »dc=foo, dc=example, dc=local« beziehungsweise »dc=bar, dc=example, dc=local« . Das Ziel ist, SSH-User zu authentifizieren, deren Benutzername und Passwort in den Active Directory-Servern gespeichert sind.

Abbildung 1: Das hier behandelte Setup besteht aus einem Linux-Client, dem 389 Directory Server und zwei Active-Directory-Instanzen.

Um die User-Einträge der beiden AD-Server in einem einzigen Repository zusammenzuführen (was für die meisten Linux-Clients Voraussetzung einer erfolgreichen Suche ist), benutzen wir den Fedora 389 Directory Server. Obwohl es für den 389 DS ein Plugin zum Synchronisieren von Usern aus einem AD gibt, wollen wir hier einen anderen Weg verfolgen und die Chaining sowie die Pass-Through-Authentication nutzen. Das eröffnet uns die Möglichkeit, ein virtuelles Directory zu erzeugen, das als Proxy zwischen LDAP-Clients und mehreren LDAP-Servern agiert. Der Proxy zeigt damit eine vereinheitlichte Ansicht aller Einträge, so als würden sie aus einem einzigen LDAP-Server stammen. Der Directory Server leitet an ihn gerichtete Anfragen an den richtigen LDAP/AD-Server weiter, ohne dass etwas zu synchronisieren wäre.

Diese Herangehensweise hat einige Vorteile verglichen mit Windows Sync, beispielsweise eine geringere Komplexität. Im Interesse einer größtmöglichen Flexibilität speichert das hier besprochene Setup alle User-Einträge (Name, UID, Shell und so weiter) im Active Directory und bildet Autorisierungsgruppen im 389 DS. Die Konfiguration wurde mit RHEL 5 und Windows Server 2003 R2 getestet, sollte prinzipiell aber auch mit anderen aktuellen Linuxdistributionen funktionieren. Wem Begriffe wie Suffix, Distinguished Name oder Attribute wenig sagen, der sollte sich zunächst etwas mit der Funktionsweise von LDAP beschäftigen. Der Kasten "LDAP-Primer" ist vielleicht ein Ausgangspunkt, für tiefer gehende Erklärungen empfiehlt sich etwa [1] .

LDAP-Primer

Das Lightweight Directory Access Protocol (LDAP) ist ein offenes Protokoll für die Speicherung, den Zugriff und die Aktualisierung von Verzeichnisinformationen. Ein Verzeichnis ist dabei eine spezielle Art von Datenbank. die für Leseoperationen optimiert ist. LDAP definiert das Format der Messages, die Client und Server austauschen (search, modify, delete, und so weiter)

Verzeichnisse (Directories) enthalten Einträge (Entries), die ihrerseits ein oder mehrere Attribute haben. Abhängig von der Objektklasse können die Attribute zwingend nötig oder optional sein. Jedes Attribut hat einen Typ, der bestimmt, welche Werte das Attribut annehmen kann. Verzeichnisse sind in einer baumartigen Struktur organisiert. Die Basis bildet ihr Distinguished Name (DN), der sich aus relativen DNs (RDNs) zusammensetzt.

Ein Beispiel: »cn=Alex, ou=IT, dc=example, dc=com« ist der DN eines Eintrags, der einen Benutzer namens Alex repräsentiert, der zu einer Organisationseinheit IT gehört und in einem Directory mit dem Root-Suffix »dc=example, dc=com« gespeichert ist. Dieser Eintrag könnte vom Typ Person sein, der noch andere optionale oder verbindliche Felder enthält wie den Familiennamen oder auch die Telefonnummer. Er könnte außerdem zu einer bestimmten Klasse von Objekten gehören, zum Beispiel der Klasse »posixAccount« , die ihrerseits noch andere Attribute definiert, etwa UID und GID oder »loginShell« .

LDAP-Verzeichnisse lassen sich für die Verwaltung von Benutzeraccounts in einem zentralen Repository nutzen und haben in dieser Funktion andere zentralisierte Repositories wie zum Beispiel NIS verdrängt.

AD und Unix-Attribute

Der erste Schritt besteht darin, Microsofts Active Directory Server zu ertüchtigen, UNIX UIDs und GIDs, Home Directories und so weiter zu speichern. Auf einem Active Directory Server unter Windows 2003 R2 kann man dafür die Identity Management Unit für Unix installieren, die es auch für Windows 2008 gibt. Die Installation des Pakets ist einfach: In der Systemsteuerung klickt man auf »Programme« »Programme und Funktionen« »Windows-Funktionen aktivieren« und selektiert dort »Identity Management for Unix« ( Abbildung 2 ). Um das Erzeugen einer NIS-Domäne braucht sich der Admin dabei glücklicherweise keine Gedanken machen.

Abbildung 2: Das Identity-Management für Unix installieren.

Nach der Installation ist das LDAP-Schema, das die AD-Struktur abbildet, erweitert. Um die Auswirkungen dieses Schritts zu sehen, editiert man einen Benutzer, den man auf einer Linux-Maschine authentifizieren will. Der Dialog sollte nun einen neuen Tab »Unix-Attribute« haben ( Abbildung 3 ).

Abbildung 3: Unix-Attribute für einen Benutzer im Active Directory konfigurieren.
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