Login
Newsletter
Werbung

Thema: OpenLDAP wird 20 - und künftig in RHEL und SLE fehlen

19 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von tvn am Do, 16. August 2018 um 15:48 #

Ich finde es super, dass eine Software wie OpenLDAP exestiert und nach wie vor gepflegt wird. Leider sehe ich großes Verbesserungspotential was die Dokumentation angeht.

Selbst verwende ich inzwischen auch 389 Directory Server, weil ich mit dieser Software in der Lage war:


  • Passwort-Hashes auf Salted SHA512 statt SHA-1 umzustellen

  • LDAPS schnell einzurichten

  • LDAPS Cipher einstellen zu können

Ich möchte damit nicht sagen, dass all das mit OpenLDAP nicht möglich ist. Ich bin nur kein LDAP Experte und habe für leider für OpenLDAP keine Dokumentation gefunden wie ich diese Anforderungen umsetzten kann.

  • 0
    Von Sven der nicht registrierte am Do, 16. August 2018 um 17:08 #

    Doku ist leider das Hauptproblem von OpenLDAP. Vieles, was man machen will, ist schlecht dokumentiert und man muß sich durch zig Google-Seiten mit Ergebnissen von Leuten herumschlagen, die z.T. selber nicht wissen, was sie da tun und warum das klappt oder nicht klappt...

    Bücher gibt es zu dem Thema auch kaum welche, vor allem brauchbare.

    389 ist dagegen erheblich komplexer, und wenn man dann zu FreeIPA hingeht, wird es richtig kompliziert ...

    • 0
      Von tvn am Do, 16. August 2018 um 20:19 #

      389 ist dagegen erheblich komplexer, und wenn man dann zu FreeIPA hingeht, wird es richtig kompliziert ...

      Darf ich fragen, was du mit komplexer meinst? Vielleicht verstehe ich deine Aussage hier falsch, weil ich 389 als besonders einfach einzurichten wahrgenommen habe - auch noch bevor ich bei den von mir angesprochenen Punkten angekommen war.

      • 0
        Von Sven der nicht registrierte am Do, 16. August 2018 um 22:36 #

        Ich hab nur mal einen Tag mit 389DS zugebracht und dabei hab ich die Struktur nicht wirklich verstanden, insbesondere mit dem (verpflichtenden?) Webinterface. Zugegeben, das war mehr gespielt als alles andere und ich hab seit Ewigkeiten Erfahrungen mit OpenLDAP, und da war zumindest in der alten Variante die Basiskonfiguration einfach über ein paar Config-Dateien erledigt (bei dem neuen Verfahren mit der Konfig als eigenen LDAP-Tree wird das auch schon wieder schwer zu durchschauen).

        Da aber das Projekt, für das ich mir das angeschaut habe, immer noch in der Pipeline steckt, werde ich wohl vor dem Hintergrund des Support-Endes von RH für OpenLDAP die Möglichkeiten auf 389DS und FreeIPA einschränken müssen, wenn das dann ernsthaft losgeht. Dann werd ich auch mehr Zeit haben, mal tatsächlich die Doku zu lesen (die RH-typisch ziemlich gut, aber auch sehr langatmig ist).

        • 0
          Von tvn am Fr, 17. August 2018 um 15:11 #

          Wenn du mit Webinterface die 389 Console meinst: Ist ja sogar noch schlimmer, weil es eine Java Applikation ist :shock: , die ist aber soweit ich das verstanden habe nur ein Interface auf das was bei OpenLDAP slapd-config(5) ist. Persönlich nutze ich sie inzwischen sogar recht gern. Sollte es dir für einen schnelleren Einstieg helfen: Ich habe mal meine Dokumentation zu dem Thema hochgeladen. Die ist natürlich weder vollständig noch erhebe ich Anspruch auf Korrektheit. hier auf ReadTheDocs einsehbar.

          […] alten Variante die Basiskonfiguration einfach über ein paar Config-Dateien erledigt (bei dem neuen Verfahren mit der Konfig als eigenen LDAP-Tree wird das auch schon wieder schwer zu durchschauen).

          Genau das hatte mir zuletzt Kopfzerbrechen bereitet, weil ich eine über 10 Jahre alte OpenLDAP Dokumentation auf den aktuellen Stand bringen wollte. Und mir war es nicht ersichtlich was ich jetzt über slapd-config(5) lösen kann und was ich mit slapd.conf(5) noch machen muss.

          Wie es mit FreeIPA aussieht kann ich noch nicht sagen, das war bislang für meine Use-Cases kräftig überdimensioniert.

    0
    Von Michael Ströder am Fr, 17. August 2018 um 09:45 #

    Salted SHA-512 geht auch mit OpenLDAP, entweder mit {crypt} und entsprechendem crypt(3) Passwortformat, oder mittels des Overlays pw-sha2.

    • 0
      Von tvn am Fr, 17. August 2018 um 15:26 #

      Also kann ich den OpenLDAP Standard-Passwort-Hasher auf crypt umstellen? Ich hatte damals nichts dazu gefunden, lasse mich aber gerne weiterbilden.

      Das entsprechende Kapitel 14.4 der Dokumentation hilft mir gerade irgendwie auch nicht weiter. Ich finde die Beschreibung was es für Methoden gibt aber nicht wie ich sie auswähle. Vielleicht habe ich auch inzwischen zu sehr ein Brett-vorm-Kopf was das Thema angeht. Hast du vlt. eine vertrauenserweckende Anleitung zu dem Thema parat?

      edit: Vergiss ruhig die letzten Zusätze, Meike Stone hat freundlicher weise ausgeholfen :D

      Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Aug 2018 um 15:30.
