Lightweight Directory Access Protocol (Deutsch)

AddEdit

Die ADD operation fügt einen neuen Eintrag in der directory-server-Datenbank. Wenn der distinguished name in der Add-Anforderung bereits im Verzeichnis vorhanden ist, fügt der Server keinen doppelten Eintrag hinzu, sondern setzt den Ergebniscode im add result auf decimal 68, „entryAlreadyExists“.

  • LDAP-konforme Server dereferenzieren niemals den in der Add-Anforderung übertragenen Distinguished name, wenn Sie versuchen, den Eintrag zu lokalisieren, dh distinguished names werden niemals de-aliased.,
  • LDAP-konforme Server stellen sicher, dass der distinguished Name und alle Attribute den Benennungsstandards entsprechen.
  • Der hinzuzufügende Eintrag darf nicht vorhanden sein und der unmittelbare Vorgesetzte muss vorhanden sein.

Im obigen Beispiel darf uid=user,ou=people,dc=example,dc=com nicht vorhanden sein, und ou=people,dc=example,dc=com muss vorhanden sein.

Binden (authentifizieren)Bearbeiten

Wenn eine LDAP-Sitzung erstellt wird, dh wenn ein LDAP-Client eine Verbindung zum Server herstellt, wird der Authentifizierungsstatus der Sitzungist auf anonym gesetzt. Der Bindevorgang legt den Authentifizierungsstatus für eine Sitzung fest.,

Simple BIND und SASL PLAIN können den DN und das Passwort des Benutzers im Klartext senden, sodass die Verbindungen, die entweder Simple oder SASL PLAINshould verwenden, mit Transport Layer Security (TLS) verschlüsselt werden. Der Server überprüft normalerweise das Kennwort anhand des Attributs userPasswordim benannten Eintrag. Anonymous BIND (mit leerem DN und Passwort) setzt die Verbindung in den anonymen Zustand zurück.

SASL (Simple Authentication and Security Layer) BIND bietet Authentifizierungsdienste über eine Vielzahl von Mechanismen, z. B. Kerberos oder das mit TLS gesendete Clientzertifikat.,

BIND legt auch die LDAP-Protokollversion fest, indem eine Versionsnummer in Form einer Ganzzahl gesendet wird. Wenn der Client eine Version anfordert,die der Server nicht unterstützt, muss der Server den Ergebniscode in der Bindungsantwort auf den Code für einen Protokollfehler festlegen. Normalerweise sollten Clients LDAPv3 verwenden, das ist derdefault im Protokoll, aber nicht immer in LDAP-Bibliotheken.

BIND musste die erste Operation in einer Sitzung in LDAPv2 sein, ist aber ab LDAPv3 nicht erforderlich., In LDAPv3 ändert eachsuccessful BIND Request den Authentifizierungsstatus der Sitzung und jede erfolglose BIND Request setzt den Authentifizierungsstatus der Sitzung zurück.

DeleteEdit

Um einen Eintrag zu löschen, übermittelt ein LDAP-Client eine ordnungsgemäß ausgebildete Löschanforderung an den Server.,

  • Eine Löschanforderung muss den definierten Namen des zu löschenden Eintrags enthalten
  • Anforderungssteuerelemente können auch an die Löschanforderung angehängt werden
  • Server dereferenzieren keine Aliase bei der Verarbeitung einer Löschanforderung
  • Nur Blatteinträge (Einträge ohne Untergebene) können durch eine Löschanforderung gelöscht werden., Einige Server unterstützen ein Betriebsattribut hasSubordinates, dessen Wert angibt, ob ein Eintrag untergeordnete Einträge hat, und einige Server unterstützen ein Betriebsattribut numSubordinates, das die Anzahl der Einträge angibt, die dem Eintrag untergeordnet sind, der das Attribut numSubordinates enthält.
  • Einige Server unterstützen die Unterbaum-Löschanforderungssteuerung, die das Löschen des DN und aller dem DN untergeordneten Objekte ermöglicht, vorbehaltlich der Zugriffskontrollen., Löschanforderungen unterliegen Zugriffskontrollen, dh ob eine Verbindung mit einem bestimmten Authentifizierungsstatus einen bestimmten Eintrag löschen darf, wird durch serverspezifische Zugriffskontrollmechanismen geregelt.

Search and CompareEdit

Der Suchvorgang dient sowohl zum Suchen als auch zum Lesen von Einträgen. Seine Parameter sind:

baseObject Der Name des Basisobjekteintrags (oder möglicherweise des Stammeintrags) relativ zu dem die Suche durchgeführt werden soll. scope Welche Elemente unter dem baseObject gesucht werden sollen., Dies kannBaseObject(suchen Sie nur den benannten Eintrag, der normalerweise zum Lesen eines Eintrags verwendet wird),singleLevel(Einträge unmittelbar unter dem Basis-DN) oderwholeSubtree(der gesamte Teilbaum beginnend am Basis-DN) sein. filterkriterien, die bei der Auswahl von Elementen innerhalb des Gültigkeitsbereichs verwendet werden sollen., Beispielsweise wählt der Filter(&(objectClass=person)(|(givenName=John)(mail=john*)))„Personen“ (Elemente der objectClass ) aus, wobei die übereinstimmenden Regeln für undmailbestimmen, ob die Werte für diese Attribute mit der Filterassertion übereinstimmen. Beachten Sie, dass ein häufiges Missverständnis darin besteht, dass LDAP-Daten Groß-und Kleinschreibung berücksichtigen, während Übereinstimmungsregeln und Bestellregeln tatsächlich Übereinstimmungen, Vergleiche und relative Wertbeziehungen bestimmen., Wenn die Beispielfilter erforderlich waren, um dem Fall des Attributwerts zu entsprechen, muss ein erweiterbarer Übereinstimmungsfilter verwendet werden, z. B.(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))

derefAliases Ob und wie Aliaseinträge (Einträge, die sich auf andere Einträge beziehen), Attribute, die Attribute in Ergebniseinträgen zurückgeben. sizeLimit, TimeLimit Maximale Anzahl der zurückzugebenden Einträge und maximale Zeit, damit die Suche ausgeführt werden kann. Diese Werte können jedoch keine Einschränkungen überschreiben, die der Server hinsichtlich Größenlimit und Zeitlimit festlegt. typesOnly Gibt nur Attributtypen zurück, keine Attributwerte.,

Der Server gibt die übereinstimmenden Einträge und potenziell weiterführenden Referenzen zurück. Diese können in beliebiger Reihenfolge zurückgegeben werden. Das Endergebnis enthält den Ergebniscode.

Die Vergleichsoperation verwendet einen DN, einen Attributnamen und einen Attributwert und prüft, ob der benannte Eintrag dieses Attribut mit diesem Wert enthält.

ModifyEdit

Der MODIFY-Vorgang wird von LDAP-Clients verwendet, um vom LDAP-Server Änderungen an vorhandenen Einträgen anzufordern. Versuche, nicht vorhandene Einträge zu ändern, schlagen fehl. Änderungsanforderungen unterliegen Zugriffskontrollen, wie sie vom Server implementiert werden.,

Der MODIFY-Vorgang erfordert, dass der Distinguished Name (DN) des Eintrags und eine Folge von Änderungen angegeben werden. Jede Änderung in der Sequenz muss eine der folgenden sein:

  • add (fügen Sie einen neuen Wert hinzu, der nicht bereits im Attribut vorhanden sein darf)
  • delete (löschen Sie einen vorhandenen Wert)
  • replace (Ersetzen Sie einen vorhandenen Wert durch einen neuen Wert)

LDIF Beispiel für das Hinzufügen eines Werts zu einem Attribut:

dn: dc=example,dc=comchangetype: modifyadd: cncn: the-new-cn-value-to-be-added-

Um den Wert eines vorhandenen Attributs stichwort., Wenn das Attribut mehrwertig ist, muss der Client den Wert des zu aktualisierenden Attributs angeben.

Um ein Attribut aus einem Eintrag zu löschen, verwenden Sie das Schlüsselwort delete und den changetype designator modify. Wenn das Attribut mehrwertig ist, muss der Client den Wert des zu löschenden Attributs angeben.

Es gibt auch eine Modify-Increment-Erweiterung, mit der ein inkrementierbarer Attributwert um einen bestimmten Betrag erhöht werden kann., Das folgende Beispiel mit LDIF erhöht employeeNumber um 5:

dn: uid=user.0,ou=people,dc=example,dc=comchangetype: modifyincrement: employeeNumberemployeeNumber: 5-

Wenn sich LDAP-Server in einer replizierten Topologie befinden, sollten LDAP-Clients erwägen, das Post-Read-Steuerelement zum Überprüfen von Updates anstelle einer Suche nach einem Update zu verwenden. Das Post-Read-Steuerelement ist so konzipiert, dass Anwendungen nach einem Update keine Suchanfrage stellen müssen – es ist eine schlechte Form, einen Eintrag abzurufen, um zu überprüfen, ob ein Update aufgrund des Replikations-Konsistenzmodells funktioniert hat., Ein LDAP-Client sollte nicht davon ausgehen, dass er für jede Anforderung eine Verbindung zum selben Verzeichnisserver herstellt, da er möglicherweise Load-Balancer oder LDAP-Proxys oder beides zwischen LDAP-Clients und-Servern platziert hat.

DNEdit ändern

DN ändern (Eintrag verschieben / umbenennen) verwendet den neuen RDN (relativer Distinguished Name), optional den DN des neuen Elternteils und ein Flag, das angibt, ob die Werte im Eintrag gelöscht werden sollen, die mit dem alten RDN übereinstimmen. Der Server unterstützt möglicherweise das Umbenennen ganzer Verzeichnisunterbäume.,

Eine Aktualisierungsoperation ist atomar: Bei anderen Operationen wird entweder der neue oder der alte Eintrag angezeigt. Andererseits definiert LDAP keine Transaktionen mehrerer Operationen: Wenn Sie einen Eintrag lesen und dann ändern, hat ein anderer Client den Eintrag möglicherweise in der Zwischenzeit aktualisiert. Server können jedoch Erweiterungen implementieren, die dies unterstützen.

Erweiterte Operationedit

Die erweiterte Operation ist eine generische LDAP-Operation, die neue Operationen definieren kann, die nicht Teil der ursprünglichen Protokollspezifikation waren. StartTLS ist eine der wichtigsten Erweiterungen., Weitere Beispiele sind Cancel und Password Modify.

StartTLSEdit

Die Operation StartTLS stellt die Sicherheit der Transportschicht (der Nachkomme von SSL) für die Verbindung her. Es kann die Vertraulichkeit der Daten gewährleisten (um Daten vor der Einhaltung durch Dritte zu schützen) und/oder den Schutz der Datenintegrität (der die Daten vor Manipulationen schützt). Während der TLS-Verhandlung sendet der Server sein X. 509-Zertifikat, um seine Identität zu beweisen. Der Client kann auch ein Zertifikat senden, um seine Identität zu beweisen. Danach kann der Client SASL/EXTERNAL verwenden., Durch die Verwendung von SASL / EXTERNAL fordert der Client an, dass der Server seine Identität aus Anmeldeinformationen ableitet, die auf einer niedrigeren Ebene bereitgestellt werden (z. B. TLS). Obwohl der Server technisch gesehen alle Identitätsinformationen verwenden kann, die auf einer niedrigeren Ebene erstellt wurden, verwendet der Server normalerweise die Identitätsinformationen, die von TLS erstellt wurden.

Server unterstützen häufig auch das nicht standardmäßige“ LDAPS “ – Protokoll („Secure LDAP“, allgemein bekannt als“ LDAP over SSL“) an einem separaten Port, standardmäßig 636., LDAPS unterscheidet sich von LDAP auf zwei Arten: 1) Beim Herstellen einer Verbindung stellen Client und Server TLS her, bevor LDAP-Nachrichten übertragen werden (ohne StartTLS-Vorgang), und2) Die LDAPS-Verbindung muss beim Schließen von TLS geschlossen werden.

Einige“ LDAPS “ – Clientbibliotheken verschlüsseln nur die Kommunikation; Sie überprüfen den Hostnamen nicht anhand des Namens im bereitgestellten Zertifikat.

AbandonEdit

Der Abandon-Vorgang fordert an, dass der Server einen durch eine Nachrichten-ID benannten Vorgang abbricht. Der Server muss die Anforderung nicht erfüllen. Weder Abandon noch eine erfolgreich abgebrochene Operation senden eine Antwort., Eine ähnliche erweiterte Operation zum Abbrechen sendet Antworten, aber nicht alle Implementierungen unterstützen dies.

UnbindEdit

Der Unbind-Vorgang beendet alle ausstehenden Vorgänge und schließt die Verbindung. Es hat keine Antwort. Der Name ist historischen Ursprungs und nicht das Gegenteil der Bindeoperation.

Clients können eine Sitzung abbrechen, indem sie einfach die Verbindung schließen, aber sie sollten Unbind verwenden. Unbind ermöglicht es dem Server, die Verbindung ordnungsgemäß zu schließen und Ressourcen freizugeben, die er sonst für einige Zeit behalten würde, bis der Client die Verbindung aufgegeben hat., Außerdem wird der Server angewiesen, Vorgänge abzubrechen, die abgebrochen werden können, und keine Antworten für Vorgänge zu senden, die nicht abgebrochen werden können.

Share

Schreibe einen Kommentar

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