© tunedin123 / 123rf.com

Viele Unternehmen vertrauen die Anmeldedaten ihrer Mitarbeiter einem Verzeichnisdienst an. Der dabei besonders beliebte OpenLDAP-Server und das von ihm genutzte Lightweight Directory Access Protocol gelten jedoch als kompliziert und sperrig. Mit unserer Schritt-für-Schritt-Anleitung gelingt der Einstieg dennoch.

Wie lautet doch gleich die E-Mail-Adresse von Frau Greiwes? Und welche Zugriffsrechte hat eigentlich Herr Fistelbück? Solche Fragen beantwortet schnell eine Adressenliste, die man in großen Unternehmen allerdings nicht als ausgedruckten Papierstapel herumreicht. Stattdessen sammelt dort ein Verzeichnisdienst auf einem zentralen Server die benötigten Informationen. Ein solcher Directory Service kann sich außerdem weitere Informationen merken, etwa die Konfiguration der gerade laufenden Server.

Ein Verzeichnisdienst stellt eine Datenbank bereit, die auf das schnelle Auslesen von Informationen getrimmt ist. Im Gegenzug erfolgt das Schreiben von Daten meist weniger effizient. In Unternehmen speichert ein Directory Service vor allem Benutzerdaten, auf die wiederum andere Dienste zur Authentifizierung und Autorisierung zurückgreifen. Das vereinfacht die Benutzerverwaltung drastisch, die an einer zentralen Stelle erfolgen kann.

Wie man bei einem Verzeichnisdienst anklopft, Informationen abfragt und Daten modifiziert, regelt gewöhnlich das Lightweight Directory Access Protocol (LDAP). Der Standard ist so erfolgreich, dass der Begriff LDAP-Server mittlerweile als Synonym für einen Verzeichnisdienst steht. Auf LDAP bauen viele weitere Dienste auf. Beispielsweise lässt sich zusammen mit Kerberos-Servern ein Single Sign-On (SSO) umsetzen. Das berühmt-berüchtigte Active Directory von Microsoft bedient sich übrigens ebenfalls bei LDAP und Kerberos.

Beliebte Referenz

Trotz des “Lightweight” im Namen gelten LDAP-Server als komplexe Zeitgenossen. Den Einstieg erschweren die eigene Terminologie und der extrem ausgeprägte AküFi, der Abkürzungsfimmel. Fast überall tauchen sie auf, ihre Bedeutung müssen Sie zumindest teilweise im Hinterkopf behalten. Das gilt schon bei der Einrichtung eines LDAP-Servers.

Einen solchen stellt unter anderem OpenLDAP [1] bereit. Das Softwarepaket enthält nicht nur eine Referenzimplementierung des LDAPs, sondern auch einen beliebten LDAP-Server mit dem lustigen Namen Slapd. Obendrauf liefert das OpenLDAP-Paket nützliche Hilfswerkzeuge sowie Konfigurationsdateien.

Sämtliche großen Distros offerieren OpenLDAP in ihren Repositories, wobei sich die Bestandteile auf mehrere Pakete verteilen. Unter Ubuntu finden Sie das Binary »slapd« im gleichnamigen Paket, andere Distributionen parken ihn gern in openldap. Einige Linux-Systeme installieren die Clientprogramme sogar standardmäßig. Wenn Sie noch nie mit OpenLDAP gearbeitet haben, sollten Sie sich allerdings nicht direkt auf die Suche nach den passenden Paketen machen, sondern bewusst einen kleinen Umweg gehen. Jede Distribution richtet OpenLDAP ein klein wenig anders ein. Wie genau, verrät im Idealfall die Dokumentation der Distro, im schlechtesten Fall müssen Sie die Konfigurationsdateien durchstöbern. Beides setzt grundlegendes Wissen um LDAP und OpenLDAP voraus.

Spielwiese

Für den Einstieg sollten Sie daher zunächst ein kleines Testsystem aufsetzen, etwa in einer virtuellen Maschine, und darin OpenLDAP aus seinem Quellcode installieren. Das hat den Vorteil, dass Sie auf die Beispielkonfiguration zurückgreifen und den LDAP-Server schrittweise einrichten können. Die Übersetzung des Quellcodes ist dank weniger Abhängigkeiten äußerst simpel. Haben Sie sich einmal mit LDAP und Slapd angefreundet, können Sie auf einem Produktivsystem zu den Paketen aus Ihrer Distribution greifen.

Falls Sie mit der schnellen Installation über einen Docker-Container liebäugeln: Bis zum Redaktionsschluss konnten wir weder einen offiziellen, noch einen empfehlenswerten aufspüren. Der häufig in Anleitungen eingespannte Container von Osixia [2] ist inzwischen veraltet. Der alternative OpenLDAP-Container [3] von Bitnami steht im Zuge einer Restrukturierung des Containerangebots eventuell vor dem Aus.

Sobald Ihr Testsystem steht, installieren Sie dort eine Entwicklungsumgebung mit GNU C-Compiler, Make, sowie den Entwicklungspaketen für Cyrus SASL (nicht zu verwechseln mit dem Cyrus Mail-System) und OpenSSL. Unter Ubuntu holt die erste Zeile aus Listing 1 alles Notwendige hinzu. Danach laden Sie das aktuelle OpenLDAP-Archiv [1] herunter, entpacken es und rufen im entstandenen Verzeichnis die übrigen Befehle aus Listing 1 auf. In den dabei erstellten Verzeichnissen landen gleich die Konfiguration (»/usr/local/etc/slapd.d/«), die eigentliche Datenbank (»/usr/local/var/openldap-data/«), die im Betrieb vom Server angelegte PID-Datei (»/usr/local/var/run/«) und sogenannte Module, die dieser Artikel jedoch ausklammert. Bevor Sie den LDAP-Server starten können, steht noch ein wenig Konfigurationsarbeit an.

$ sudo apt install build-essential libsasl2-dev
$ ./configure
$ make depend
$ make
$ sudo make install
$ sudo mkdir -p /usr/local/etc/slapd.d
$ sudo mkdir -p /usr/local/var/openldap-data
$ sudo mkdir -p /usr/local/var/run
$ sudo mkdir -p /usr/local/libexec/openldap

Dynamische Eigenleistung

Lange Zeit gelang die Einrichtung des LDAP-Servers über die Konfigurationsdatei »slapd.conf«. Nach jeder Änderung musste man den LDAP-Server einmal neu starten. Eine pfiffige Idee brachte die Lösung: LDAP-Server speichern neben den Benutzerdaten in vielen Unternehmen auch Rechnerkonfigurationen. Also kann sich Slapd zusätzlich seine eigene Konfiguration merken. Die Server-Konfiguration lässt sich dann wie alle anderen Daten mit den üblichen Clients ändern. Die modifizierten Einstellungen wendet Slapd zudem direkt im laufenden Betrieb an. Wegen der beiden Vorteile kommt mittlerweile nur noch die sogenannte dynamische Konfiguration zum Einsatz.

Nach der Installation ist die Datenbank allerdings noch leer. Um Slapd mit einer sinnvollen Grundkonfiguration zu füttern, sammeln Sie zunächst sämtliche Einstellungen in einer Datei. Die trichtern Sie dem LDAP-Server anschließend über einen passenden Client ein. Das funktioniert ähnlich wie bei SQL, bei dem man alle Anweisungen zum Aufbau einer Datenbank in einer ».sql«-Datei ablegt und sie dann dem SQL-Server übergibt. Um Slapd auf diesem Weg konfigurieren zu können, braucht es einen kurzen Blick auf seine Arbeitsweise.

Kleine Baumschule

LDAP-Server sind äußerst ordentliche Gesellen, die alle ihnen anvertrauten Daten in eine Gliederung pressen. Sie sollten sich daher vorab überlegen, welche Informationen Sie wie gegliedert im Verzeichnisdienst speichern möchten. Häufig bietet es sich an, die eigene Unternehmensstruktur abzubilden. Beispielsweise könnten Sie die Anmeldedaten der Mitarbeiter anhand der Filialen in München und Hamburg gruppieren. Aufgemalt entsteht eine Baumstruktur wie in Abbildung 1.

Abbildung 1: Die Zahnradfabrik hat zwei Filialen mit mehreren Mitarbeitern. Diese Unternehmensstruktur bietet sich direkt als Gliederung an.

Ein solcher Baum verschafft Ihnen mehrere Vorteile: Administratoren können unabhängig an unterschiedlichen Teilen arbeiten. Einzelne Zweige des Baumes lassen sich auf andere LDAP-Server auslagern (die Partitionierung vereinfacht sich) und die Suche über Filter gezielt auf einzelne Zweige beschränken. Der von einem LDAP-Server verwaltete Baum heißt Directory Information Tree (DIT) – womit Sie schon die erste Abkürzung kennen.

Wenn Sie die Anmeldedaten von Frau Greiwes im Verzeichnis speichern, erstellt der LDAP-Server für die Informationen im Baum an der passenden Position einen neuen Eintrag (Entry), den man auch als Objekt (Object) bezeichnet. Letzteres können Sie sich wie ein Paket vorstellen, in dem alle Informationen über Frau Greiwes enthalten sind. In Abbildung 2 dienen die Filialen lediglich als Gliederungshilfe. Solche Objekte bezeichnet man als Organizational Units (OU), denen Sie die Objekte mit den eigentlichen Daten unterordnen. Letztgenannte stehen damit meist am Ende der Hierarchie und somit an den Blättern des Baums. Ein LDAP-Server hält Sie jedoch nicht davon ab, eine andere Gliederung zu wählen, und etwa Herrn Fistelbück seiner Abteilungsleiterin Frau Greiwes unterzuordnen.

Namenstag

Um die ganzen Objekte und insbesondere Frau Greiwes einfacher wiederzufinden, bekommt jedes Objekt einen Namen. Im Beispiel könnte man das Objekt einfach mit dem Namen der Dame beschriften. Doch in Hamburg könnte ebenfalls eine Frau Greiwes arbeiten. Um im Baum dennoch die passende Person aufspüren zu können, haben sich die LDAP-Macher ein ausgeklügeltes Namensschema ausgedacht: Jedes Objekt erhält zunächst einen eignen Namen, den Relative Distinguished Name (RDN). Das Objekt mit den Anmeldedaten von Frau Greiwes könnten Sie »cn=Frau Greiwes« taufen. Das vor dem Gleichheitszeichen notierte Kürzel verrät, wovon sich der Objektname ableitet – dazu gleich mehr. Das »cn« steht hier für Common Name und somit einen frei wählbaren Namen.

Abbildung 2: Jedes Objekt in einem DIT besitzt einen eigenen Namen. Die Wurzel ganz oben darf sogar mehrere haben – in diesem Fall zwei.

Hängen Sie an diesen Namen alle RDNs der Vorgänger im Baum an, erhalten Sie den Distinguished Name (DN). Abbildung 2 zeigt dazu ein Beispiel: Dort gibt es links unten das Objekt »cn=Frau Greiwes«, das einer Organizational Unit namens »ou=munich« untergeordnet ist. Wie bei LDAP üblich, werden die Kürzel kleingeschrieben. Die beiden RDNs schreibt man hintereinander und trennt sie mit einem Komma: »cn=Frau Greiwes,ou=munich«.

Dann klettern Sie weiter im Baum nach oben und gelangen zu seinem Startpunkt, der Wurzel (Root). Auch er bekommt einen Namen beziehungsweise RDN, doch für ihn gilt eine Besonderheit: Niemand verbietet Ihnen, der Wurzel mehrere Namen zu verpassen. Das nutzt man in der Praxis gern aus: Als Startpunkt im Baum dient meist der Domainname des Unternehmens. Wie bei »zahnrad.com« besteht der aus mindestens zwei Komponenten. Genau denen stellt man jeweils ein »dc=« für Domain Component voran und verwendet sie mit einem Komma getrennt als Doppelnamen. Im Beispiel von »zahnrad.com« ergibt sich als kompletter Name der Wurzel »dc=zahnrad,dc=com«. Mit anderen Worten muss es also nicht zwingend ein Objekt »dc=zahnrad« und ein weiteres Objekt namens »dc=com« geben.

Zurück zu Frau Greiwes: Um den kompletten DN für ihre Anmeldedaten zu erhalten, hängen Sie den Namen der Wurzel an, wieder durch ein Komma getrennt. Damit haben Sie nicht nur einen eindeutigen Namen, sondern können auch leicht nachvollziehen, wo in der Hierarchie das Objekt mit den Anmeldedaten von Frau Greiwes untergebracht ist. Der Name der Wurzel ist zwangsweise Bestandteil eines jeden DN. Man spricht deswegen auch von einem Base DN, Naming Context oder (am häufigsten) Suffix.

Wo ist was?

Mit diesem Wissen geht es jetzt an die Grundkonfiguration von Slapd. Öffnen Sie mit Root-Rechten (etwa via »sudo nano«) die Datei »slapd.ldif« im Ordner »/usr/local/etc/openldap/«. Achten Sie dabei auf die Endung. Die Datei enthält eine Beispielkonfiguration, die Sie weitgehend übernehmen können – mit vier Ausnahmen. Ergänzen Sie unter der ersten Zeile von Listing 2 die beiden folgenden Zeilen.

include: file:///usr/local/etc/openldap/schema/core.ldif
include: file:///usr/local/etc/openldap/schema/cosine.ldif
include: file:///usr/local/etc/openldap/schema/nis.ldif

