Im Februar 2019 erhielt der Univention Directory Notifier eine neue Protokollversion, die die Replikation von Verzeichnisdienstinhalten innerhalb der UCS Domäne sicherer macht. Um das erreichen zu können, mussten unter der Haube einige Dinge geändert werden.

Univention Directory Notifier – was ist das überhaupt?

Innerhalb einer UCS Domäne werden Informationen, die im OpenLDAP Verzeichnisdienst gespeichert werden, vom UCS Master (oder von UCS Backups) auf weitere UCS Systeme repliziert. Das grundlegende Konzept wurde in unseren Artikeln UCS: LDAP-Replikation leicht gemacht und Ausfallsicherheit und Lastverteilung durch LDAP-Replikation im Blog bereits thematisiert.

Ganz konkret erfolgt die Replikation über den sog. Listener-/Notifier-Mechanismus: Auf allen domänenfähigen UCS Systemen läuft der Systemdienst „Univention Directory Listener“ (UDL). Zudem läuft auf dem UCS Master sowie den UCS Backups der Systemdienst „Univention Directory Notifier“ (UDN). UDL fragt dann kontinuierlich einen UDN nach neuen Transaktionen im Verzeichnisdienst ab, bspw. die Passwortänderung eines Benutzers, um diese dann anschließend auf das lokale System zu übertragen:

Ablauf der Replikation

Bislang (Protokollversion 2) lief die Replikation wie folgt:

  1. UDL baut (sofern noch nicht passiert) eine Verbindung zum UDN auf.
  2. Der UDL fragt die Nummer der letzten Transaktion ab.
  3. Der UDL wartet auf die nächste Transaktion und blockiert so lange.
  4. Sobald die besagte Transaktion passiert ist, sendet der UDN bisher unverschlüsselt über die Verbindung den Distinguished Name (DN) des Eintrags, der geändert wurde.
  5. Anschließend baut UDL eine verschlüsselte Verbindung zum LDAP-Server auf, authentifiziert sich mit dem Maschinenkonto und ruft den kompletten Eintrag ab.

Die Problematik liegt nun im Punkt 4 und der unverschlüsselten Verbindung. Zwar lassen sich hierüber keine hochsensiblen Informationen wie Passwort-Hashes abrufen, allerdings wird der Distinguished Name (DN) übermittelt, aus dem sich u. U. auch Informationen zu Benutzernamen und E-Mail-Adressen ergeben.

Die neue Protokollversion 3 macht nun folgendes anders:

  1. Während des Verbindungsaufbaus wird „Version 3“ ausgehandelt.
  2. Der Listener verwendet nun eine andere Methode zum Abfragen der Transaktion. Ihm wird vom Notifier nicht mehr direkt der Distinguished Name (DN) geliefert, sondern lediglich die letzte Transaktionsnummer, die keine weiteren Rückschlüsse auf Benutzer erlaubt.
  3. Statt direkt nach dem DN zu fragen, fragt der UDL zuerst über die verschlüsselte, authentifizierte LDAP-Verbindung nach dem LDAP-Eintrag reqSession=$TRANSAKTIONSNUMMER,cn=translog. Erst dieser enthält dann im Attribut reqDN die DN des eigentlichen LDAP-Eintrags, der erst dann abgefragt wird.

Damit UDL auch nach längerer Downtime wieder auf den aktuellen Stand kommen kann, muss UDN alte Transaktionen vorrätig halten. Bislang wurde dafür die Datei /var/lib/univention-ldap/notify/transaction genutzt. Ab Protokoll Version 3 wird zusätzlich die LDAP-Datenbank cn=translog verwendet. Dabei handelt es sich um eine neu eingeführte, zweite Datenbank, die unabhängig von der LDAP-Datenbank ist, die die regulären Verzeichnisdienstinhalte wie Benutzer und Gruppen enthält. Sie finden die neue Translog-Datenbank unter /var/lib/univention-ldap/translog/.

Alt-Systeme, die noch mit UCS 4.3 installiert werden oder wurden, bieten weiterhin noch das alte Protokoll in Version 2 an. Neuinstallationen ab UCS 4.4 bieten standardmäßig nur noch Version 3 an. Über die UCR-Variable notifier/protocol/version kann dies bei Bedarf angepasst werden.

Weiterführende Informationen

Für Entwickler wurde auch die Developer Reference überarbeitet. Hier finden sich weitere Details, bspw. hinsichtlich Listener-Cache, Weitergabe der Informationen an die Listener-Module und Index zur transaction Datei.
Im der Kategorie „Knowledge Base“ im Univention Forum haben wir zwei Artikel zur tiefergehenden Analyse und Behebung von möglichen Problemen im Zuge der Replikation bereitgestellt:

Michael Grandjean

Open Source Software Consultant und Mitglied des Professional Services Teams bei Univention.

Philipp Hahn

Open Source Software Contributor vom Kernel bis Python seit 1996, Debian Maintainer seit 2002 und Mitglied des Software Engineering-Teams von Univention seit 2009.

Was ist Ihre Meinung? Hinterlassen Sie einen Kommentar!

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.