Diskussion:Lightweight Directory Access Protocol

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.

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!

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* 

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.

Weblink zeigt auf eine leere Seite, ändert sich das noch ? Ansonsten lösche ich den Link

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.

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

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.

• ist im Satz "unter ihm verzweigen sich die höheren Strukturen" nicht eine unlogik ? -- bluumi