Open Source im professionellen Einsatz
Linux-Magazin 03/2004

LDAP-Server mit Tcl bearbeiten

Baum-Pflege

Per Lightweight Directory Access Protocol lassen sich Benutzerdaten zentral in einer Baumstruktur verwalten. Linux, Apache oder E-Mail-Clients greifen zur Authentifizierung oder für Kontaktinformationen darauf zu. Dank der LDAP-Erweiterung bearbeiten auch Tcl-Programme die Daten auf dem LDAP-Server.

1231

Wer als Admin viele Rechner und Benutzer betreut, ist es schnell leid, die Passwortdateien verschiedener Rechner und Dienste zu synchronisieren. Auch um Kontaktdaten zentral zu speichern sind einfache Lösungen gefragt - es muss nicht gleich ein CRM-System sein (Customer Relationship Management). In beiden Fällen hilft ein LDAP-Server, der die Daten zentral anbietet. Das Lightweight Directory Access Protocol (LDAP) wird von vielen Programmen und Betriebssystemen eingesetzt, um Daten über Personen, Organisationstrukturen oder Rechner abzufragen.

Als Server kommt vor allem der Slapd aus dem OpenLDAP-Projekt[1] zum Einsatz, es gibt aber auch kommerzielle Alternativen von Sun oder Netscape. Für die Client-Seite greifen Tcl-Programmierer auf die LDAP-Erweiterung von Tcl zurück, sie automatisieren damit komplexere Aufgaben oder konvertieren und übertragen Daten. Diese Erweiterung gehört bei allen wichtigen Distributionen zum Lieferumfang, die Quellen sind bei[1] zu finden.

Als Einstieg zeigt Listing 1 eine einfache LDAP-Abfrage von Personendaten. Das Beispiel verwendet den öffentlichen LDAP-Server der kalifornischen Chapman-Universität, zu dem das Kommando »LdapBind« (Zeile 9) eine anonyme Verbindung herstellt. Anonyme Verbindungen benötigen keinen Usernamen und kein Passwort, jeweils ein leerer String genügt. Wie bei anderen Datenbankverbindungen auch ist das Ergebnis von »LdapBind« ein Handle, das die Verbindung bei den weiteren Kommandos identifiziert.

Die LDAP-Baumstruktur

Danach fragt »LdapSearch« die Daten eines Eintrags ab. LDAP-Server enthalten baumartig strukturierte Daten, die möglichen Knotentypen und ihre Werte sind durch das jeweils verwendete Schema beschrieben. Standardschemata für verbreitete Knotentypen wie etwa Personen, Organisationen, Gruppen und weitere sind in den RFCs 1274, 2307 und 2798 festgelegt.

Jeder Knoten lässt sich durch den so genannten voll qualifizierten Namen eindeutig wählen. Dieser Name besteht aus den Namen aller Elterneinträge und dem eigenen Namen des Knotens. Der Aufbau einer typischen LDAP-Struktur ist in Abbildung 1 zu sehen: Der Datenbankeintrag »Kontaktdaten« hat zwei Kinder vom Typ »organization« (Firmeneintrag). Beim linken Ast sind mehrere Attribute abgebildet, diese können auch mehrfach vorkommen, wie »objectclass« zeigt. Am rechten Ast ist zusätzlich ein Personeneintrag angehängt.

Abbildung 1: Unter dem Startknoten »dc=Kontaktdaten« sind in diesem LDAP-Server Organisationen und Personen gespeichert. Der voll qualifizierte Name von Mustermann lautet »cn=Mustermann, o=Acme GmbH, dc=Kontaktdaten«.

Anders als von SQL-Datenbanken bekannt starten LDAP-Suchvorgänge immer von einem bestimmten Knoten aus, sie berücksichtigen nicht die darüber liegenden Einträge. Der Anfrager kann die Suchtiefe begrenzen, mögliche Werte sind »base« (nur Attribute aus dem Startknoten), »one« (nur direkte Kinder) oder »sub« (alle Kindknoten). Neben dem Suchbereich lässt sich auch die Anzahl der möglichen Ergebnisse einschränken, »0« steht für beliebig viele. E

