OpenLDAP - Alles in sync?

In großen und kleinen Netzen steht der Administrator häufig vor der Frage, welche Art der Benutzerauthentifizierung, Authorisierung und Namensauflösung wohl die flexibelste und zukünftig sicherste ist. Häufig wird hier als Lösung LDAP gewählt, da diese Lösung herstellerunabhängig und flexibel ist. Leider stellt sich gerade in Netzwerken mit mehreren LDAP-Servern immer wieder die Frage, ob man das nicht auch hätte besser lösen können. In OpenLDAP 2.3 haben einige interessante Funktionen Einzug gehalten, die in diversen Bereichen Verbesserung versprechen.

Der Master und seine Kumpels

In großen, wie auch kleinen Netzwerken lohnt es sich immer, mindestens 2 LDAP-Server zu konfigurieren. Dies hat Vorteile, falls mal einer der Server ausfällt. Außerdem kann man die Last der Anfragen so auf mehrere Server verteilen. Im Prinzip kann man beliebig viele LDAP-Server konfigurieren, wobei einer davon immer der Master ist, alle anderen sind Slaves.

Der Master ist der einzige, der eine beschreibbare LDAP-Datenbank besitzt. Alle anderen bekommen nur eine ReadOnly-Kopie der Daten repliziert. Hier sieht man die Sonderrolle des Masters: Der Master ist für alle Schreibarbeiten, z. B. Passwortänderungen, zuständig, welche er dann auf alle LDAP-Slaves replizieren muss.

MASTER:


replogfile /var/lib/ldap/replica.log
replica uri=ldap://ldapslave1.ordix.de:389/
bindmethod=simple
binddn="cn=ldapadmin,dc=ordix,dc=de"
credentials="geheim"


SLAVE:
updatedn "cn=ldapadmin,dc=ordix,dc=de"
updateref "ldap://ldapmaster.ordix.de:389/"

MASTER:


overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 1000


SLAVE:
   syncrepl rid=2
   provider=ldap://ldapmaster.ordix.de:389
   type=refreshOnly
   interval=00:00:00:10
   searchbase="dc=ordix,dc=de"
   filter="(objectClass=*)"
   scope=sub
   attrs="uid,cn,sn,description,mail"
   schemachecking=off
   updatedn="cn=ldapadmin,dc=ordix,dc=de"
   bindmethod=simple
   binddn="cn=ldapadmin,dc=ordix,dc=de"
   credentials="geheim"

Interessant ist, dass immer der Master für die Replikation zuständig ist. Das heißt, wenn ein Slave gerade Offline ist, muss irgendwann die Replikation nachgeholt werden. Und hier kommt es hin und wieder zu unterlassenen Replikationen.

Auch das Konfigurieren eines LDAP-Slaves ist etwas umständlich: Hierzu muss der Master gestoppt, die komplette LDAP-Datenbank exportiert, zum Slave transferiert und auf diesem importiert werden. Erst ab jetzt werden Änderungen vom Master auf den Slave repliziert. Eine Vereinfachung wäre hier hilfreich. Abbildung 1 zeigt einen Auszug, wie Master und Slave bisher konfiguriert wurden.

Verbesserung ist im Anmarsch

Wie aus der Abbildung ersichtlich wird, ist der Master für den Replikationsvorgang zuständig. Je mehr Slaves vorhanden sind, umso mehr muss der Master seine Slaves mit den korrekten Replikationen "bei Laune" halten. Bei den meisten anderen Master-Slave-basierten Diensten kümmern sich die Slaves selbst um ihre Daten.

Genau hier haben die OpenLDAP-Entwickler die Ohren gespitzt und der Version 2.3 den neuen Mechanismus syncrepl spendiert, bei dem die Slaves sich selbstständig um die Replikation der Änderungen kümmern. Auch das Installieren und Konfigurieren eines Slave-Servers ist nun wesentlich einfacher und komfortabler geworden. Will man einen neuen Slave-Server installieren, muss nur die Konfigurationsdatei konfiguriert und der Dienst gestartet werden.

Beim allerersten Start stellt der Slave fest, dass er überhaupt keine Daten hat und repliziert alle Daten. Ab dann fragt er regelmäßig beim Master nach, um sich die geänderten Informationen zu holen. In Abbildung 2 ist ein Auszug der Konfiguration mit syncrepl.

Klingt ja kompliziert

Wie Abbildung 2 zeigt, ist beim neuen Verfahren syncrepl einiges mehr an Konfiguration notwendig.

• Mit overlay syncprov wird der Master für das syncrepl-Verfahren konfiguriert. Overlays sind eine neue Funktion in OpenLDAP 2.3, auf die später detaillierter eingegangen wird.
• Mit syncprov-checkpoint wird festgelegt, nach wie vielen Einträgen bzw. nach wie vielen Minuten der contextCSN (Change Sequence Number) überprüft werden soll. Es wird repliziert, sobald eine der beiden Optionen eintritt.
• Der syncprov-sessionlog Eintrag ist eine Historie über Änderungen seit dem letzten Repliziervorgang. Mit diesem Eintrag kann die Zeit zum Vergleichen der Einträge, die repliziert werden müssen, verkürzt werden.

Auf der Slave-Seite muss der Master mit provider=<master> angegeben werden. Type=refreshOnly besagt, dass die Anforderung der Daten vom Slave ausgeht. Alternativ könnte man natürlich auch, wie bisher, die Initiierung vom Master ausgehend konfigurieren.

Die Häufigkeit, wie oft der Master nach Änderungen befragt werden soll, wird mit intervall=[dd:hh:mm:ss] eingestellt.

