Konfiguration via OLC

OpenLDAP hat in der Version 2.4, die sich im CentOS-Repository befindet, auf das Modell der dynamischen Konfiguration umgestellt. In der Kurzform wird diese Art der Konfiguration als OLC (On-Line-Configuration) bezeichnet. In den verschiedenen Dokumentationen rund um den OpenLDAP-Server taucht auch immer wieder der Begriff der »cn=config« -Methodik auf, die das Gleiche bedeutet.

Beim »cn=config« -Modell liegen die Konfigurationsdaten im LDAP-Server und werden mit den LDAP-Client-Werkzeugen bearbeitet. Im alten Modell wurde der OpenLDAP-Server noch über eine zentrale Konfigurationsdatei gepflegt. Die Gründe für die Umstellung, die auf den ersten Blick erst einmal alles komplizierter macht, sind schnell ersichtlich. Alle Änderungen können im laufenden Betrieb vorgenommen werden, ohne dass ein Neustart des Servers erforderlich wird. Insbesondere bei größeren Installationen ist der Neustart eine relativ zeitaufwendige Sache, die mehrere Minuten dauern kann. Zudem verliert der LDAP-Server bei einem Neustart seinen Cache, der im Hauptspeicher liegt. Nachfolgende Anfragen dauern entsprechend länger und müssen erst wieder den Cache füllen.

Mit dem dynamischen Konfigurationsmodell entfallen Neustarts und die Verfügbarkeit des LDAP-Servers bleibt erhalten. Sobald man das Konzept hinter dem neuen Konfigurationsmodell verstanden hat, fühlt es sich auch deutlich schlüssiger an. Beim alten Modell liegen die Konfigurationsdateien in einem Verzeichnisbaum unterhalb von »/etc/openldap/slapd.d« , die Vorrang vor einer eventuell vorhandenen Konfigurationsdatei »/etc/openldap/slapd.conf« haben. Dieser Artikel konzentriert sich im Weiteren aber ausschließlich auf das neue Modell. Nach der Installation sind einige Schritte erforderlich, bevor der LDAP-Server-Daemon »slapd« starten kann. Zuerst müssen Sie sich für ein Daten-Backend entscheiden. OpenLDAP unterstützt eine Vielzahl an Backends, beginnend bei der Berkeley DB (BDB), die als Standard gesetzt ist, über MySQL, Memory-Datenbanken oder auch Perl-Datenstrukturen. In unserer Beispielkonfiguration verwendet der LDAP-Server die BDB.

Die nachfolgenden Schritte müssen Sie mit Root-Rechten durchführen. Statt direkt als Root-Benutzer zu arbeiten, werden im Folgenden alle Kommandos mit dem »sudo« -Befehl ausgeführt. Um eine initiale Datenbank anzulegen, liefert der OpenLDAP-Server ein Konfigurations-Template mit. Kopieren Sie es in das Datenverzeichnis des OpenLDAP-Servers:

$ sudo cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

Das Template enthält Angaben über Cache-Größe und Datenbank-Logfiles. Alle diese Werte können Sie jedoch dank des dynamischen Konfigurationsmodells später ändern. Nach dem Kopieren der Datei testen Sie den OpenLDAP-Server auf korrekte Konfiguration und starten ihn anschließend:

$ sudo slaptest -u
$ sudo chkconfig slapd on
$ service slapd start

Voilà, der OpenLDAP-Server ist bereit für die initiale Konfiguration. Aktuell kann sich, obwohl der Server läuft, noch niemand verbinden.

Authentifizieren

Zuerst erzeugen Sie das LDAP-RootDN-Passwort. Der RootDN stellt den obersten Knoten in einem LDAP-Verzeichnis dar und kann grundsätzlich alle Knotenpunkte unter ihm verändern. Es ist quasi der Root-User des LDAP-Systems. Das Passwort kann mit dem Kommando »slappasswd« generiert werden. Das nachfolgende Kommando setzt das Passwort auf »geheim« und gibt den SHA-Hash des Passworts auf der Kommandozeile aus:

$ sudo slappasswd -s geheim
{SSHA}GT+mLzLeRPGE7176X1Btmt9AzSolCTRa

Die komplette Zeile kopieren Sie sich sinnvollerweise in ein temporäres Editor-Fenster, sie wird später für die Konfigurationsdatei benötigt.

Zum jetzigen Zeitpunkt ist der Slapd-Daemon noch sehr rudimentär konfiguriert und kann noch keine sinnvollen Aufgaben erfüllen. Trotzdem ist es informativ, den Directory Information Tree (DIT) in der aktuellen Form anzuschauen. Wenn der LDAP-Server läuft, formulieren Sie mit dem Kommando »ldapsearch« eine Suchabfrage und schicken sie zum Server:

$ sudo ldapsearch -b cn=config -Y EXTERNAL -H ldapi:// '(objectClass=olcDatabaseConfig)' olcDatabase

Das Kommando »ldapsearch« wird hierbei angewiesen, sich über einen Socket ( »ldapi« ) zum LDAP-Server zu verbinden und eine Suchabfrage zu starten. Der erste Teil der Server-Antwort sieht so aus:

SASL/EXTERNAL authentication started
SASL username:
gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

Die Methode der Authentifizierung wird durch die Option »-Y EXTERNAL« angegeben. Sie weist den LDAP-Server an, die Authentifizierung nicht gegen die Daten im LDAP-Server durchzuführen, sondern auf Basis der User-ID oder anderer Kriterien zu entscheiden. Für diese Form der Authentifizierung ist im OpenLDAP bereits ein Standard vorkonfiguriert, der hier genutzt wird. Der User mit der UserID 0 und der GruppenID 0 darf sich anmelden, also der User »root« . Deshalb muss diesem Kommando ein »sudo« vorangestellt werden. Zum aktuellen Zeitpunkt ist dies der einzige Weg, sich am LDAP-Server anzumelden.

Die weiteren Zeilen der Ausgabe geben Aufschluss über die Suche und die Form der Ausgabe:

# extended LDIF
# LDAPv3
# base <cn=config> with scope subtree
# filter: (objectClass=olcDatabaseConfig)
# requesting: olcDatabase

Das Format »extended LDIF« ist der Standard in der LDAP-Protokollversion 3. Die Zeile »base« gibt an, von wo die Suche gestartet wurde. In diesem Falle wurde der Knotenpunkt mit dem Common Name ( »cn« ) »config« durchsucht. Der Scope, also der Suchbereich, gibt dabei Aufschluss über die Suchtiefe. Bei der Bezeichnung »subtree« wird alles unterhalb der Base durchsucht. Der Suchfilter wurde auf eine »objectClass« gesetzt, in diesem Fall »olcDatabaseConfig« . Eine Objektklasse stellt in LDAP eine Form von Datencontainer dar, die mit Attributen gefüllt ist.

Des Weiteren sind in der Ausgabe die beiden interessantesten Datenbanken zu sehen:

# {0}config, config
dn: olcDatabase={0}config,cn=config
olcDatabase: {0}config
# {2}bdb, config
dn: olcDatabase={2}bdb,cn=config
olcDatabase: {2}bdb

Als erstes Element ist die Konfigurationsdatenbank vorhanden und dann die Datenbank ( »{2}bdb« ), die später die Nutzerdaten aufnehmen wird. Abgeschlossen wird die Antwort auf die Anfrage durch eine kleine Statistik über Suche und Treffer:

# search result
search: 2
result: 0 Success
# numResponses: 5
# numEntries: 4