1
Von lle am Do, 16. August 2018 um 21:32 #

Schade aber da fehlt es für den roten Hut und dem Kamelion mal wieder am Wirtschaftsmarkt. OpenLDAP fehlt es an Dokumentation? Ja aber wenn es für die genannten interessant wäre damit Geld zu verdienen würde sie diese erstellen. Wie sich andere Projekte einverleiben und dort doch tatsächlich auch die Dokumentation übernehmen :-D

Aber das ist ein universelles Problem mit den großen kommerziellen Distributionen. Da geht es, wie bei MS, immer nur um den Dollar :-) Dabei stützt sich ihr ganzes Imperium auf freie Software. RH kaufte Jboss und schon wurde in CE und Commercial getrennt. SLES nutzt Leap wie MS Windows 10 nutzt um den lästigen Beta Test auf alle Anwender zu verteilen.

Aber ohne Geld geht es anscheinend nicht. Oder etwa doch? Wo die großen Finanz- und Wirtschaftskonzerne doch auf einmal viel Geld an Open Source Projekte spenden. Natürlich nur um diese zu fördern! Wie selbstlos ;-)

Red Hat und Suse sollten sich schämen. Verdient ihr nicht schon genug? Man sollte nie vergessen wo man herkommt!

  • 1
    Von EinBisschenSpasmusSein am Do, 16. August 2018 um 21:55 #

    Man sollte nie vergessen wo man herkommt!

    Ihr könnt Linux aus dem Ghetto holen, aber nicht das Ghetto aus Linux! Yao! Shoo, bre!

    0
    Von Sven der nicht registrierte am Do, 16. August 2018 um 22:26 #

    JBoss und anderen Java-Kram brauch ich zum Glück nicht, weiß also nicht, was genau da der Unterschied zwischen Commercial und CE ist, aber bei dem meisten Zeug von RedHat hat doch die CE exakt Null funktionelle Einschränkungen gegenüber der kommerziellen Variante, es gibt schlicht nur keinen Support direkt von RedHat.

    Das ist mindestens so bei RHEL -> CentOS, RHEV -> OVirt, 3 RH DS -> 389DS und RH IdM -> FreeIPA.

    Insofern kann ich mit dem Geschäftsmodell von RedHat sehr gut leben, und SuSE ist mittlerweile doch leider mehr oder minder irrelevant.

0
Von Anonymous Coward am Fr, 17. August 2018 um 10:47 #

Was zum Geier soll das denn bitte sein? Das Wort Landmarke gibt es im Deutschen nicht, eine mögliche Übersetzung von „landmark“ wäre z. B. Wahrzeichen.

0
Von Michael Ströder am Fr, 17. August 2018 um 12:28 #

Es wird auch in Zukunft gewartete OpenLDAP-Pakete für SUSE Linux geben:

https://build.opensuse.org/package/show/network:ldap/openldap2

0
Von Meike Stone am Fr, 17. August 2018 um 12:43 #

Ich werde openLDAP in der Distribution auf jeden Fall vermissen, für kleinere Sachen sehr gut zu gebrauchen.
Leider habe ich nicht nur positive Erfahrungen gemacht:
- So wird openldap schnarchlangsam bei der Suche, wenn in einem Index mehr als 2^32 gleiche Werte vorkommen (z.B.: Meier) dann muss man in den Header-Dateien rumfummeln und selber kompilieren (Stichwörter: LDAP_PVT_THREAD_STACK_SIZE und BDB_IDL_LOGN)
- Zuverlässigkeit der Multimasterreplikation bei Großen Installationen lässt zu wünschen übrig
- keine wirkliche zuverlässige ACL/ACI Unterstützung.

Da laufen andere LDAP-Implementationen stabiler und vom openLDAP gibt es auch einen stabilen Fork:

https://github.com/leo-yuriev/ReOpenLDAP


Als Vorteile sind klar:
- Referenzimlplementierung -> so fehlen selbst heute noch bei z.B: OpenDJ alias dereferencing..
- kleines Installationspaket, einfache Konfiguration, gute Dokumentation!
- Modularität, und dadurch viele Zusatzfunktionen

Als Buch kann ich empfehlen:
OpenLDAP 2.4 ->ISBN-10: 383621198X

zum Kommentar von tvn:
..kann ich so nicht nachvollziehen
> Passwort-Hashes auf Salted SHA512 statt SHA-1 umzustellen
hier muss man nur das Contib-Modul übersetzen (nicht mal den LDAP)
moduleload pw-sha2.so
password-hash {SSHA512}