• Mit searchbase stellt man den Teilbaum ein, der repliziert werden soll.
• Und nach welchen geänderten Attributen gesucht werden soll, legt attrs fest.
• Das Schema wird in unserem Beispiel nicht geprüft (schemachecking=off).
• Am Ende wird noch definiert, mit welchen Rechten der Zugriff stattfindet.

syncrepl versus slurpd

Wenn man in der Prozessliste des Betriebssystems sucht, wird man vergeblich einen Prozess namens syncrepl suchen. Während beim alten Verfahren auf dem Master noch ein separater Prozess namens slurpd für die Replikation zuständig war, handelt es sich bei syncrepl um einen Thread des slapd-Daemon.

Auch gibt es mit dem neuen Verfahren neue Möglichkeiten: Während mit dem slurpd der ganze LDAP-Baum repliziert wurde, kann mit dem syncrepl auch nur ein Teilast repliziert werden. Das ist aus sicherheitstechnischen Aspekten und in Netzwerken mit geringer Bandbreite von Interesse. So kann in einer Firma mit mehreren Standorten zu jedem Standort immer nur der für den Standort relevante Teil repliziert werden.

Auch in OpenLDAP 2.2 gab es den syncrepl Mechanismus schon, wobei vom Einsatz des Mechanismus in der alten Version in Produktivumgebungen eher abzuraten ist, da er in den Versionen vor 2.3 noch als sehr experimentell gilt.

Overlays: Es gibt da was zwischen uns

Wie in der Master-Konfiguration (siehe Abbildung 2) schon erwähnt, existiert in OpenLDAP Version 2.3. eine neue Funktion namens overlay. Ein Overlay ist im Prinzip eine virtuelle Schicht zwischen dem LDAP-Daemon und der Datenbank. Diese erlaubt es, Veränderungen der Daten vorzunehmen, ohne die Datenbank selbst zu verändern.

Die Richtung ist hier nicht vorgegeben. Die Veränderungen können sowohl bei lesendem als auch bei schreibendem Zugriff vorgenommen werden. Damit die Overlays überhaupt genutzt werden können, muss beim Kompilieren des Quellcodes der configure-Schalter -enable-overlays bzw. -enable-<overlay-name> genutzt werden. Dies ist bei aktuellen Suse und RedHat RPM standardmäßig der Fall.

Zu den meisten Overlays existieren Manual-Pages, die man auch benötigt, da das Internet noch keine ausreichenden Informationen darüber zur Verfügung stellt. Normalerweise kann man die Manual-Page mit dem Befehl man slapo-<overlay-name>, oder noch besser mit man -k slapo finden. In Abbildung 3 finden Sie eine kleine Auflistung einiger Overlays.

Mehr über Overlays

Die in Abbildung 3 dargestellten Overlays sind jedoch nur eine kleine Auswahl. Es gibt noch viele weitere Overlays - mittlerweile für fast alle Eventualitäten, die im Alltag des Netzwerkadministrators auftreten können.

Das Schöne daran ist: Sie sind meist mit wenig Aufwand vom Administrator schnell in die Konfigurationsdatei eingetragen. Das Unschöne ist, dass sie oft schlecht dokumentiert sind und im Internet nur wenig Informationen darüber existieren.

Übrigens sind die Overlays auch stapelbar, so dass bei der Konfiguration eines Datenbank-Backends auch mehrere Overlays angegeben werden können, die dann, ähnlich einer Pipe, als Filter arbeiten. Abbildung 4 zeigt ein Beispiel, wie einfach ein Overlay implementiert werden kann.

Das praktische Overlay slapo-accesslog bietet die Möglichkeit, Zugriffe aller Art (add, read, modify, delete) in einer separaten Datenbank zu protokollieren. Zum Beispiel können die mitprotokollierten Informationen ganz normal in einer Organisationseinheit im LDAP zwischen Benutzern und Gruppen abgelegt werden. Zugriffe auf diese Informationen sind dann mit den normalen Bordmitteln (ldapsearch, ldapdelete etc.) möglich.

Dr. Watson klärt Sie auf

suffix "dc=ordix,dc=de"


overlay accesslog
logdb dc=logs
logops writes reads
logpurge 2+10:00 00:30

In Abbildung 4 ist zu sehen, dass nur wenig Einträge, die sogar menschenlesbar sind, vorgenommen werden: Mit suffix wird definiert, ab welchem Punkt der LDAP-Struktur der Zugriff mit Hilfe des Overlays accesslog überwacht werden soll.

Die protokollierten Zugriffe werden dann unterhalb von dc=logs abgelegt. Protokolliert werden Lese- und Schreibzugriffe. Die Logs werden alle 30 Minuten gescannt. Logs, die älter als 2 Tage und 10 Stunden sind, werden gelöscht.

Fazit

OpenLDAP hat in der Version 2.3 einige Erweiterungen und Verbesserungen zu bieten, die gerade in großen Netzwerken das Arbeiten mit diesem heterogenen Netzwerkprotokoll vereinfachen. Das Arbeiten mit dem syncrepl-Mechanismus erleichtert zum einen das Aufsetzen eines Slave-Servers, zum anderen wird der Master entlastet.

Mit dem Mechanismus der Overlays, können viele neue Funktionen implementiert werden, ohne die komplette Datenbankstruktur zu verändern. OpenLDAP 2.3. bietet noch weitere nützliche Funktionen, wie zum Beispiel das Speichern der Konfiguration und der Zugriffsberechtigung innerhalb der LDAP-Datenbank.

So entfällt das Abgleichen der Konfigurationsdateien und das damit verbundene Neustarten der LDAP-Dienste. Darüber werden wir in einer der nächsten Ausgaben der ORDIX News berichten.

Christian Fertsch (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen