Der baumartig organisierte Verzeichnisdienst OpenLDAP bildet das Rückgrat vieler Infrastrukturen. Wirft eine plötzliche Böe den LDAP-Server um, kann nur eine verteilte Struktur mit Slave-Servern die Katastrophe verhindern. Eine Anleitung.

Die Praxis zeigt: Es ist nichts Schlechtes daran, dass Verzeichnisdienste wie LDAP fast so alt wie manche Baumriesen sind, genauer: auf den X.500-Standard der ITU-T (International Telecommunication Union) zurückgehen. Denn LDAP profitiert vom hohen Reifegrad des Konzepts und der Implementierungen, was bei Infrastruktur-Software wichtiger ist als hippe Features. Selbst Microsofts vergleichsweise junges Active Directory fußt auf LDAP.

Dieser Workshop vermittelt keine Grundlagen wie [1] und [2], sondern will zeigen, was Sie tun können, um einen Single Point of Failure bei LDAP zu vermeiden und Performance-Engpässe auf dem zentralen LDAP-Server zu bekämpfen. Er zeigt, wie Sie Redundanzen schaffen oder Außenstellen der Firma mit einem LDAP-Spiegel versorgen. Das geht naturgemäß mit den Themen Replikation und Synchronisation Hand in Hand und passt bestens zum Titelthema dieser Ausgabe.

Zum Szenario: Wer die IT einer Außenstelle mit Anmeldediensten zu versorgen hat, kämpft damit, dass der zentrale Anmeldedienst kilometerweit entfernt in der Firmenzentrale steht. Dabei laufen sämtliche Daten über eine WAN-Leitung mit ihren hohen Latenzzeiten. Wenn sich morgens dann der ganze Mitarbeiterstamm innerhalb weniger Minuten anmeldet – dann guten Morgen. Sind die IT-Verantwortlichen vor Ort keine Experten, rufen sie in der Situation gern einen Berater in Haus, der es richten soll – mit diesem Workshop vertraut, könnten das Sie sein.

LDAP als lokaler Service mit Verzweigungen

Sofern der Anmeldedienst aus Open-Source-Komponenten, also auch aus OpenLDAP besteht, ist das gar kein gravierendes Problem, sondern eher eine Fleißaufgabe. Die Lösung heißt Slurpd (Stand-alone LDAP Update Replication Daemon) und ist der weitere Dienst, den Sie zusätzlich zum LDAP-Serverdienst Slapd auf dem Masterserver betreiben werden. Er spielt die zentralen Rolle, wenn es um die Replikation von Daten im Verzeichnisbaum geht.

In einer Grund- und Basiskonfiguration behandelt Slapd, der Stand-alone LDAP-Daemon, alle Anfragen beziehungsweise Queries einer Domäne. Den darunter liegenden Baum behandelt ein zentraler Server, es findet keinerlei Interaktion zu anderen Verzeichnisdiensten statt. Diese Konfiguration ist nur in kleinen Umgebungen sinnvoll. Kommt nun eine weitere Umgebung hinzu, brauchen Sie nicht unbedingt die Replikation als Verbindungsglied. X.500 sieht die Verzweigung und Verbindung von weiteren Verzeichnissen mittels Referrals vor.

Vereinfacht gesagt, darf man sich dieses wie einen Uniform Resource Locator (URL) vorstellen. Wenn der Baum am Ende seines Lateins angelangt ist und der Benutzer etwas in einem Zweig sucht, was irgendwo anders auf der Welt liegt, teilt der Verzeichnisdienst einen Link mit. Der Client löst nun automatisch den Verweis auf und fordert die gesuchten Informationen an, schematisch zu sehen in Abbildung 1. Die Technik eines Referral dient zwar im Single-Master-Modus zur Verzweigung auf andere Verzeichnisdienste, stellt aber auch ein wesentliches Element im verteilten Szenario mit redundanten Servern dar.

Abbildung 1: Wenn ein LDAP-Baum die angeforderte Information nicht vorrätig hat, teilt der Verzeichnisdienst einen Referral-Link mit. Der Client fordert damit die gesuchten Informationen von anderer Stelle ein.

Ein großer Dienst am Objekt

In größeren Organisationen erlauben die IT-Budgets meist einen zentralen Anmeldeserver. So auch im folgenden Beispiel: Sie sind also ein optimistischer Jung-Consultant und erhalten den Auftrag, einen Verzeichnisdienst für das Unternehmen Hxchaos aufzubauen. Und damit es nicht im selbst verursachten Chaos versinkt, arbeiten Sie in das Design bereits eine verteilte Umgebung ein. Das Ziel der ganzen Mühe ist es, das verzweigte Unternehmen mit zwei Außenstellen zu versorgen.

Aus Erfahrung wissen Sie bereits, dass das Design der Verzeichnisstruktur elementar ist. Nach endlosen Diskussionen mit Managern über die Namensgebung darf es losgehen: Sie strecken den Baum »dc=hxchaos,dc=local« von einem Master- auf zwei Slave-Server. Den daraus resultierenden Netzwerkaufbau zeigt Abbildung 2.

Abbildung 2: Das vorgestellte LDAP-Setup mit drei Servern, einem Master und zwei Slaves. Die Lastverteilung und die Failover-Funktion ist recht einfach über einen gemeinsamen DNS-Eintrag realisierbar.

Nachdem Sie Ihr Netzwerkdiagramm fertiggestellt haben, installieren Sie auf dem Master »idefix.hxchaos.local« den Slapd-Dienst und konfigurieren ihn wie in einem lokalen Szenario. Hier ist nicht viel zu tun. Sie legen den Distinguished Name des Admin fest, vergeben ein Kennwort und bauen Basisobjekte für den Verzeichnisdienst auf. Den Slapd als Binärpaket zu installieren oder aus den Sourcen zu kompilieren gelingt normalerweise auf Anhieb und soll darum hier keinen Platz verschwenden.

Wichtig sind allerdings die Parameter, die Sie in der Default-»slapd.conf« anzupassen haben, das Basis-Suffix des Verzeichnisdienstes und den Root-DN des Verzeichnisdienstes beziehungsweise den administrativen Account für OpenLDAP:

suffix       "dc=hxchaos,dc=local"
rootdn       "cn=admin,dc=hxchaos,dc=local"

Abschließend vergeben Sie noch ein Kennwort für den Root-DN.

Salted SHA1

Dazu bemühen Sie das Kommando »slappasswd«, das einen SHA1-Hashwert erzeugt, genauer gesagt, einen SSHA1-Hash (Salted SHA1). Ein Salt erschwert das Knacken von Passwörtern erheblich. Um den Hash zu erzeugen, tippen Sie das Kommando ohne Parameter:

idefix:/etc/ldap# slappasswd
New password:
Re-enter new password:
{SSHA}1kJlmFFsBk+wkfpY/CXKvlTOAihHkt66

Im Beispiel hat der User das schwache Kennwort »volker« eingetippt. Den erzeugten Hash fügen Sie in die »slapd.conf« unter der Direktive »rootdn« ein:

rootdn     "cn=admin,dc=hxchaos,dc=local"
rootpwd {SSHA}1kJlmFFsBk+wkfpY/CXKvlTOAihHkt66

Jetzt dürfen Sie »slapd« starten und den Verzeichnisdienst mit Grunddaten füttern. Das erledigen Sie am schnellsten mit der kleinen LDIF-Datei, die in Listing 1 zu sehen ist.

01 dn: dc=hxchaos,dc=local
02 objectClass: top
03 objectClass: dcObject
04 objectClass: organization
05 o: hxchaos.local
06 dc: hxchaos
07 structuralObjectClass: organization
08 businessCategory: IT Company
09 description: LDAP Verzeichnis der HXCHAOS Inc.
10 
11 dn: cn=admin,dc=hxchaos,dc=local
12 objectClass: simpleSecurityObject
13 objectClass: organizationalRole
14 cn: admin
15 description: LDAP administrator
16 
17 dn: cn=sync,dc=hxchaos,dc=local
18 cn: sync
19 objectClass: simpleSecurityObject
20 objectClass: organizationalRole
21 objectClass: top
22 structuralObjectClass: organizationalRole
23 description: Synchronisationsbenutzer
24 userPassword:: e1NTSEF9MlpUaVY0Y3FHcGp5bnhWbVdneXVCUTM0UFlLN1B1OWJOOHNpSVE9PQ=
25 =

Ein extra Benutzer zum LDAP-Syncen

Sie als aufstrebender Consultant sind natürlich richtig auf Zack: Für den Datenaustausch zwischen den Master- und Slave-Servern legen Sie einen eigenen Synchronisationsbenutzer an, hier den Distinguished Name »cn=sync,dc=hxchaos,dc=local« mit dem Kennwort »volker«. Anschließend passen Sie die ACLs (OpenLDAP Standard Access Control Lists) in der »slapd.conf« entsprechend dem folgenden Muster an:

access to *
  by dn="cn=admin,dc=hxchaos,dc=local" write
  by dn="cn=sync,dc=hxchaos,dc=local" write
  by * read

Der Root-DN hat vollen Schreibzugriff, jeder andere – auch anonyme – User darf lesend zugreifen. Der Sync-DN erhält ebenfalls vollen Schreibzugriff. Das Ändern der »slapd.conf« bedingt selbstverständlich den Neustart des Dienstes.

Redundanzen erstellen und absichern

Wenn Slapd läuft, beginnt das eigentliche Vergnügen: Sie richten den Datenstrom zwischen dem Master und dem ersten Slave ein. Zuerst installieren Sie die beiden Slave-Server »flexus.hxchaos.local« und »foxtrott.hxchaos.local« und versehen sie ebenfalls mit dem OpenLDAP-Paket. Nun müssen Sie die LDAP-Datenbank des Masters auf die beiden Slave-Server kopieren. Die Datenbankdateien der hier eingesetzten Berkeley Datenbank (Backend BDB) finden sich unter »/var/lib/ldap«.

Zunächst stoppen Sie alle beteiligten Serverdienste. Mittels »scp« können Sie nun die Dateien problemlos auf die beiden Slave-Server verteilen. Zudem kopieren Sie die Basis-»slapd.conf« von »idefix.hxchaos.local« gleichfalls auf »flexus« und »foxtrott«. Das erspart, Konfigurationsänderungen doppelt vorzunehmen. Dann passen Sie die »slapd.conf« des Master-Servers »idefix.hxchaos.local« an. Sie tragen den ersten Slave-Server als Replik ein:

replica uri=ldap://flexus.hxchaos.local:389
        binddn="cn=sync,dc=hxchaos,dc=local"
        bindmethod=simple credentials=volker

Dabei kommt der vorhin geborene Synchronisationsbenutzer zu Ehren – mit dem Kennwort »volker«. Die Server werden sich über die so genannte Simple-Bind-Methode miteinander verbinden. Auf dem ersten Slave-Server »flexus.hxchaos.local« editieren Sie die »slapd.conf« so, dass er den Master kennt:

referral  "ldap://idefix.hxchaos.local:389"
updatedn  "cn=sync,dc=hxchaos,dc=local"
updateref "ldap://idefix.hxchaos.local:389"

Auf dem ersten Slave-Server starten Sie jetzt den »slapd«-Dienst. Analog setzen Sie auf »idefix.hxchaos.local« den Slurp-Daemon im Foreground-Modus mittels »slurpd -d 16384« in Gang.

Benutzer auf dem Master anlegen

Sie schenken an dieser Stelle nochmals dem Master Ihre Aufmerksamkeit und legen dort einen Benutzer an. Das geht mit der LDIF-Datei aus Listing 2 am besten. Das eigentliche Importieren erledigt eine längliche Zeile:

idefix:/etc/ldap# ldapadd -D "cn=admin,dc=hxchaos,dc=local" -x -h idefix.hxchaos.local -f myldap.ldif -W
Enter LDAP Password:
adding new entry "cn=Test Tester,dc=hxchaos,dc=local"

01 dn: cn=Test Tester,dc=hxchaos,dc=local
02 cn: Test Tester
03 objectClass: organizationalPerson
04 objectClass: person
05 objectClass: top
06 sn: Tester

Auf der Konsole sehen Sie im Erfolgsfall eine Meldung nach dem Import. In Listing 3 ist dies für ein Debian-System zu sehen. Um die Funktionsfähigkeit der Replizierung auf andere Weise zu belegen, suchen Sie den LDAP-Eintrag auf dem Slave direkt:

ldapsearch -x -h flexus.hxchaos.local -b "dc=hxchaos,dc=local" cn=Test*