Im Hintergrund verstaut Slapd alle ihm anvertrauten Informationen in einer Datenbank, dem Backend. Standardmäßig kommt die Memory Mapped Database (MDB) zum Einsatz. Die Einstellungen rund um die Datenbank finden Sie am Ende der »slapd.ldif«. Slapd kann prinzipiell mehrere Datenbanken gleichzeitig verwalten. Wenn Sie den LDAP-Server um die Anmeldedaten von Frau Greiwes bitten, in welcher Datenbank muss Slapd dann suchen? Einen Hinweis darauf gibt die Einstellung »olcSuffix:«. Dahinter legen Sie das Suffix des in der Datenbank gespeicherten Baumes ab.

Tragen Sie hier beispielsweise »dc=zahnrad,dc=com« ein, würde Slapd das Objekt aus Listing 3 in der für »dc=zahnrad,dc=com« zuständigen Datenbank suchen. Ändern Sie daher die Zeile für das Beispiel auf »olcSuffix: dc=zahnrad,dc=com«. Wenn Sie Slapd aus den Ubuntu-Repositories installieren, leitet der Paketmanager dieses Suffix automatisch aus dem aktuellen Rechnernamen ab. Andere Distros geben nach einem ähnlichen Prinzip bereits ein Suffix vor.

cn=Frau Greiwes,ou=munich,dc=zahnrad,dc=com

Allmächtiger!

Slapd kennt einen allmächtigen Benutzer, der den Baum nach Belieben verändern und auslesen darf. Er muss sich mit dem Passwort ausweisen, das hinter »olcRootPW:« steht. Das Beispiel verwendet ein Passwort im Klartext, was nicht besonders sicher ist. Geben Sie hier besser einen Hash an, den das Werkzeug »slappasswd« erzeugt. Wenn es sich nicht direkt aufrufen lässt, finden Sie es im Verzeichnis »/usr/local/sbin«. Nach seinem Start denken Sie sich ein Passwort aus und hinterlegen dann die komplette erzeugte Zeichenkette hinter »olcRootPW:«.

Der allmächtige Benutzer besitzt neben dem Passwort einen eigenen hinter »olcRootDN:« eingetragenen DN. Für ihn muss es weder ein richtiges Benutzerkonto, noch einen Eintrag im Baum geben. Abgesehen vom Suffix bleibt es Ihnen überlassen, wie Sie den DN bezeichnen. Für das Beispiel können Sie den »Manager« übernehmen (Listing 4). Damit darf sich jetzt ein Benutzer mit dem Namen »cn=Manager,dc=zahnrad,dc=com« und dem Passwort bei Slapd anmelden und den kompletten Baum mit dem Suffix »dc=zahnrad,dc=com« nach Belieben verändern.

olcRootDN: cn=Manager,dc=zahnrad,dc=com

Rein damit

Nachdem Sie alle Änderungen an der Datei vorgenommen haben, müssen Sie die Konfiguration in den LDAP-Server bekommen. Das erledigt Slapadd wie in der ersten Zeile von Listing 5 gezeigt.

$ sudo /usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l /usr/local/etc/openldap/slapd.ldif
$ sudo /usr/local/libexec/slapd -F /usr/local/etc/slapd.d

Im Erfolgsfall sollte nur Closing DB… erscheinen. Trifft das nicht zu, gibt es entweder einen Tippfehler oder eines der in der »slapd.ldif« angegebenen Verzeichnisse existiert nicht. Nachdem Sie das Problem korrigiert haben, löschen Sie den kompletten Inhalt des Verzeichnisses »/usr/local/etc/slapd.d/« und rufen Slapadd noch einmal auf.

Im Hintergrund entsteht ein neuer DIT: Slapd sammelt alle Konfigurationseinstellungen in einem eigenen Baum, dessen Wurzel »cn=config« heißt. Diesem Baum fügt Slapadd sämtliche Einträge hinzu, die die Datei »slapd.ldif« vorgibt. Der Parameter »-n 0« wählt die erste von Slapd verwaltete Datenbank aus (die Zählung beginnt bei 0). Hinter »-F« steht der Ordner, in dem die Einträge landen.

Auf genau diesen Ordner können Sie jetzt Slapd ansetzen und somit endlich mithilfe des Kommandos aus der zweiten Zeile von Listing 3 starten. Der Einfachheit halber läuft der LDAP-Server hier mit Root-Rechten. Die Distributionen starten ihn hingegen unter einem eigenen Nutzer, der häufig »ldap« heißt. In jedem Fall lauscht der LDAP-Server an Port 389.

Fazit

Sobald Sie sich in die Nomenklatur des LDAP-Universums eingearbeitet haben, ist das Aufsetzen eines Servers kein Hexenwerk mehr. Sobald er läuft, müssen Sie den Baum für die Anmeldedaten der Mitarbeiter aufbauen. Wie genau sich das gestaltet, zeigen wir ihn im zweiten Teil dieses Artikels. (csi)