Abb. 1: Der LDAP-Baum des Beispiels als Diagramm.

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.

Das Thema einer einheitlichen zentralen Benutzerverwaltung beschäftigt die IT-Welt seit jeher und ist heute durch Entwicklungen wie Single Sign On und Public Key Infrastructures aktueller als je zuvor. Um eine einheitliche Benutzerverwaltung zu gewährleisten, nimmt der Administrator heutzutage NIS oder Yellow Pages.

Sind Ihre Anforderungen allerdings größer und Sie möchten gar Applikationen in ein zentrales Benutzerdaten-Konzept einbeziehen, dann hilft nur noch eine skalierbare Lösung weiter. Hierzu gehören Möglichkeiten für das Replizieren der Daten sowie zur Schaffung von verteilten Architekturen. LDAP (Lightweight Directory Access Protocol) bietet den Unterbau für solche Lösungen in seiner Rolle als zentraler Informationsdienst im Netzwerk.

LDAP ist in NDS (Novell Directory Services) und in Microsofts Active Directory integriert. Es ist ein offener Standard für einen Informationsdienst auf Basis einer baumähnlichen Datenbankstruktur. Gegenüber einer normalen Datenbank ist der Hauptvorteil die attributsbezogene Speicherung. LDAP ist aus X.500DAP entstanden, benutzt aber statt des OSI-Stacks den TCP/IP-Stack. Die Entwickler haben versucht den Datenaufbau im Vergleich zu X.500 zu vereinfachen, was sich beispielsweise in der Ablage von Daten im Klartext bemerkbar macht. Eine Ablage in dieser Form vereinfacht auch die Abfrage eines LDAP-Baums, da die Client-Seite nach einer Abfrage nicht mit umständlichen Encodings zurechtkommen muss.

LDAP schlägt die Brücke zu X.500 und minimiert zudem den Aufwand für Netzwerk und Netzwerksoftware (Clients). LDAP wurde in der Version 1 von der Universität Michigan ins Leben gerufen. Erst seit Version 2 besteht die Möglichkeit, LDAP im klassischen Client-Server-Modell zu benutzen, ohne dass Hauptlast auf die so genannten Clients verteilt wird. Mittlerweile liegt auch schon das Konzept für die Version 3 vor, deren Grundlagen im Wesentlichen bereits in die LDAP-Implementationen Einzug halten und Verbesserungen im Datenmodell mit sich bringen.

Datenaufbau

Im LDAP-Datenaufbau definiert eine Objektklasse eine Sammlung aus verschiedenen Attributen, die dazu benutzt werden können, einen Verzeichniseintrag zu beschreiben. Es existieren vordefinierte Objektklassen, die man für die Definition von Lokationen, Organisationen beziehungsweise Firmen, Personen oder Gruppen benutzen kann.

Mittels einer Objektklasse lässt sich ein Eintrag erzeugen. Ein typischer Eintrag in einen LDAP-Baum sieht etwa so aus:

cn=Volker Schwaberow, ou=IT, o=MyCompany, c=DE

Das wäre ein so genannter Distinguished Name (DN) beziehungsweise der eindeutige Name in einem LDAP-Baum (siehe Abbildung 1). Der Eintrag zeigt uns die Attribute cn, ou, o und c.

Auf den ersten Blick ist zu erkennen, dass das LDAP-Konzept hierarchisch aufgebaut ist. In Form des DN liest es sich von rechts nach links, vergleichbar mit dem Aufbau des Domain Name Service im Internet. Wie bereits erwähnt wird innerhalb eines DN mit Attributen gearbeitet. Oft gewählte Attribute im Standard-LDAP-Schema sind: Common Name (CN), Organizational Unit (OU), State (S) und Country (C).

Diese Attribute werden jeweils einer Objektklasse durch Definition zugeteilt. Häufig eingesetzte Objektklassen sind beispielsweise wieder Organization, organizationalUnit, Person, organizationalPerson und Country. Die definierten Objektklassen entscheiden darüber, was ein Eintrag enthalten kann. Der Eintrag einer Person in den LDAP-Baum kann zum Beispiel die Telefonnummer einer Person enthalten, ihren General Public Key oder nach Wunsch sogar ein JPEG-Bild, das von einem LDAP-Client dargestellt wird. Die Möglichkeiten sind schier unbegrenzt, sie hängen nur von der jeweiligen Anwendung ab und müssen, falls die Lösung der Anforderung nicht bereits in Form eines existierenden Attributs oder einer Klasse vorhanden ist, in das LDAP-Schema des Servers eingepflegt werden.

Benutzerdaten oder Organisationsdaten lassen sich über Textdateien im LDI-Format in dieses Schema einpflegen. LDIF (Lightweight Data Interchange Format) kann für sehr viele unterschiedliche Zwecke verwendet werden. Eintragungen vornehmen ist ein Beispiel, ein anderes der Export eines bestehenden LDAP-Baums in eine LDIF-Datei. Dank des LDI-Formats ist es leicht, LDAP-Daten zu bearbeiten. Eine nützliche Übersicht über LDIF gibt es bei [7]. Sie bezieht sich zwar auf den Directory Server von Netscape, man kann aber grundsätzliche Dinge ableiten.

Abb. 1: Der LDAP-Baum des Beispiels als Diagramm.

Nach den LDAP-Grundlagen aber nun zum Kern: OpenLDAP. Das Open-Source-Projekt ging vor einigen Jahren aus einem Server-Projekt der Universität Michigan [5] hervor. OpenLDAP besteht aus einem skalierbaren Server mit passenden LDAP-Clients und unterstützt seit Version 2 endlich auch die Protokolle der LDAP-(Konzept-)Version 3.

Installation von OpenLDAP

Nach dem Download der aktuellen Source-Distribution von [6] müssen noch einige Voraussetzungen erfüllt sein, bevor Sie kompilieren können. Hierzu gehört eine zur LDAP-eigenen LDBM kompatible Datenbank. LDBM-kompatibel sind zum Beispiel die Berkeley DB2 oder GDBM (GNU Data Base Manager). Übrigens kann OpenLDAP auch andere Back-Ends nutzen. Da alle Distributionen über eine von beiden oben genannten Datenbanken verfügen, sollte es keine großen Schwierigkeiten geben.

Somit können Sie auch gleich die Quellen entpacken:

tar xvfz openldap-stable-DATUM.tgz

Sie wechseln dazu in das Verzeichnis mit dem entpackten Source und führen

./configure -prefix=/usr/local/

aus. Hat das geklappt, folgen die Befehle:

make depend
make

Nachdem OpenLDAP kompiliert wurde, sollten Sie die Funktionalitätstests ausführen lassen. Hierzu wechseln Sie in das Directory tests unterhalb des Source-Baums und starten make.

Falls die Tests (Datenbank, Serverfunktionalität und so weiter) erfolgreich abgeschlossen sind, können Sie die OpenLDAP-Server und -Clients mit dem gewohnten Befehl

make install

installieren. Unter /usr/local liegt nun Folgendes: in libexec der slapd und der Replication Dämon slurpd sowie Gateways für X.500 (Fax, Mail und so weiter).

Unter bin liegen die OpenLDAP-Clients. Hier sind besonders diese drei Kommandos interessant:

Die Befehle funktionieren sowohl lokal als auch remote mit Zugriff auf einen entfernten LDAP-Server.

Konfiguration von OpenLDAP

Als Erstes verschieben Sie der Einfachheit halber das Verzeichnis /usr/ local/etc/openldap nach /etc/openldap, so dass die Konfigurationsdateien auch an der richtigen Stelle liegen. Wenn Sie nun nach /etc/openldap wechseln, finden Sie folgende Dateien für die mitgelieferten OpenLDAP-Clients:

Für die OpenLDAP-Server sind folgende Dateien gedacht:

Als Erstes rufen Sie die slapd.conf auf und sollten sie wie im Kasten “Konfiguration 1 slapd.conf” gezeigt ändern. Klassen und Attribute brauchen Sie jetzt nicht anzufassen. Bevor Sie sich aber näher mit OpenLDAP beschäftigen, sollten Sie zumindest einmal die Standard-Attribute und -Klassen anschauen.

# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include  /etc/openldap/slapd.at.conf
include  /etc/openldap/slapd.oc.conf
schemacheck on
referral ldap://myserver.mycompany.de/

pidfile  /var/run/slapd.pid
argsfile /var/run/slapd.args

############################################################
# ldbm database definitions
############################################################

database ldbm
suffix  "o=MyCompany, c=DE"
rootdn  "cn=Manager, o=MyCompany, c=DE"
rootpw  meinpasswort
directory /var/ldap/openldap-ldbm

defaultaccess none

access to attr="userpassword"
  by self write
  by * compare

access to *
  by self write
  by dn=".+" read
  by * none

access to *
  by dn="^$$" none
  by * read

dn: o=MyCompany, c=DE 
o: MyCompany 
l: Gelsenkirchen 
streetaddress: Emscherstr. 41 
postalCode: 45891 
telephonenumber: 0209-4711 
objectclass: organization

dn: cn=Manager, o=MyCompany, c=DE 
cn: Manager 
sn: Manager 
objectclass: person

dn: ou=IT, o=MyCompany, c=DE 
ou: IT 
objectclass: top 
objectclass: organizationalUnit

dn: ou=Finanzen, o=MyCompany, c=DE 
ou: Finanzen 
objectclass: top 
objectclass: organizationalUnit

dn: cn=Volker Schwaberow, ou=IT, o=MyCompany, c=DE 
objectclass: top 
objectclass: person 
objectclass: organizationalPerson 
objectclass: inetOrgPerson 
cn: Volker Schwaberow 
sn: Schwaberow 
telephonenumber: 0209/4712

dn: cn=Bernd Schlaefer, ou=Finanzen, o=MyCompany, c=DE 
objectclass: top 
objectclass: person 
objectclass: organizationalPerson 
objectclass: inetOrgPerson 
cn: Bernd Schlaefer 
sn: Schlaefer 
telephonenumber: 0209/4713

dn: cn=Volker Schwaberow, ou=IT, o=MyCompany, c=DE  
changetype: modify 
replace: telephonenumber 
telephonenumber: 0209/4716512

Falls Sie das Modell aufgrund eines eventuellen Andockens von spezieller Serversoftware (zum Beispiel Netscape-Suitespot-Produkte) verändern müssen, können Sie zusätzliche Attribut- oder Klassenänderungen mittels include Dateiname in der Datei slapd.conf einpflegen. Achten Sie auch darauf, dass Sie Ihr Manager-Passwort selbstverständlich nicht wie im gezeigten Beispiel im Klartext in slapd.conf unterbringen sollen. Hier werden SHA, MD5 oder CRYPT als Passwort-Verschlüsselung von OpenLDAP akzeptiert.

Mit den zwei include-Anweisungen in der Datei slapd.conf im Kasten-Beispiel werden die Standard-Attribute und -Klassen geladen. Wichtig ist die Zeile mit database. Hier wird eine LDBM-kompatible Datenbank als Back-End gewählt. Das Schlüsselwort suffix definiert den DN der Anfragen, der gegenüber unserem Server laufen kann.

Der Eintrag rootdn ist klar, dieser DN hat alle Operationsrechte und dient dem Administrator als Bind, um Operationen am LDAP-Baum vorzunehmen. Mit der directory-Zeile wird festgelegt, wo der slapd seine Datenbank ablegt. Dieses Verzeichnis ist vorab anzulegen und mit den Dateirechten rwx ( chmod 0700) für den Benutzer zu versehen. In den weiteren Zeilen folgen die Zugriffsrechte beziehungsweise ACLs (Access Control List) für den LDAP-Baum. Der Default-Access liegt hier auf none. Dann bekommt jeder authentifizierte Benutzer self write-Rechte auf das Attribut userpassword – jeder Benutzer darf sein eigenes Passwort innerhalb des LDAP-Baums abändern. Die letzte ACL dient dem Zulassen von anonymous binds, so dass etwa auch eine Adressbuch-Applikation ohne dedizierten LDAP-Baum-Benutzer auf den Service zugreifen kann.

Nachdem Sie damit die Grundeinstellungen für den slapd-Server vorgenommen haben, sollten Sie versuchen ihn zu starten:

/usr/local/libexec/slapd -f /etc/openldap/slapd.conf

Nun kontrollieren Sie, ob der Server korrekt gestartet ist, und zwar am besten mit ps -ax | grep slapd. Der LDAP-Service läuft als Standard auf Port 389. Das sollte natürlich auch in /etc/services vermerkt sein. Bitte beachten Sie, dass der SLAPD mit TCP-Wrapper-Support kompiliert werden kann, um zusätzliche Sicherheit zu erzeugen.

Die ersten Einträge im Verzeichnis

Wenn der Server läuft, versehen Sie das Verzeichnis mit den ersten Einträgen. Dazu sollten Sie die Angaben aus dem Kasten “Konfiguration 3” in eine separate Datei mit der Endung LDIF übernehmen. Hier muss zuerst die Organisation angelegt werden. Im gezeigten Beispiel ist das also o=MyCompany, c=DE. Beachten Sie, dass Ihre LDIF-Datei auf jeden Fall von Formatierungen abhängt und genauso erstellt werden muss wie im Beispiel angegeben, damit die Übernahme klappt.

Der Einfachheit halber speichern Sie Ihre initiale LDIF-Datei auch ins Verzeichnis /etc/openldap – falls Sie sie zu einem späteren Zeitpunkt wieder benötigen. Die fertige LDIF-Datei wird nun mit der Befehlszeile

ldapadd -D "cn=Manager, o=MyCompany, dc=DE" -W < LDIF-Dateiname

importiert. Nachdem der Manager-Account bekannt gemacht ist, legen Sie noch zwei weitere Organisationseinheiten an. Dabei handelt es sich einmal um die IT und um das Ressort Finanzen. Abschließend werden noch zwei Personen den einzelnen Bereichen zugeordnet, einmal der Autor und außerdem noch ein Herr Bernd Schlaefer.

Wenn die Einträge hinzugefügt sind, kann das Verzeichnis das erste Mal durchsucht werden. Das geht über das Kommando ldapsearch. Angenommen den Fall, dass Sie alle Einträge im Verzeichnis suchen und listen wollen, dann heißt das korrekte Kommando dafür:

ldapsearch -D "cn=Manager, o=MyCompany, c=DE" -b "o=MyCompany, c=DE" "(objectclass= *)"

Bei großen Installationen ist das aber mit Vorsicht zu genießen. Sie suchen nun alle cn mit der Zeichenkette Vol am Anfang – das sollte einen Eintrag zurückgeben. Der Befehl hierzu ist:

ldapsearch -D "cn=Manager, o=MyCompany, c=DE" -b "o=MyCompany, c=DE" "(cn=Vol*)"

Deutlich wurde anhand der beiden Beispiele, dass die Suchattribute runde Klammern verlangen.

Nun könnte sich etwa die Telefonnummer des Autors oder eine andere Größe ändern. Dazu sollten Sie eine LDIF-Datei nach Muster LDIF Modify File (im Kasten zu finden) mit den Daten des Autors anfertigen und dort die Telefonnummer ändern. Dieses LDIF-File wird mit folgendem Kommando eingepflegt:

ldapmodify -D"cn=Manager, o=MyCompany, c=DE" -W < LDIF-File

