Open Source im professionellen Einsatz
Linux-Magazin 07/2015
© parawat isarangura na ayudhaya , 123RF

© parawat isarangura na ayudhaya , 123RF

Multimaster-Replikation

Sicherheitsnetz

Replikation stellt sicher, dass der Verzeichnisdienst LDAP verfügbar ist. Seit Version 2.4 funktioniert sie auch dann, wenn ein Master ausfällt. Das Zauberwort heißt Multimaster-Replikation.

573

Verzeichnisdienste sind in großen Netzwerken fast unverzichtbar, zugleich fällt es schnell auf, wenn Authentifizierung, Autorisierung oder Zertifikatsverwaltung schlecht verfügbar sind. Der Artikel erklärt, wie der Admin einen Open-LDAP-Server für den Masterbetrieb konfiguriert [1], der dann als Vorlage für einen weiteren Masterserver dient.

Abbildung 1: Mehrere Knoten bauen ein Netz von LDAP-Servern und machen LDAP verfügbarer.

Wie Abbildung 1 zeigt, lässt sich diese Two-Way-Multimaster-Replikation leicht um einen Zusatzknoten erweitern. Traditionell heißen die an der Replikation beteiligten Server Master und Slave. Jeder Master dient dabei zugleich als Slave für jeden anderen Master. Zwei Knoten bilden also zwei überkreuzte Master-Slave-Umgebungen.

Open LDAP 2.4: Replikation

Dieses Modell der Replikation ([1], [2])klappt erst seit Version 2.4 von Open LDAP, zuvor funktionierte Replikation noch etwas anders [3].

Auf den Master, der als Verzeichnisdienst dient, greifen die Clients schreibend zu. Der Slave erlaubt hingegen nur den Lesezugriff, auf ihn wird repliziert. Open LDAP gleicht Master und Slave über die LDAP Sync Replication Engine (»syncrepl« [4]) ab.

Seit Open LDAP 2.4 gilt diese strikte Unterteilung der Server in Master und Slave nicht mehr. Es ist nun möglich, einen Directory Information Tree (DIT) zwischen mehreren Mastern synchron zu halten. Der Slave heißt im LDAP-Kontext Consumer und fungiert als Client gegenüber dem Server. Den bezeichnen die LDAP-Entwickler als Provider. Auf einem Knoten laufen meist ein Consumer und ein Provider, die – wie erwähnt – über Kreuz miteinander kommunizieren. Nach diesem Schema konfiguriert der Admin mit mehreren LDAP-Servern eine n-Way-Multimaster-Replikation.

Abbildung 2: Der Consumer nimmt gewöhnlich Kontakt mit dem Provider auf, um die Replikation anzustoßen.

Der Consumer baut dabei periodisch die Verbindung zum Provider auf und fragt entweder die Änderungen aktiv ab (Consumer Poll, »refreshOnly« ) oder wartet darauf, dass der Provider ihm diese sendet (Provider Push, »refreshAndPersist« , Abbildung 2). Dabei kann ein Consumer alle Provider kontaktieren, deren Zugangsdaten er kennt. Im Produktivbetrieb sollte der Admin die Verbindungen unbedingt verschlüsseln.

Bezugsquelle

Die nun gezeigten Beispiele laufen auf einem aktuellen Centos 7, lassen sich jedoch relativ einfach auf andere Distributionen übertragen [5]. Dort heißt unter Umständen das Verzeichnis für die Konfigurationsdateien anders oder die installierte Grundkonfiguration weicht etwas vom beschriebenen Schema ab.

Die Installation auf Centos 7 beziehungsweise RHEL 7 erfordert das RPM-Paket »openldap-servers« . Im Artikel konfiguriert der Admin Open LDAP ausschließlich über »slapd-config« , eine dynamische Engine zur Laufzeitkonfiguration. Sie existiert als eigene LDAP-Datenbank mit dem Index »{0}« , ihr Distinguished Name (DN) lautet »cn=config« .

Im Gegensatz zu LDAP-Datenbanken wie der Berkley DB (DBD) oder deren Weiterentwicklung HDB befinden sich die Konfigurationsdateien für »slapd-config« nicht im Datenbankverzeichnis von Open LDAP, sondern liegen im lesbaren LDAP Data Interchange Format (LDIF) im Dateisystem unter »/etc/openldap/slapd.d/cn=config« . Im Notfall kann der Admin sie also direkt verändern.

Der übliche Weg, um die LDAP-Konfiguration anzupassen, führt jedoch über die LDAP-Clients »ldapadd« , »ldapdelete« und »ldapmodify« oder einen beliebigen LDAP-Browser. Sie setzen Änderungen zur Laufzeit um und aktivieren diese unmittelbar, ohne dass der Admin den »slapd« -Daemon neu starten muss.

Er sollte also darauf achten, diese Dateien nur im Notfall direkt zu ändern. Vor dem Neustart prüft er die modifizierte Konfiguration zudem am besten mit »slaptest« auf ihre Korrektheit. Konfiguriert er LDAP hingegen im laufenden Betrieb über »slapd-config« , nimmt die Engine die Syntax- und Integritätsprüfung automatisch vor.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 4 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Webanwendungen

    Statt die Authentifizierung und Rechtezuordnung für die Nutzer von Webanwendungen aufwändig mittels Tabellen in Datenbanken zu managen, lässt sich diese Aufgabe als Admin auch bequem und sicher über ein vorhandenes LDAP erledigen.

  • Bäumchen repliziere dich

    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.

  • Auskunft, wo ist mein Objekt?

    Enterprise-Anwendungen sind verteilte Anwendungen und das Auffinden von Ressourcen stützt sich dabei auf Namens- und Verzeichnisdienste. Dieser Artikel gibt eine Einführung in das Java Naming and Directory API (JNDI) und zeigt seine Anwendung anhand des freien LDAP-Servers OpenLDAP.

  • In der Vermittlerrolle

    Einer für alles - so lautet die Devise der LDAP-Befürworter. Das Plugin »ldapdb« agiert als Proxy zwischen einem Postfix-Mailserver und dem zentralen Verzeichnisdienst und sorgt für sichere Nutzerauthentifizierung mit den Mechanismen des Simple Authentication and Security Layer.

  • Straffe Verwaltung

    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.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.