> LDAPS schnell einzurichten
> LDAPS Cipher einstellen zu können

äm nö - Start-Config hier:

TLSCACertificateFile /etc/openldap/certs/myroot.pem
TLSCertificateFile /etc/openldap/certs/myhost.mydom.de.crt
TLSCertificateKeyFile /etc/openldap/certs/myhost.mydom.de.key
TLSCipherSuite HIGH:MEDIUM:-SSLv2

  • 0
    Von Meike Stone am Fr, 17. August 2018 um 12:52 #

    .. und ich vergaß, natürlich den slapd dann auch mit ldaps starten:
    slapd -h ldap:/// ldaps:/// ....

    0
    Von Michael Ströder am Fr, 17. August 2018 um 12:58 #

    Es ist nicht sinnvoll, einen Index anzulegen, wenn dann so viele gleiche Werte drinstehen. Das macht die Suche eher langsamer, da in einem ersten Schritt immer sog. Candidate Sets von allen indexierten Attributen erzeugt werden, welche dann in einem zweiten Schritt nochmals mit den Filterteilen der nicht-indexierten Attribute gefiltert werden.

    Typisches Beispiel für ein Anti-Pattern bei der Indexierung:

    (uid=foobar) gibt immer einen einzelnen Eintrag zurück

    Man indexiert dann natürlich das Attribut uid:

    index uid eq

    Jetzt nur aktive Benutzer suchen:

    (&(uid=foobar)(organizationalStatus=aktiv))

    Wenn man organizationalStatus auch indexieren lässt, so verschlechtert man massiv die Performance! Im ersten Schritt werden dann nämlich immer zwei Candidate Sets jeweils für uid (1 Ergebnis) und für organizationalStatus (n Ergebnisse) gebildet.

    • 0
      Von Meike Stone am Mo, 20. August 2018 um 10:04 #

      Hallo,

      das mag sein, dass es im Fall von openLDAP nicht sinnvoll ist, aber es ist eine Implementierungsschwäche vom openLDAP, in diesem Fall eine "statische Deklaration von Speicherbereichen", welche vor der Compilierung vergrößert werden kann.
      Was wäre der Vorschlag, wenn man eine Datenbank mit Millionen von Einträgen hat und nach dem Nachnamen suchen möchte?
      (Btw. Der "Index-Slot" ist nur 2^16 nicht 2^32 wie ich oben erwähnte ... )
      Dass die Reihnefolge der Filter eine Rolle spielt ist klar ;-)

    0
    Von tvn am Fr, 17. August 2018 um 15:39 #

    ..kann ich so nicht nachvollziehen
    > Passwort-Hashes auf Salted SHA512 statt SHA-1 umzustellen
    hier muss man nur das Contib-Modul übersetzen (nicht mal den LDAP)
    moduleload pw-sha2.so
    password-hash {SSHA512}

    Wie gesagt ich bin kein LDAP Experte und hatte meine alten Konfigurationen auf der Basis einer >10 Jahre alten Dokumentation gemacht. Zusätzlich hatte ich Probleme entsprechendes in der Dokumentation zu finden. Aber vielen Dank für die Tipps! Hättest du eine Referenz zur Dokumentation zur Hand? Ich hoffe das mir das helfen würde mich durch die Dokumente von OpenLDAP zu suchen. Auch wenn ich zugeben muss, dass es mir etwas seltsam/unhandlich vorkommt etwas selbst dafür zu übersetzten. Ich versuche meine Software immer soweit es geht aus gepflegten Quellen zu beziehen, damit ein besseres Auge auf Sicherheitsupdates liegt.

    Aber so werde ich dem ganzen nochmal einen Versuch geben, es schadet ja nie sich weiter zu bilden :D Danke nochmal!

    • 1
      Von Meike Stone am Mo, 20. August 2018 um 12:17 #

      "Hättest du eine Referenz zur Dokumentation zur Hand"
      "Hier bitte .. (Link per a Tags, sonst zu lang für dieses Board?!)"

      Die Installation unter SLES11 sah irgendwie so aus:

      zypper in openldap2-devel
      zypper in libdb-4_5-devel mozilla-nspr-devel mozilla-nss-devel openslp-devel tcpd-devel
      wget ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.xx.tgz
      tar -xzf openldap-2.4.xx.tar.gz
      cd openldap-2.4.xx
      ./configure
      cd ./contrib/slapd-modules/passwd/sha2
      ../../../../libtool --mode=link gcc -g -O2 -Wall -module -o /usr/lib64/libldap_r.la /usr/lib64/libldap_r.o
      ../../../../libtool --mode=link gcc -g -O2 -Wall -module -o /usr/lib64/liblber.la /usr/lib64/liblber.o
      vi Makefile
      LDAP_LIB = /usr/lib64/libldap_r.la \
      /usr/lib64/liblber.la
      make
      cp /root/ap-2.4.42/contrib/slapd-modules/passwd/sha2/.libs/* /usr/lib/openldap/modules
      vi /etc/openldap/slapd.conf
      modulepath /usr/lib/openldap/modules
      moduleload pw-sha2.so

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung