Diskussion:Lightweight Directory Access Protocol

LDAP und Datenbankmodelle

"LDAP agiert als Frontend zu hierarchischen Datenbanken.". Unsinn: LDAP ist ein Protokoll, kein Frontend. Typische Implementierungen von Verzeichnisdiensten, die LDAP als Protokoll unterstützen, verwenden zur Datenhaltung entweder eine Textdatei (passwd) oder Berkeley DB. Und Berkeley DB ist keine hierarchische Datenbank, sondern ein flat file mit Zugriff über eine Hash-Tabelle. Ob das objekt-orientierte, hierarchische Datenmodell von X.500 (das LDAP adaptiert) für einen Verzeichnisdienst sinnvoll ist, darüber kann sicher streiten - man sollte das aber bei X.500 diskutieren. Das sich relationale Datenbanken mit hierarchischen Datenstrukturen (Stücklisten, Stammbäumen, usw.) schwer tun, ist nicht diesen Datenstrukturen anzulasten, sondern eine Schwäche des relationalen Modells. --Jost Riedel (Diskussion) 10:02, 1. Dez. 2012 (CET)

Die ursprüngliche Aussage ist nicht richtig, da stimme ich zu. Mir geht es eher um die Aussage zur Berkeley DB, konkret im Zusammenhang mit OpenLDAP. Kommt es dabei nicht auf das verwendete Backend an? LMDB und HDB ist laut OpenLDAP Dokumentation hierarchisch. Bei HDB steht geschrieben "[...] uses hierarchical database layout [...]". Siehe: http://www.openldap.org/doc/admin24/backends.html Mkriesten (Diskussion) 17:57, 2. Feb. 2014 (CET)

Überarbeitung von ??

Folgenden Satz habe ich gelöscht:

Im theoretischen Vergleich mit einer relationalen Datenbank ist LDAP aufgrund seiner zugrundeliegenden hierarchischen Datenhaltung auf den ersten Blick haushoch unterlegen. Mit Vorkenntnissen relationaler Datenhaltung mag LDAP sogar zunächst als anachronistisch angesehen werden. Das ist eine subjektive und faktisch nicht belegbare Einschätzung. Welche Kriterien wendet man an, um zu zeigen das "LDAP haushoch unterlegen" ist? Wenig enzyklopädisch, trägt zum Verständnis nix bei, daher *plonk*

(nicht signierter Beitrag von Marychristmas (Diskussion | Beiträge) 13:39, 12. Jan. 2007‎ (CET))

Folgenden Satz habe ich gelöscht:

Metadirectories und die damit verbundenen Mechanismen versuchen, diese Probleme zu mildern (können sie aber nicht lösen, da die Probleme strukturell sind).

Der Begriff Metadirectories wird verwendet aber nicht erklärt. Auch halte ich den Satz für sachlich falsch: Metadirectories dienen dazu einen standardisierten Zugriff auf unterschiedliche Datenquellen zu bereitzustellen.

(nicht signierter Beitrag von Marychristmas (Diskussion | Beiträge) 11:38, 12. Jan. 2007‎ (CET))

Ich habe den Unterabschnitt "Keine erste Normalform, sondern Strings mit Format" gelöscht. Die Verschlüssellung von Userpassworten ist eine Option von LDAP, kein MUSS. Man wird diese Option nur dort einsetzen, wo sie Sinn macht, eine Abfrage über Userpasswörter ist völlig unsinnig.

(nicht signierter Beitrag von Marychristmas (Diskussion | Beiträge) 16:58, 11. Jan. 2007‎ (CET))

Ich habe den Unterabschnitt "DN" nicht stabil im Abschnitt "Schwächen von LDAP" gelöscht. Bei dem angegebenen Beispiel gibt der Autor (wohl unfreiwillig) eher ein Beispiel für schlechtes Design, anstatt für eine "Konstruktionsschwäche" eines etablierten Protokolls. Aus genau den vom Autor beschriebenen Gründen wird man in einem Verzeichnis bei den Personenobjekten auflisten, welche Mailinglisten sie abonniert haben, und nicht umgekehrt! Die Abonnentenliste der Mailingadresse erhält man dann über eine Abfrage!

(nicht signierter Beitrag von Marychristmas (Diskussion | Beiträge) 16:47, 11. Jan. 2007‎ (CET))

Ich habe mir mal erlaubt, den letzten Abschnitt "Schwächen von LDAP" zu löschen weil m.E nicht enzyklopädisch genug:

Volkommen gelöscht hab ich folgende:

== Schwächen von LDAP ==
Zu praktisch relevanten Schwächen von LDAP gehört leider eine allgemein schlechte oder schwer verständliche Dokumentation (betrifft gleichermaßen LDAP-Protokoll, LDAP-Server, LDAP-Clients und LDAP APIs), umständlich und meist extrem komplex zu verwendende APIs (Stichwort: Java JNDI) und allgemein wenig Erfahrung bei Programmierern. Aus diesen Schwächen resultieren viele LDAP-Praxis-Probleme, die zu einem eher schlechten Ruf von LDAP beitragen, weil Applikationsdesigner Anforderungen stellen, die sich mit LDAP nicht gut abbilden lassen und weil Programmierer LDAP-APIs häufig unsauber oder unperformant integrieren.

• Es gibt hervorragende Dokumentation zu LDAP, die dem Schreiber dieser Zeilen

möglicherweise nicht bekannt war

• Der Schreiber behauptet die Dokumentation **aller** LDAP Apis sei schlecht.

Das ist subjektiv geurteilt, und ich wage zu bezweifeln dass Schreiber *alle*

LDAP APIS kennt (JNDI, JavaLDAP, PHP, Pyton, Net::LDAP, .....usw )

• Der Schreiber postulierte einen hypothetischen nicht belegbaren Sachverhalt:

"..Applikationsdesigner Anforderungen stellen, die sich mit LDAP nicht gut

abbilden lassen"

*plonk*

(nicht signierter Beitrag von Marychristmas (Diskussion | Beiträge) 18:23, 8. Jan. 2007‎ (CET))

Für den Laien (wenn dieser LDAP z.B. in Thunderbird liest) vielleicht erklären, was man prinzipiell damit anstellen kann. Ist wahrscheinlich zu allgemein und sehr schwer zu fassen - aber vielleicht kann es trotzdem gelingen. (nicht signierter Beitrag von Hi.ro (Diskussion | Beiträge) 18:04, 27. Nov. 2005‎ (CET))

Weblink zeigt auf eine leere Seite, ändert sich das noch ? Ansonsten lösche ich den Link (nicht signierter Beitrag von Trixium (Diskussion | Beiträge) 20:08, 30. Mai 2003‎ (CEST))

der weblink "OpenLDAP, GPL Version eines LDAP-Verzeichnisses" is glaubich falsch. OpenLDAP steht unter der OpenLDAP Public License. siehe: http://www.openldap.org/devel/cvsweb.cgi

das is kein GPL.

(nicht signierter Beitrag von 82.207.202.82 (Diskussion) 06:54, 2. Jan. 2005‎ (CET))

Vielleicht kann mal jemand, der davon Ahnung hat, den Link unter 'Funktionsweise' zu dem Thema 'Schema' (Schemata) anpassen. --213.168.102.131 09:27, 11. Jan 2005 (CET)

Jahreszahl

Kann jemand die genaue Jahreszahl raussuchen, wann LDAP jetzt entwickelt wurde? Es gab zwei Ideen im Text, einmal 199 und einmal 1993 - gefunden habe ich aber zu beiden Daten nichts, weswegen ich es erst mal rausgenommen habe --Liquidat 12:36, 28. Jun 2005 (CEST)

hmm, http://www.ietf.org/rfc/rfc1487.txt - das ist offenbar das erste RFC für LDAP, ist vom Juli 93. Entwickelt wurde wahrscheinlich schon vorher... Kruemelmo 13:45, 28. Jun 2005 (CEST)

Prompte Antwort - ich werde versuchen, es passend reinzubauen. Macht es Sinn, das rfc zusätzlich zu verlinken? --Liquidat 14:02, 28. Jun 2005 (CEST)

Probleme von LDAP

Siehe auch meinen Vortrag http://kris.koehntopp.de/artikel/dir-vs-rel/, und den Vortrag von Kai, http://k.123.org/Kai%20Voigt/MySQL/3C23CB08-DE88-48B1-ABE3-5400A89B52FC.html (Folien werden noch Online gestellt)

Anmerkung: Sollte man nicht die "Problem von LDAP" in einen eigenen Artikel auslagern oder daraus einen abwägenden Teil "Vor- und Nachteile" von LDAP machen? So wie der Artikel ist, wundert man sich, dass überhaupt jemand LDAP nutzt. Die Vorteile werden momentan nicht gegen die Nachteile abgewogen. Hinweis: Ich werde mal "NetUSE" und die real existierenden Personen aus den Beispiel-DNs entfernen. Gruß Martin (falsch signierter Beitrag von Martinseeger (Diskussion | Beiträge) 08:46, 28. Jul. 2006‎ (CEST))

=== Keine erste Normalform, sondern Arrays ===

LDAP implementiert eine hierarchische Datenbank. Daten sind nicht einmal in erster Normalform gespeichert (multivalued attributes können erlaubt sein). Das macht es sehr schwer, LDAP-Systeme mit SQL-Systemen interagieren zu lassen, etwa LDAP mit einem SQL-Backend effizient zu realsieren.

=== Keine erste Normalform, sondern Strings mit Format ===

LDAP implementiert eine Reihe von Attributen, bei denen im Wert des Attributes mehr als ein Datum gespeichert ist. In Paßworten ist zum Beispiel im Paßwortstring vorne in geschweiften Klammern die Paßwortcodierung gespeichert: {crypt}blafasel ist ein Unix-Paßwort, {md5}blafasel ein MD5-codiertes Paßwort und {clear}secret ein Klartextpaßwort.

In LDAP ACLs-Attributen sind die ACEs als Multivalue-Attribute gespeichert, wobei jeder Wert als dreiwertites Tupel als String gespeichert ist. Das macht es nahezu unmöglich, eine Query zu formulieren, die alle Knoten liefert ab denen der User "kris" bestimmte Rechte hat.

=== DN nicht stabil ===

LDAP verwendet den DN eines Records als Primärschlüssel im Baum. Der DN ist aber nicht opak, sondern ein Pfad aus RDNs, die wiederum Kopien von strukturbildenden Attributen auf jedem Level enthalten. Ändern sich die Werte dieser strukturbildenden Attribute, ändern sich der DN des Records, damit ändert sich der Wert eines Primärschlüssels.

Wenn Verweise auf den Record existieren, dessen DN sich ändert, dann werden diese dadurch ungültig, denn es existiert im Standard kein Mechanismus, der so etwas konsistent halten kann (Active Directory versucht dieses Problem zu beheben, und im Netscape Server existiert mit dem Referential Integrity Plugin ebenfalls ein Versuch, das zu fixen). Das wiederum führt zu einer großen Anzahl von Updates im ganzen LDAP-Baum und in einem verteilten Setup mit Replikation zu einem Replikationssturm.

Beispiel: CN=Marit Köhntopp, OU=Kiel, O=NetUSE, C=DE heiratet und heißt nun wieder CN=Marit Hansen, OU=Kiel, O=NetUSE, CD=DE. Marit ist Mitglied von vielen Mailinglisten, eingetragen mit ihrem DN, darunter auch der Mailingliste "all" mit 9000 Subscribern. Das geänderte "all"-Objekt mit Marits neuem DN wird geschrieben und repliziert. Es ist 480 KB gross.

Alternativ werden Marits DNs in den Mailinglisten nicht angepaßt und sie fällt von allen Mailinglisten.

=== Partitionierung und Baumstruktur sind gekoppelt ===

Relationale Datenbanken koennen Tabellen entlang beliebiger Attribute und Ranges partitionieren (MySQL implementiert SQL92 und bietet die folgenden Optionen http://dev.mysql.com/doc/refman/5.1/en/partitioning-types.html).

In LDAP ist eine Partition und Teilreplikation nur entlang eines Subtrees moeglich, d.h. die Partitionierung erfordert die Einführung einer Hierarchieebene im DN (Es ist möglich, OU=Kiel, O=NetUSE, C=DE zu replizieren, aber es ist nicht möglich, alle Mitarbeiterrecords zu replizieren, bei denen das Standort-Attribut den Wert "Kiel" hat.).

Dadurch entsteht aber wieder Struktur im DN, und der DN ist nicht mehr opak. Ich muß den DN eines Mitarbeiters ändern, der nach Kiel versetzt wird (anstatt einfach sein Standort-Attribut zu ändern). Dadurch werden aber etwa wieder alle Mailinglisten-Subscriptions des Mitarbeiters ungültig (oder ich löse einen Replikationssturm aus).

=== Hierarchische Datenbank für relationale Probleme ===

LDAP implementiert eine hierarchische Datenbank, und ist mithin nicht in der Lage, n:m-Beziehungen zu modellieren. Es ist zum Beispiel nicht möglich, in einer LDAP-Datenbank sinnvoll eine Assetliste zu modellieren. Zwar kann ich eine Liste von Personen haben und auch eine Liste von Rechnern. Es ist aber schon nicht mehr sinnvoll möglich, die Beziehung zwischen Rechnern und Personen zu modellieren (mit "bezahlt", "steht bei" und "kann benutzen"-Relationen).

=== Abfragesprache limitiert ===

Von den relationalen Operationen Projektion (Spaltenauswahl), Selektion (Zeilenauswahl), Kreuzprodukt (Join), Spaltenumbenennung (Rename, AS) und Aggregation (GROUP BY) beherrscht LDAP nur Projektion (ohne Erzeugung von errechneten Attributen) und Selektion. Ein Join oder einen "Dereferenziere diesen DN"-Operator gibt es nicht, ein Rename (und damit ein Selfjoin) existiert nicht und Aggregation muss mit Schleifen im Client auscodiert werden.

Dadurch werden auf LDAP-Servern in der Regel sehr hohe "Queries per Second"-Werte erzeugt. So erzeugt ein Sendmail mit LDAP-Support mindestens 4, aber bis zu 7 Queries bei der Zustellung einer Mail an einen einzelnen lokalen Empfaenger, und noch weitaus mehr Queries bei der Zustellung an eine Mailingliste.

Aus diesem Grund ist fuer die effiziente Operation von LDAP fast immer eine lokale Replikationskopie des LDAP-Baumes notwendig, damit Netzwerklatenzen das System nicht ueber Gebuehr verlangsamen.

(nicht signierter Beitrag von 212.202.57.232 (Diskussion) 18:06, 14. Mai 2006‎ (CEST))

ist im Satz "unter ihm verzweigen sich die höheren Strukturen" nicht eine unlogik ? -- bluumi (falsch signierter Beitrag von 212.117.97.18 (Diskussion) 10:34, 29. Sep. 2006‎ (CEST))

LDAP vs. relationale Datenbank

Hier werden die beiden Technologien aus meiner Sicht etwas kurz gegenübergestellt.

Interessant wäre es hier auch herauszuarbeiten, wann man besser einen LDAP Server verwendet und wann eine relationale Datenbank ausreichend ist. Es gibt sicherlich Indizien die ganz klar für das eine oder andere sprechen. Aber da ist sicherlich auch ein großer grauer Bereich, wo man sich nicht sicher ist, wie man sich entscheiden soll.

Ein paar Statistiken wann bzw. wo LDAP Server eingesetzt werden, wäre sinnvoll. Ich würde mir so etwas erhoffen wie "ab X lesenden und weniger als Y schreibenden Datenzugriffen pro sekunde/minute/stunde bei insgesammt Z gespeicherten Daten der Hierarchietiefe n (z.B. 1-3)"

Gibt es solche Statistiken überhaupt?

(nicht signierter Beitrag von 62.159.112.38 (Diskussion) )

Inkonsistenz

Ich will ja nicht meckern, aber wieso steht im Artikel zu LDAP "[...] eines Verzeichnisdienstes (eine im Netzwerk verteilte hierarchische Datenbank) [...]" als Erklärung für ein Verzeichnisdienst, wenn in der Definition zu ADS (ein Verzeichnisdienst, der LDAP benutzt) "Das Active Directory baut auf einer Datenbank auf, [...] Sie ist relational, transaktionsorientiert [...]" steht? Also entweder ist das Datenbankmodell dann nicht immer hierarchisch, oder hierarchisch (bzw. relational, transaktionsorientiert) ist völlig falsch.

(nicht signierter Beitrag von 62.214.116.36 (Diskussion) 16:34, 13. Mär. 2007‎ (CET))

Baumstruktur-Bild

Hallo, die Angaben unter dem Baumstruktur-Bild scheinen IMHO ohne mich näher mit LDAP beschäftigt zu haben, teilweise falsch, da im Knoten andere Werte stehen als in den Attributen darunter. Also Copy&Paste-Fehler? Kann da mal jemand bitte darüberschauen und das überprüfen? 212.202.71.51 09:55, 15. Aug. 2007 (CEST)

Anregung zu Port und Anmerkung zur Geschichte

Bitte gebt Doch neben der übrigens sehr schönen Stackaufbauskizze jeweils den Std - Port an (unsecured und secured) dies ist eine wichtige info und muss extra noch zusammengesucht werden.

LDAP hat enorm von einer grundlegenden Vorarbeit profitiert: dem einzigen ernstzunehmenden Netzwerkverzeichnisdienst, der anfang 90er existiert hatte : NDS Novell Directory Services, später umbenannt in eDir, nachdem Microsoft 50% des Konzepts übernommen hatte. Heute ist jede eDir Installation auch LDAP-fähig, nur ist der Strukturaufbau in den Projekten etwas unterschiedlich zu vielen Linux-LDAP- implementationen. Das hängt aber mit dem Organisationskonzept von eDir zusammen. Gruss b.cosandey@hotmail.com

(falsch signierter Beitrag von 82.220.52.50 (Diskussion) 17:57, 23. Jan. 2008‎ (CET))

Was bedeutet die folgende Aussage?

"Es gibt drei Arten von Objektklassen: Da ein Objekt zu mindestens einer strukturellen Klasse gehören muss, ist dies die Standardeinstellung."

(nicht signierter Beitrag von 87.78.248.117 (Diskussion) 14:45, 22. Aug. 2008‎ (CEST))

Referenzimplementierung?

In den Weblinks wird OpenLDAP als Referenzimplementierung ausgegeben. Quellen dafür konnte ich nicht finden. De facto referenzimplementierung?

In http://www.openldap.org/lists/openldap-software/200206/msg00453.html wird behauptet, dass der Standard durch den RFC und nicht durch eine Implementierung definiert ist. Kann das jemand fixen?

--Self 13:09, 4. Okt. 2008 (CEST)

falscher "Directory Access Protocol"-Redirect

Das "Directory Access Protocol" auf LDAP verweist ist falsch DAP ungleich LDAP. --Bkmzde 09:47, 29. Mär. 2010 (CEST)

Abgrenzung zu Datenbanken

Hallo,

ich finde, dieser Bezug müsste noch in den Artikel, da man sich fragen könnte, warum man denn keine Datenbank verwendet, um Nutzerdaten oder Konfigurationsdaten zu halten und abfragbar zu machen. Ein Abschnitt darüber wäre schön und sinnvoll, soweit ich sehe.

mfg Captainsurak 17:35, 26. Aug. 2010 (CEST)

Baustein Überarbeiten

Hallo zusammen, kann den Baustein "Überarbeiten" nicht ganz nachvollziehen (im Gegensatz zu dem Baustein "Belege fehlen"). Könnte derjenige, der den Baustein eingefügt hat, sich nochmal hier melden, damit wir gemeinsam besprechen können, wie wir den Artikel in einen besseren Zustand überführen können? --Noresoft (Diskussion) 18:16, 21. Feb. 2017 (CET)

Ich hab ihn dann vorerst entfernt. Wenn die Notwendigkeit einer Bearbeitung noch besteht, bitte melden.

--Noresoft (Diskussion) 09:37, 1. Mär. 2017 (CET)

Die Typenbezeichnungen der Attribute sollten vor ihrer Verwendung erklärt werden

Der Artikel ist im Abschnitt LDAP-Verzeichnis schlecht geschrieben. Die Bezeichner wie bspw. ou und o werden 6 Abschnitte lang verwendet, bis sie dann erst im 7. Abschnitt nach deren ersten Erwähnung erstmals erklärt werden. Als Leser kann man so dem Artikel nur schwer folgen, weil einem gar nicht klar ist, was oe und o bedeuten soll. Die Erklärung wird erst weiter unten aufgeführt. --134.3.83.235 16:00, 28. Dez. 2018 (CET)

Im Abschnitt Protokoll sieht es nicht viel besser aus

Da steht bspw. "Mit der bind-Direktive vermittelt man dem Directory-Server über eine dn, wer den Zugriff durchführen möchte (entweder anonym, per Passwort-Authentifizierung oder anders) baseDN" Wofür steht denn dn? Was soll das sein? Etwa domain name? Bei gutem Deutsch werden Abkürzungen vor ihrer Verwendung erst einmal ausgeschrieben hingeschrieben, die bloße Verwendung von nicht geläufigen Abkürzungen und dn ist ganz gewiss keine geläufige Abkürzung, IP dagegen schon, ohne diese mindestens einmal am Anfang auszuschreiben ist Murks und wird einer Enzyklopädie nicht gerecht. --134.3.83.235 16:14, 28. Dez. 2018 (CET)