Die »LdapSearch«-Parameter (siehe Tabelle 1) Suchtiefe, Deref, Start-DN und Max-Results beschränken den Suchbereich und die möglichen Ergebnisse, der Suchfilter bestimmt die gewünschten Knoten. Hier kommt ein Suchfilter zum Einsatz, wie ihn auch andere LDAP-Werkzeuge verwenden. Optional beschränkt die Attributliste auch die Knotenwerte. LDAP-Datenbanken können sehr groß werden, im produktiven Einsatz sind Verzeichnisse mit mehreren Millionen Einträgen. Die Suchanfrage exakt und eng eingrenzend zu formulieren ist daher in großen Verzeichnissen entscheidend.

Tabelle 1:
LDAP-Kommandos

 

Kommando

Erklärung

LdapInit

Initialisiert die Tcl-Erweiterung

LdapBind Host Port UserDN Passwort

Gibt die Verbindung zurück

LdapUnBind Verbindung

Schließt die Verbindung

LdapDelete Verbindung DN

Löscht den Eintrag mit der DN

LdapModify Verbindung DN Attributliste

Ändert oder löscht Attribute

LdapAdd Verbindung DN Attributliste

Erzeugt einen neuen Eintrag

LdapSearch Verbindung Suchtiefe Deref Start-DN Max-Results
Suchfilter Attributnamenliste

Sucht Einträge und gibt eine Liste mit Werten
zurück

In Listing 1 sind zwei Abfragen enthalten. Die erste (Zeilen 11 bis 15) ermittelt vier Attribute eines bekannten Knotens, die Suchtiefe ist deshalb mit »base« auf null gestellt. Die Ausgabe ist in Abbildung 2 (oberer Abschnitt) zu sehen, sie besteht aus einer Liste. Für jedes Attribut enthält sie Namen und Wert.

Abbildung 2: Das Ergebnis der Suchanfrage von Listing 1. Die »LdapSearch«-Funktion liefert eine Liste mit den Attributen der gefundenen Einträge. Leere Listenelemente »{}« trennen die Einträge voneinander.

Die zweite Abfrage startet bei einem Organisationseintrag und sucht maximal zehn Personeneinträge, die mit dem Buchstaben »a« beginnen. Wie in Abbildung 2 zu sehen ist, kommen auch hier die Ergebnisse als Liste zurück, die jeweils zu einem Eintrag gehörenden Werte werden durch leere Listenelemente »{}« getrennt.

Dieses Ausgabeformat ist allerdings für das weitere Verarbeiten ziemlich unhandlich, deshalb ist in Listing 2 eine Hilfsprozedur angegeben. Sie schreibt die Werte der Liste in ein Array, so wie es von den diversen SQL-Erweiterungen bekannt ist. Folgende Kommandos rufen - am Ende von Listing 1 eingefügt - die Hilfsfunktion auf und geben dann das Array aus:

inArray $resultat2 a
parray a


Die Ausgabe des »parray«-Aufrufs beginnt wie folgt:

a(0,cn)   = Esmael Adibi
a(0,uid)  = adibi
a(1,cn)   = Claudia Alfaro
a(1,uid)  = calfaro


Die Ausgabe endet nach dem zehnten Eintrag (Nummer 9). Die Tabelle enthält auch ein Length-Feld, das die Anzahl der Elemente nennt:

a(9,cn)   = Mark Axelrod
a(9,uid)  = axelrod
a(length) = 10


LDAP-Server sind für viele Abfragen auf relativ statische Inhalte konzipiert, aber irgendwann müssen die Einträge auch in den Server gelangen. Ohne Skriptsprache sind per Hand LDIF-Dateien zu erzeugen und dann mit »ldapadd« einzufügen.

Einfacher geht es mit Tcl, siehe Listing 3. Mit wenigen Zeilen liest das Skript eine »/etc/passwd«-Datei und legt alle neuen Accounts, deren User-ID größer oder gleich 500 ist, im LDAP-Server ab. So lassen sich schnell ganze Rechnerparks auf PAM (Pluggable Authentication Modules) mit einem LDAP-Server zur zentralen Datenhaltung umstellen. Für einen Einstieg in dieses Thema bietet sich[2] an, weitergehende Informationen finden sich bei[3].

Das Opt-Paket wertet die Kommandozeile aus

Um die Verbindungsdaten wie Server, Port und Basis-DN bequem per Kommandozeilenparameter zu erfahren, verwendet das Skript das Opt-Paket (ab Zeile 37). Es gehört seit langem zum Lieferumfang von Tcl, allerdings fehlt immer noch die Dokumentation - eine frühere Feder-Lesen-Folge[4] hat dieses Paket bereits vorgestellt. Anders als Listing 1 kann Listing 2 keinen anonymen Zugang verwenden, da dieser meist keine Schreibrechte hat. Im Zusammenhang mit Authentifizierungsdaten wäre das auch ein gefährliches Sicherheitsloch. Trotzdem sind die Kommandozeilenparameter »userDN« und »passwort« als optional gekennzeichnet (Fragezeichen in Zeilen 41 und 42).

Der größte Teil des Skripts (Zeilen 6 bis 35) dient dazu, die Passwd-Datei auszulesen und in die einzelnen Einträge aufzuteilen. Die Foreach-Schleife in Zeile 11 weist den Inhalt jedes Felds einer Variablen zu. Sie verarbeitet jeweils nur eine Zeile, die Schleife läuft daher immer genau einmal ab. Dennoch ist die Foreach-Syntax sehr vorteilhaft, da sie die Elemente einer Liste einzelnen Variablen zuweist. Die Anweisung »[split $line :]« trennt die Passwd-Zeile an jedem Doppelpunkt auf und gibt sie danach als Liste zurück.

Das »LdapAdd«-Kommando (Zeile 29) erwartet den voll qualifizierten DN (Distinguished Name) des neuen Eintrags sowie eine Liste mit allen Attributen. Die Attribute sind in der gleichen Form anzugeben, wie sie »LdapSearch« als Ergebnis liefert. Das Skript stellt diese Liste in der Variablen »attribute« zusammen, neben dem Verweis auf den richtigen Eintragstyp (Zeile 9) erhält sie die gleichen Felder wie die »/etc/password«-Datei (Zeilen 21 bis 26).

Das Skript zeigt auch die Fehlerbehandlung bei der LDAP-Erweiterung. Jedes Kommando kann Fehler werfen, die das Skript mit »catch« auffangen sollte (Zeilen 16 und 30). Die meisten Fehler sind auf eine gestörte Verbindung oder fehlende Rechte auf dem Server zurückzuführen. Eine weitere Fehlerquelle ist »LdapSearch«: Scheitert die Suche, dann beginnt der Ergebnisstring mit »Search failed« (Zeile 53).

Weitere 30 Zeilen Tcl-Code würden genügen, um auch »/etc/groups« in den LDAP-Server zu füllen. Mit diesen Skripten gestaltet sich der Umstieg auf PAM-Authentifizierung mit LDAP-Anbindung recht bequem.

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Webanwendungen

    Statt die Authentifizierung und Rechtezuordnung für die Nutzer von Webanwendungen aufwändig mittels Tabellen in Datenbanken zu managen, lässt sich diese Aufgabe als Admin auch bequem und sicher über ein vorhandenes LDAP erledigen.

  • LDAP und Samba 4

    Mit Samba 4 lässt sich ein Active-Directory-kompatibler Domain Controller betreiben. Das Linux-Magazin schaut sich die Choreografie des darin enthaltenen LDAP-Verzeichnisses genauer an.

  • Straffe Verwaltung

    Der Verzeichnisdienst Lightweight Directory Access Protocol bringt Struktur und Übersicht in den Wirrwarr der Server-Administration. Mit OpenLDAP und Linux kommt der Administrator sogar Lizenzkosten-neutral in diesen Genuss.

  • Zentrale Meldestelle

    Einen Account unter Linux, Windows und anderen Plattformen nutzen: Mit LDAP als Basis sowie NSS, PAM und Samba als Helfer gelingt die zentrale Benutzerverwaltung.

  • Zentral erfasst

    Egal ob man eine eigene Webanwendung schreibt oder nachträglich eine freie Lösung aufbohren will: Die Benutzerinformationen in einem LDAP-Verzeichnis zu speichern schafft Login-Synergien und bringt Konsistenz in die eigene IT-Landschaft. Fehlt nur die LDAP-Authentifizierung.

comments powered by Disqus

Ausgabe 04/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.