01 @(#) $OpenLDAP: slurpd2.3.30 (Mar  9 2007 05:44:57) $
02         root@windlord:/tmp/buildd/openldap2.3-2.3.30/debian/build/servers/slurpd
03 
04 request done: ld 0x8070778 msgid 1
05 request done: ld 0x8070430 msgid 1
06 request done: ld 0x8070430 msgid 2
07 request done: ld 0x8070778 msgid 2

Die Ausgabe sieht dann wie in Listing 4 aus. Wollen Sie es noch genauer wissen, sichten Sie das Replikations-Logfile, das unter »/var/lib/ldap« beziehungsweise im Datenbankpfad zu finden ist. Die Direktive Replogfile veranlasst das Mitschreiben der Replikations-Logdatei:

replogfile /var/lib/ldap/replog

01 # extended LDIF
02 #
03 # LDAPv3
04 # base <dc=hxchaos,dc=local> with scope subtree
05 # filter: cn=Test*
06 # requesting: ALL
07 #
08 # Test Tester, hxchaos.local
09 dn: cn=Test Tester,dc=hxchaos,dc=local
10 cn: Test Tester
11 objectClass: organizationalPerson
12 objectClass: person
13 objectClass: top
14 sn: Tester
15 
16 # search result
17 search: 2
18 result: 0 Success
19 
20 # numResponses: 2
21 # numEntries: 1

Nun stoppen Sie auf beiden Servern die LDAP-Dienste und wiederholen auf dem zweiten Slave-Server »foxtrott.hxchaos.local« diese Schritte. Falls Sie nicht – wie oben empfohlen – schon die Datenbank vom Master und die Konfigurationsdatei auch auf den zweiten Slave kopiert haben, holen Sie das jetzt nach.

Foxtrott wie Flexus

Für den »slurpd« tragen Sie als Nächstes auf »idefix.hxchaos.local« eine zusätzliche Replik in der »slapd.conf« ein:

replica uri=ldaps://foxtrott.hxchaos.local:636
       binddn="cn=sync,dc=hxchaos,dc=local"
       bindmethod=simple credentials=volker

In der »slapd.conf« auf »foxtrott.hxchaos.local« nehmen Sie die gleichen Einträge wie für »flexus.hxchaos.local« vor. Im Kern sind Sie jetzt schon fertig, denn die LDAP-Umgebung mit drei Servern funktioniert – Grund für zufriedenes Consultanten-Strahlen.

Ausfall programmiert

Das bietet Ihnen Gelegenheit, sich dem Thema Ausfallsicherheit zu widmen. Unter diesem Aspekt ergeben sich bei der Beispielumgebung folgende Fragen:

• Wie lässt sich die Last auf die drei Server
  verteilen?
• Wie reagiert sie, wenn der Master-Server ausfällt?

Auf die erste Frage gibt es mehrere Antworten. Das einfachste Szenario zieht den Domain Name Service heran, Sie adressieren also alle drei Server unter einem DNS-Namen. Dazu definieren Sie auf dem DNS-Server etwa den Eintrag »ldapdns.hxchaos.local«, der auf die drei IPs der LDAP-Server verweist.

Das Ganze ist leicht eingerichtet und Probleme in interaktiven Sitzungen und bei gesicherten Verbindungen ergeben sich nicht, denn die Clients stellen ihre DNS-Anfragen nur beim ersten Verbindungsaufbau. Bei späteren Anfragen suchen die Clients den Server immer unter der anfangs aufgelösten IP-Adresse.

Echte Hochverfügbarkeit ist das freilich nicht. Denn wenn der Master ausfällt, beantwortet das Szenario Anfragen weiterhin nur dann, wenn der DNS-Service den Ausfall bemerkt hat – händisch oder über eine Monitoring-Komponente. Ein ähnliches Problem ergibt sich mit zwischenzeitlichen LDAP-Änderungen. Sie wären bis zur Wiederinbetriebnahme des ausgefallenen Masters verloren. Die Lösung ist einfach: Die Master- und Slave-Einteilung ist nicht in Stein gemeißelt. Fällt der Master-Server aus, erklären Sie einen der Slave-Server zum neuen Master. Das erfordert zwar kleine Konfigurationsänderungen, die aber in wenigen Minuten erledigt sind.

Alternativ können Sie auch IPtables zur Lastverteilung nutzen oder eine kommerzielle Lösung. Hierfür gibt es x-beliebige Spielarten, über die sich mehrere Bücher füllen ließen.

Pflege mit jeder Plattform

Wenn Ihr Verzeichnisdienst im vollen Glanz erscheint, fehlt dem lokalen Administrator noch ein Toolkit, um den replizierten LDAP-Baum vernünftig zu pflegen. Hierfür empfiehlt sich der Jxplorer [1], der als in Java verfasster LDAP-Client auch auf Mac OS und Windows läuft (Abbildung 3). Jxplorer kommt hervorragend mit Referrals klar, was bedeutet, dass der lokale Administrator der Hxchaos-Domäne bei jeder Änderung – gleich welchen LDAP-Server er dabei adressiert – immer an den Master-Server »idefix.hxchaos.local« verwiesen wird. Das verhindert Inkonsistenzen jeder Art, denn die Modifikationen erfolgen auf dem Master-Server.

Abbildung 3: Der plattformunabhängige LDAP-Client Jxplorer beim Browsen der aufgebauten LDAP-Domain.

Darum muss sich auch der LDAP-Client auf Referrals verstehen, andernfalls würde der Master von Änderungen nichts mitbekommen. Damit der Jxplorer mit Referrals arbeitet, müssen Sie nach der Installation die »jxplorer.txt« in einen Editor laden und den Eintrag »option.ldap.referral=« von »ignore« auf »follow« abändern. Abbildung 4 zeigt, was netzwerkseitig passiert, wenn der Admin per Jxplorer versucht, eine LDAP-Änderung auf einem Slave durchzuführen. Jxplorer erhält einen Referral und wendet sich an den Master-Server.

Abbildung 4: Hier analysiert Wireshark den Traffic, wenn Jxplorer auf einem Slave eine Änderung durchzuführen versucht. Per Referral landet die Anfrage auf dem Master-Server.

Sicherheit ist keine Lappalie

Ohne Risikobetrachtung bliebe der Artikel unvollständig. LDAP-Informationen gehen – wie oft per Default – unverschlüsselt übers Netzwerk. Da LDAP-Einträge sensiblen Charakters sind, liegt die Notwendigkeit der Absicherung nahe. Beobachten Sie, was repliziert wird und was zwischen den Diensten passiert. Dazu und auch zum Monitoring etwaiger Angriffe auf das geschaffene Setup loggen Sie per Syslog, am besten über einen zentralen Syslog im Netzwerk. Sie müssen das Logging für jeden Serverdienst dediziert einschalten.

Das Risiko des Mitlesens von Informationen zwischen den Systemen lässt sich zum Beispiel mit IPsec minimieren. Sind auch Firewalls im Spiel, ist die Kombination mit NAT bekanntlich problematisch. Der Ausweg führt im Schichtenmodell ein Protokoll tiefer zum Secure Socket Layer. SSL wiederum benötigt Zertifikate. Die können Sie entweder kostenpflichtig erwerben oder in Eigenregie erzeugen. Für Letzteres richten Sie eine Certificate Authority (CA, [4]) ein. Der Aufwand hierfür fällt geringer aus als erwartet, da SSL ein geeignetes CA-Skript, »CA.pl« oder »CA.sh«, mitliefert.

Bevor Sie loslegen, sollten Sie die Konfigurationsdatei von OpenSSL unter die Lupe nehmen. Sinnvoll ist es, den Wert für die Laufzeit eines Zertifikats festzulegen: »default_days = 1460« steht für vier Jahre. Unter dem Konfigurationsabschnitt »[req]« setzen Sie die Länge des Schlüssels von gewöhnlich 1024 Bit auf »default_bits = 2048«. Der Rest der Default-OpenSSL-Konfiguration darf bleiben, wie sie ist.

Initialisierung der Zertifikatsautorität

Nun starten Sie das CA-Skript zum ersten, aber beileibe nicht zum letzten Mal:

cd /usr/lib/ssl/misc
./CA.pl -newca

Bei der Frage nach einem Zertifikatsnamen drücken Sie einfach [Return]. Danach errechnet das Skript den RSA-Schlüssel und fordert zur Eingabe eines Master-Kennworts für den privaten RSA-Schlüssel und zum Befüllen der Zertifikatsfelder des Root-Zertifikats entsprechend Listing 5 auf. Nachdem Sie alles ausgefüllt haben, müssen Sie noch einmal ein Kennwort für das gesamte Zertifikat eingeben und bekommen die Zertifikatsfelder präsentiert.

01 Country Name (2 letter code) [AU]:DE
02 State or Province Name (full name) [Some-State]:NRW
03 Locality Name (eg, city) []:Heimat des FC Schalke 04
04 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Hxchaos Industries
05 Organizational Unit Name (eg, section) []:RootCA
06 Common Name (eg, YOUR name) []:RootCA
07 Email Address []:jungconsultant@hxchaos.local

Ihre nächste Aufgabe besteht darin, für die drei Server Zertifikatsanfragen zu erstellen. Die bewältigen Sie leicht mit »./CA.pl -newreq«. Danach vergeben Sie ein PEM-Kennwort für den erzeugten Schlüssel und belegen die Felder für den Server »idefix.hxchaos.local« nach Belieben. Nur das Feld »Common Name« ist signifikant:

Common Name (eg, YOUR name) []:idefix.hxchaos.local

Jetzt starten Sie noch »./CA.pl -sign« und signieren das neue Zertifikat. Die entstehenden Dateien »newcert.pem« und »newkey.pem« sowie das CA-Zertifikat »cacert.pem«, das unterhalb des Verzeichnisses »demoCA« liegt, positionieren Sie auf »idefix.hxchaos.local« im OpenLDAP-Konfigurationsverzeichnis »/etc/ldap«. Dort in der »slapd.conf« setzen Sie zunächst die SSL-Konfigurationsparameter:

TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCACertificateFile   /etc/ldap/cacert.pem
TLSCertificateFile     /etc/ldap/newcert.pem
TLSCertificateKeyFile  /etc/ldap/newkey.pem

Die Einstellungen gelten ebenfalls für den Slurpd. Sie brauchen lediglich beim Daemon-Start mitzuteilen, dass er den SSL-Port aktivieren möge:

slapd -h ldap:/// ldaps:/// -g openldap -u

Viele Linux-Distribution verfügen über eine globale Konfigurationsdatei für den Daemon (im Verzeichnis »/etc/conf.d/slapd« oder bei Debian unter »/etc/default/slapd«). Sie können auch dort den Parameter setzen.

Ausrollen der letzten Replizierungsparameter

Die Konfigurationsschritte von eben müssen Sie für alle Slapd-Dienste der anderen beteiligten Server wiederholen. Um die Replikation in Zukunft per SSL auszuüben, modifizieren Sie außerdem die Replica-Parameter auf »idefix.hxchaos.local«:

replica uri=ldaps://flexus.hxchaos.local:636
        binddn="cn=sync,dc=hxchaos,dc=local"
        bindmethod=simple credentials=volker

Sowohl für den Flexus-Server, als auch für den Foxtrott:

replica uri=ldaps://foxtrott.hxchaos.local:636
        binddn="cn=sync,dc=hxchaos,dc=local"
        bindmethod=simple credentials=volker

Wer das Setup richtig dicht machen will, könnte explizite Verbindungsregeln setzen und die Replikation per Klartext auf Port 389 verbieten.

Warmlaufen fürs nächste Projekt: LDAP 2.4

Geschafft! Sie haben die verteilte Umgebung etabliert. Fortan können sich alle Dienste auf einen ausfallsicheren und performanten LDAP stützen, seien es Mailserver, Ihre Public Key Infrastructure oder ein Samba-Server. Die Zukunft aber heißt OpenLDAP 2.4 und bringt neue Features, unter anderem den Standby-Master, den der Autor dieses Artikels schon lange vermisst. Denn der Ausfall eines Masters kann heute trotz der Existenz von Slaves noch gravierende Probleme bereiten. Ebenfalls zu erwarten ist eine N-Multi-Master-Replikation.

Für Produktivumgebungen gestaltende Jung-Consultants ist das nur ein Wetterleuchten in der Ferne, denn OpenLDAP 2.4 laboriert im Alphastadium herum und eignet sich heute nur für Experimente in Xen- oder VMware-Umgebungen. Gleichwohl liefert sie einen Anhaltspunkt dafür, welchen Wandel der Baumriese OpenLDAP durchlebt. Es bleibt daher spannend, mit welcher Funktionalität und Stabilität sich in Zukunft LDAP-Daten replizieren lassen. (jk)