Das gezeigte Verfahren zeichnet sich zwar nicht gerade durch Benutzerfreundlichkeit bei einem Eintrag aus, kann sich aber bei größeren Änderungen durchaus bezahlt machen. Lästige Fehlerquellen können durch Debugging vor dem Modify sichtbar gemacht werden.

Die Abfrage des Verzeichnisses durch Mail-Clients

Nach den drei Standardoperationen, die Ihr Verzeichnis lokal erfahren hat, sollten Sie eine Abfrage durch einen Mail-Client durchführen. Tippen Sie folgende URL in Ihren Browser (zum Beispiel Netscape 4.x):

ldap://myserver.mycompany.de/o=MyCompany, c=DE??base

Daraufhin wird Netscape Sie fragen, ob Sie diesen Server zu Ihren LDAP-Einstellungen hinzufügen möchten. Nachdem das passiert ist, kann der eingerichtete LDAP-Server über den Punkt Adressbuch abgefragt werden. Wenn die Adressierung richtig konfiguriert ist, wird gar bei der Eingabe eines Namens im Feld An im Mail- Client das gesamte LDAP-Verzeichnis nach Treffern durchsucht. Nach der Eingabe von

ldap://myserver.mycompany.de/o=MyCompany, c=DE??sub

in den Browser bekommen Sie sogar das ganz Verzeichnis über HTML präsentiert.

Änderungen ohne LDIF-Datei per Editor vornehmen

Doch was ist, wenn Sie nur einen kleinen Eintrag ändern möchten? Es wäre ziemlich viel Geduld erforderlich, wenn man alles über eine LDIF-Datei regeln wollte. Hier bietet sich eher ein so genannter LDAP-Editor an. Einen solchen Editor in einer Java-Implementation finden Sie zum Beispiel unter [8]. Weitere Empfehlungen sind unter [9] (GQ für Gtk) und [10] (Kldap) angegeben. Ein LDAP-Browser erlaubt auch eine Darstellung der LDAP-Baums als Strukturdiagramm und macht damit Änderungen einfacher.

Programmiersprachen und LDAP

Interessante Möglichkeiten bietet die LDAP-Unterstützung durch diverse Programmiersprachen. Sehr schnell ist dann eine umfangreiche Adressverwaltung für das heimische Intranet erstellt, wenn Sie Sprachen wie etwa PHP einsetzen. Listing 1 zeigt eine LDAP-Baumauflistung per Anonymous Bind über PHP.

<?
 // LDAP Example By V. Schwaberow
 // for Linux-Magazin 2001
 echo "<html><head><title>LDAP Test</title></head><body>";

 //Stelle TCP Verbindung zur LDAP Datenbank her.
 //Hier steht die IP Adresse des LDAP Servers.
 $connection = ldap_connect("192.168.10.248");

 if ($connection){

 // Anonymous bind, zum Abfragen laut ACL ausreichend!
 // Falls Änderungen erfolgen sollen, ist allerdings
 // ein gültiger DN nötig.
 $result = ldap_bind($connection);

 // Suche nach allen CN Attributseintragungen im LDAP tree.
 $search = ldap_search($connection,"o=MyCompany,c=de","cn=*");

 // Array von Ergebnis der Suche.
 $entries=ldap_get_entries($connection,$search);

 echo "<table cellspacing="0" cellpadding="0" border="2">";

 // Tabellenschleife
 for ($i=0;$i<$entries["count"];$i++){
 $cn=$entries[$i]["cn"][0];
 $dn=$entries[$i]["dn"];
 $phone=$entries[$i]["mail"][0];
 echo "<tr>";
 echo "<td>";
 echo "<td>";
 echo "<td>";
 echo "<td>";
 echo "</tr>";
 }

 // Schliesse Verbindung zum Server.
 ldap_close($connection);
}
else {
 echo "kann keine Verbindung zum LDAP-Server herstellen!";
 }

 echo "</table></body></html>";
?>

Damit ließe sich für den Benutzer schon eine recht einfache E-Mail-Adressenauskunft realisieren. Der LDAP-Baum wäre sogar über ein PHP-Skript zu verwalten, zum Beispiel könnte man für eine andere Fachabteilung den generellen Zugriff auf die Telefonnummern im LDAP-Stamm schaffen.

Auch Perl bietet sehr viele Möglichkeiten zum Einbinden von LDAP in ein Skript. Im CPAN-Archiv steckt die Net-LDAPapi-Schnittstelle, siehe [11]. Wesentlich handlicher ist allerdings das Perl-Modul Net-LDAP, das Sie unter [12] finden können. Ein kleines Perl-Beispiel sehen Sie im Listing 2. Selbstverständlich gibt es außerdem die Möglichkeit, LDAP-Anbindungen unter Java beziehungsweise C/C++ zu programmieren; wobei die Sympathie des Autors der Java-Variante gehört.

#!/usr/bin/perl
# 
# Net::LDAP Test for Linux-Magazin
#

use Net::LDAP;

# Neues Net::LDAP Objekt

 $ldap = Net::LDAP->new(`myserver.mycompany.de'); 

# anonymous bind

 $ldap->bind;

# Die Suchanfrage

 $state = $ldap->search ( 
      base => "o=MyCompany, c=DE", 
      filter => "(objectclass=*)" 
    ); 
# Ausgabe der Entries

 foreach $buffer ($state->all_entries)  
 {
  print $buffer->dump; 
 }

Weitere Möglichkeiten und Sicherheitsaspekte

Beim zentralen Informationsdienst im Netzwerk besteht die Möglichkeit, Standards an eine Authentifikation gegenüber dem eingerichteten Verzeichnis zu binden. Das ist durch den Austausch des Login-PAM-Moduls machbar. Anmeldungen an einen Linux-Server können gegenüber einem Verzeichnis verifiziert werden. Diese Lösung gibt es auch für den Apache sowie für Squid, Qmail und weitere Server-Dienste.

Auf dem Markt tummeln sich recht viele Anbieter, die solche Single-Sign-On-Lösungen für viel Geld verkaufen. Dass dieses Feature auch kostenlos erhältlich ist, beweist zum Beispiel das Plugable Authentification Module von PADL Software. Es ist Open Source, erhältlich auf [13] und bewährt sich im Alltagsbetrieb besser als manch teure SSO-Lösungen diverser Hersteller. OpenLDAP lässt sich außerdem als PKI-Server (Public Key Infrastructures) nutzen. Hier ist vor allem das Oskar-PKI-Projekt [14] zu nennen.

Die Access Control Lists (ACLs) sind Ihnen schon bekannt. Sie beschränken den Zugriff nach unterschiedlichen Kriterien auf Attribute. Noch läuft jedoch der Zugriff auf den Verzeichnisdienst völlig unverschlüsselt. Das können Sie durch den Einsatz eines so genannten SSL-Wrappers ändern. Als Standard benutzt ein LDAP-Server den Port 389. Die meisten Clients unterstützen auch SSL-verschlüsseltes LDAP. Ein häufig eingesetzter SSL-Wrapper ist beispielsweise der Sslwrap [15].

Die Zukunft

Führt man sich die heute üblichen Methoden für die Verwaltung eines Netzwerks vor Augen, ist festzustellen, dass es zu viele unterschiedliche Dienste gibt, die Einstellungen und Benutzerdaten lokal auf den Servern bereithalten. Eine große Erleichterung brächte die Zentralisierung dieser Daten mit sich. Damit wird auch schnell einsichtig, warum Enterprise-Produkte von Haus aus eine LDAP-Schnittstelle mitbringen.

Bleibt also nur zu hoffen, dass Firmen gerade in diesem Bereich das Potenzial von Linux und Open Source erkennen. Eine Integration von Directory Services auf Basis von Open Source kann Kosten minimieren und gleichzeitig die Stabilität und Zuverlässigkeit der Systeme erheblich verbessern. ( jk)