X

Wie geht es eigentlich mit OpenLDAP weiter?

Heute mal was zum OpenLDAP. Ja, der Eine oder Andere wird jetzt sagen: „Der ist doch eh tot“. Nur stimmt das nicht. Die Entwicklung geht auch hier weiter. Zur Zeit hat die aktuelle Version die Versionsnummer 2.5.6, die auch schon sehr stabil läuft und auch schon genutzt werden kann. Leider gibt es noch für keine Distribution die entsprechenden Pakte. Selber bauen ist angesagt. Nur im Debian Experimental gibt es die Pakte schon, aber wer möchte Experimental schon produktiv einsetzen? Genau, niemand.

Aber wie geht es weiter mit OpenLDAP?

Für 2.4 gibt es nur noch kritische Updates, Neuerungen wird es hier nicht mehr geben. 2.4 hat den Status „end of live“ erreicht. Im September dieses Jahres wird es dann die Version 2.6 geben, die dann über längere Zeit mit Updates versorgt wird. Mit dem Erscheinen der Version 2.6 wird es keine Updates mehr für 2.4 geben. Ob das wieder 14 Jahre sind wie bei 2.4 wage ich zu bezweifeln. Im nächsten Jahr wird dann eine Version 2.7 erscheinen. Mit dem Erscheinen der 2.7 wird es keine Updates für 2.5 mehr geben.

Lohnt der Umstieg auf OpenLDAP 2.6? Ja, auf jeden Fall, denn einen performanteren Verzeichnisdienst wird man so schnell nicht finden.

Warum denken viele OpenLDAP sei tot? Da gibt es eine Firma die unbedingt ihren 389DS durchsetzen will und OpenLDAP das Wasser abgraben möchte. Wer von OpenLDAP auf 389DS wechsel will, sollte sich das aber genau überlegen. Eine Übernahme der Daten ist nicht so einfach realisierbar. Das Sicherheitskonzept ist ein komplett anderes. Die ACLs sind komplett anders und müssen alle neu eingerichtet werden. Auch fehlen viele Funktionen, die der OpenLDAP bereitstellt, noch komplett. Im 389DS so ist es momentan (so mein Stand) noch nicht möglich einen LDAP-Proxy zu realisieren. Wer also seine LDAP-Server z.B. in einer DMZ eingerichtet hat und damit die Daten für die Authentifizierung externe Mitarbeiter aus dem Active Directory holen will, kann das nur mit OpenLDAP realisieren.

Alles vielleicht für den Einen oder Anderen kein Thema, aber zu bedenken ist auch, mit dem 389DS wir IMMER Java auf dem LDAP-Server benötigt, auch wenn keine grafische Oberfläche installiert werden soll. Dann kommt dazu, dass die Java-Version die mit dem 389DS installiert wird, eine Oracle-Lizenz unterliegt. Spätestens an dem Punkt sollte man sich Gedanken machen warum man eigentlich auf open source Software gesetzt hat.

Ich habe die Version 2.5 jetzt schon eine Zeit lang getestet und viele neue Möglichkeiten haben schon was, so gibt es jetzt die Möglichkeit automatisch Client-Zertifikate vom OpenLDAP erstellen zu lassen. Einfach die eigene CA hinterlegen und alles andere geht dann automatisch. Auch die Passwortverschlüsselung mit Argon2 funktioniert jetzt mit einem eigenen Overlay. Zusammen mit der Möglichkeit der Einrichtung einer zwei Faktoren Authentifizierung kann man den Sicherheitsstandard schon sehr hoch ansetzen.

Endlich wird auch in den dynamischen Gruppen das „member“-Attribut bei der Suche ausgewertet, so ist es jetzt möglich, dynamische Posix-Gruppen zu erzeugen, denn dann im Dateisystems eines Fileservers Rechte zugewiesen werden können. Was bringt das? Ich erzeuge für jede meiner Abteilung oder Projektgruppe eine eigene dynamische Posic-Gruppe. Der Gruppe gebe ich auf unterschiedlichen Fileservern verschieden Rechte. Dann suche ich mir ein Benutzerattribut, das beim Eintrag eins bestimmten Wertes, den Benutzer automatisch zum Mitglied der Gruppe macht. Entferne ich das Attribut, wir der Benutzer automatisch auch aus der Gruppe entfernt und verliert somit auch sofort die Rechte auf den den Fileservern.

Auch was die Performance angeht wurde viel gearbeitet. Die Replikation wurde komplett überarbeitet auch wird durch ein effektives Loadbalancing werden die anfragen beim Einsatz mehrerer LDAP-Server besser auf die alle LDAP-Server verteilt.

Wer mehr über die Neuerungen wissen möchte, hier ist ein interessanter Artikel der auf jeden Fall lesenswert ist.

Also, immer ein Auge auf die tot gesagten haben 😉

Categories: Allgemein
Stefan:
Related Post

This website uses cookies.