LDAP - Das Lightweight Directory Access Protocol
Das LDAP Protokoll spielt im Zusammenhang mit ADSI eine große Rolle,
den bei ADSI handelt es sich eigentlich um nichts anderes als eine Schnittstelle
zur Benutzung von LDAP mittles selbst entwickelter Skripte oder Applikationen.
Dieser Abschnitt des SelfADSI Tutorials beschreibt das Lightweight Directory
Access Protocol (LDAP).
Folgende Abschnitte stehen zur Verfügung:
LDAP Historie und Standards
LDAP wurde ursprünglich im Zusammenhang mit der OSI-Recommendation X.500 für Verzeichnissysteme geschaffen. An X.500 lehnen sich die meisten der heute vorhandenen Verzeichnisdienste an. Die Entsprechnung für X.500 in der ISO-Standardisierungswelt lautet ISO/IEC-Standard 9594. Alle entsprechenden Dokumente stehen jedoch nicht online kostenlos zur Verfügung, sondern können z.B. im ITU Online Bookshop oder im ISO Online Store erworben werden.
Der X.500 Standard wurde von 1984 bis 1988 in seiner ursprünglichen Form definiert - es wird hier sowohl das Data Model, das Informational Model, das Functional Model, das Namespace Model als auch ein Authentication Framework für Verzeichnisdienste beschrieben. In diesem Zuge wurde auch ein Zugriffsprotokoll für Verzeichnisdienste spezifiziert: Das Directory Access Protocol (DAP). Es handelt sich hier um ein sehr komplexes Applikationsprotokoll, dass allen Anforderungen des OSI-Modells gerecht wird und außerdem ausschließlich auf den entsprechenden OSI-Transport-Protokollen aufsetzt - und nicht auf TCP/IP.
Zum Thema X.500 können Sie eines der maßgeblichen Bücher
zum Thema online zugreifen: Understanding
X.500 - The Directory von David Chadwick.
Auf Grund der großen Komplexität von X.500 und DAP wurde 1993
an der University of Michigan das Leightweight Directory Protocol entworfen
- trotz des Namens bietet es alle notwendigen Operationen für den
Zugriff auf einen Verzeichnisdienst. Außerdem setzt es auf TCP/IP
auf - dieser Umstand war für den Erfolg von LDAP fast noch wichtiger
als die übersichtlichere Protokollstruktur. LDAP war zuerst ein reines
Front-End für X.500 Server, es hat sich jedoch seit 1995 als eigenständiges
Verzeichnissystem etabliert. LDAP-Verzeichnisserver müssen nun nicht
unbedingt X.500 Server sein, verwenden jedoch die im X.500-Standard beschriebenen
Hierarchien und Namensgebungen.
Die LDAP Version 2 wurde dann 1995 als RFC
1777 von der IETF-Arbeitsgruppe (der "Access Searching
and Indexing of Directories ASID Working Group") verabschiedet. Unter
anderem wurde dort das Protokoll zum ersten Mal auf die Basis TCP/IP gesetzt.
Die heute aktuelle LDAP Version 3 wurde schließlich 1997 in RFC
2251 festgeschrieben. Hier kam vor allem eine Erweiterung
der Authentifizierung über LDAP hinzu (in Version 2 gab es nur anonyme
oder unverschlüsselte Anmeldungen), außerdem wurde durch die
Einführung von UTF-8 und Unicode die Formatierung der im Verzeichnis
enthaltenen Daten modernisiert.
RFC Standards
Allgemein spielen im Zusammenhang mit LDAP natürlich eine ganze
Reihe von RFC-Dokumenten eine Rolle (veraltete Standards oder Drafts sind
getrenntfarbig schwarz markiert, die Hauptstandards fett gedruckt):
| RFC 1484: Using the OSI Directory to achieve User Friendly Naming |
| RFC 1485: A String Representation of Distinguished Names |
| RFC 1487: X.500 Lightweight Directory Access Protocol |
| RFC 1488: The X.500 String Representation of Standard Attribute Syntaxes |
| RFC 1588: A String Representation of LDAP Search Filters |
| RFC 1777: Lightweight Directory Access Protocol (replaces 1487) [LDAP v2] |
| RFC 1778: The String Representation of Standard Attribute Syntaxes (replaces 1488) [for LDAP v2] |
| RFC 1779: A String Representation of Distinguished Names (replaces 1485) |
| RFC 1781: Using the OSI Directory to Achieve User Friendly Naming (replaces 1484) |
| RFC 1798: Connection-less Lightweight X.500 Directory Access Protocol |
| RFC 1823: The LDAP Application Program Interface |
| RFC 1959: An LDAP URL Format |
| RFC 1960: A String Representation of LDAP Search Filters (replaces RFC 1588) |
| RFC 2251: Lightweight Directory Access Protocol (v3) [LDAP v2] |
| RFC 2252: Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions |
| RFC 2253: Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names (replaces RFC 1779) |
| RFC 2254: The String Representation of LDAP Search Filters (replaces RFC 1960) |
| RFC 2255: The LDAP URL Format |
| RFC 2256: A Summary of the X.500(96) User Schema for use with LDAPv3 |
| RFC 2307: An Approach for Using LDAP as a Network Information Service |
| RFC 2559: Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 |
| RFC 2696: LDAP Control Extension for Simple Paged Results Manipulation |
| RFC 2820: Access Control Requirements for LDAP |
| RFC 2829: Authentication Methods for LDAP |
| RFC 2830: Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security |
| RFC 2849: The LDAP Data Interchange Format (LDIF) - Technical Specification |
| RFC 3377: Lightweight Directory Access Protocol (v3): Technical Specification (specifies the valid LDAP-RFCs) |
| RFC 3352: Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status (replaces RFC 1798) |
| RFC 3494: Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status (describes the outdated LDAPv2 RFCs) |
| RFC 3698: Lightweight Directory Access Protocol (LDAP): Additional Matching Rules |
| RFC 3771: The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message (extends RFC 2251) |
| RFC 4370 : Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control |
| RFC 4373 : Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) |
| RFC 4510 : Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map (specifies the valid LDAP-RFCs) |
| RFC 4511 : Lightweight Directory Access Protocol (LDAP): The Protocol (replaces 2251, 2830, 3771) |
| RFC 4512 : Lightweight Directory Access Protocol (LDAP): Directory Information Models (replaces RFC 2251, 2252, 2556, 3674) |
| RFC 4513 : Lightweight Directory Access Protocol (LDAP): Authentication Methods, Security Mechanisms (replaces RFC 2251, 2829, 2830) |
| RFC 4514 : Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names (replaces RFC 2253) |
| RFC 4515 : Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters (replaces RFC 2254) |
| RFC 4516 : Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator (replaces RFC 2255) |
| RFC 4517 : Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules (replaces RFC 2251, 2252, 3698) |
| RFC 4518 : Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation (replaces RFC 2251, 2830, 3771) |
| RFC 4519 : Lightweight Directory Access Protocol (LDAP): Schema for User Applications (replaces RFC 2256, 2247, 2798, 2377) |
| RFC 4520 : Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) |
| RFC 4521 : Considerations for Lightweight Directory Access Protocol (LDAP) Extensions |
| RFC 4522 : Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option |
| RFC 4523 : Lightweight Directory Access Protocol (LDAP): Schema Definitions for X.509 Certificates |
| RFC 4524 : COSINE LDAP/X.500 Schema |
| RFC 4525 : Lightweight Directory Access Protocol (LDAP): Modify-Increment Extension |
| RFC 4526 : Lightweight Directory Access Protocol (LDAP): Absolute True and False Filters |
| RFC 4527 : Lightweight Directory Access Protocol (LDAP): Read Entry Controls |
| RFC 4528 : Lightweight Directory Access Protocol (LDAP): Assertion Control |
| RFC 4529 : Requesting Attributes by Object Class in the Lightweight Directory Access Protocol |
| RFC 4530 : Lightweight Directory Access Protocol (LDAP): entryUUID Operational Attribute |
| RFC 4531 : Lightweight Directory Access Protocol (LDAP): Turn Operation |
| RFC 4532 : Lightweight Directory Access Protocol (LDAP): "Who am I?" |
| RFC 4533 : The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation |
Microsofts Ausführungen über die LDAP-Konformität von Active Directory.
Das Kommunikationsmodell
Innerhalb einer LDAP-Kommunikation stellt ein Client eine TCP-Verbindung
zu einem Verzeichnis-Server her. Der Server wird nach X.500-Gewohnheiten
auch als DSA (Directory Service Agent) bezeichnet. Es
gibt mittlerweile auch Implementationen eines verbindungslosen LDAP-Protokolls,
bei dem Anfragen direkt über UDP gesendet werden.
Typischerweise wird dabei der TCP/UDP Port 389 verwendet,
bei Verbindungen über SSL/TLS (Secure Socket Layer/Transport Level
Security) wird der Port 636 benutzt.
Der Server kann den Client an einen anderen Server verweisen. Diese Möglichkeit
des Referals wurde mit der LDAP-Version 3 eingeführt und erlaubt eine
Lastverteilung in großen Verzeichnissystemen, die von mehreren Servern
zur Verfügung gestellt werden.
Server können untereinander Ihre Verzeichnisse synchronisieren, hierfür
sind jedoch keine eigenständigen LDAP-Requests vorgesehen, vielmehr
können die Server dabei die normalen LDAP-Protokollkommandos verwenden
oder mit anderen Mechanismen ihre Datenbestände synchronisieren.
Während der Kommunikation übermittelt der Client einen oder mehrere Requests an
den Server, dieser beantwortet diese mit entsprechenden Response.
Diese Kommunikation muss nicht unbedingt streng synchron sein, d.h. der
Client kann mehrere Anfragen stellen, bevor der Server die erste beantwortet
hat, und der Server muss sich bei seinen Antworten nicht unbedingt an die
Reihenfolge der Requests halten. Eine einfache Anfrage des Clients kann
auch mit mehreren Response-Nachrichten des Servers beantwortet werden.
Aufbau von LDAP-Paketen
Eine LDAP-Anfrage (hat folgenden Aufbau:
Dabei ist wie in den RFCs die Definition der Inhalte einer LDAP-Message in der ASN.1 (Abstract Syntax Notation) ausgeführt (hier in verkürzter Form wiedergegeben). Die eigentliche konkrete Datenkodierung innerhalb der Netzwerkpakete geschieht über den Standard BER (Basic Encoding Rules). Dies ist anfangs nicht ganz übersichtlich, jedoch sind wichtige Teile der Daten (z.B. Objekt- und Attributnamen) in ASCII ausgeführt, so dass sie sich auch direkt im Hex-Code eines Paket-Sniffers identifizieren lassen.
Den genauen technischen Aufbau können Sie der Standard-Spezifikation in RFC 2251 entnehmen. Die einzelnen Kommandos werden weiter unten in diesem SelfADSI-Abschnitt erläutert. Ein einziges Beispiel für die genaue Analyse einer LDAP Message wollen wir jedoch anhand eines LDAP-Suchvorgangs unter die Lupe nehmen. Betrachten Sie dazu die Paket-Aufzeichnung einer LDAP-Session.
Die Dekodierung behauptet, bei dem betrachteten Paket handele es sich um eine LDAP-Suchanfrage für User-Objekte im gesamten Naming Context "dc=karakorum,dc=net". Zurückgegeben werden soll jeweils das Attribute displayName.
Schauen wir uns den Hexadezimal-Abschnitt der LDAP-Message (oben dunkel markiert) nochmals genauer an - und zwar zusammen mit der ASN.1-Definition einer LDAP-Search Operation. Um die genaue Kodierung zu verstehen, benötigen Sie unbedingt Kenntnisse in der Festlegungen der Basic Encoding Rules (BER). Bewegen Sie die Maus über die Werte, um genaue Erläuterungen zu bekommen:
LDAP Kommandos
Technisch gesehen würde man die verschiedenen LDAP-Kommandos auch
eher als Protokoll-Operationen betrachten. Eine dieser Operationen haben
wir im letzten Abschnitt genau untersucht. Eine genaue Betrachtung aller
Aspekte der LDAP-Kommandos finden Sie in RFC
2251.
| [0] Bind Request:...................... | Die Anmeldung eines Clients an einen LDAP-Server. Es
werden diverse Methoden für SASL-Authentifizierung (Simple Authentication
and Security Layer) unterstützt. Ebenso ist jedoch auch eine Klartext-Authentifizierung
denkbar - oder ein Anonymer Bind-Vorgang, bei dem überhaupt keine
Anmeldedaten übergeben werden. Wie man mit ADSI-Skripting ein
Bind ausführt, können Sie hier im SelfADSI-Tutorial im Abschnitt "Verbindung
mit dem Verzeichnis und Objekten herstellen"
lesen. In ADSI-Skripten wird ein BindRequest immer dann ausgelöst, wenn man Funktionen wie GetObject oder OpenDSObject verwendet bzw. wenn man eine ADO-Suche im Verzeichnis auslöst. |
| [1] Bind Response:................... | Die Antwort des LDAP-Servers auf einen BindRequest. |
| [2] UnBind Request:................. | Mit diesem Kommando beendet der Client die LDAP Protokoll-Session.
Dies wird vom Server NICHT beantwortet, sondern alle ausstehenden Requests
werden sofort verworfen und die Verbindung beendet. Ein ADSI-Skript
braucht diese Funktion nicht explizit auszuführen - die LDAP-Connection
wird nach Beendigung eines Scripts durch einen Timeout vom Server automatisch
abgebrochen. |
| [3] Search Request:................. | Dieses Kommando sucht ein oder mehrere Objekte im Verzeichnis - es
wird dabei eine Reihe von Attributen zurückgegeben, die der Client
bei der Suchanfrage übergeben kann. Als Kriterium für die Suche wird ein LDAP-Filter mit übergeben. Der Client kann ebenfalls den Verzeichnis-Container angeben, von dem aus die Suche beginnen soll: Die so genannte BaseDN. Außerdem kann durch einen Scope-Parameter festgelegt werden, ob die Suche sich auch auf vorhandene Sub-Container ausdehnen soll. In ADSI-Skripten wird diese Funktion z.B. bei ADO-Suchvorgängen verwendet - aber auch in Aufrufen der Methoden GetInfo und GetInfoEx. Auch hier wird intern einen LDAP-Bind verwendet, wobei als BaseDN das Objekt selbst angegeben wird und als Scope der Wert "baseObject", d.h. die "Suche" bezieht sich nur auf das betreffende Objekt. Zu Suchvorgängen in ADSI-Skripten lesen Sie die Anmerkungen im folgenden Abschnitt des SelfADSI-Tutorials: "Objekte im Verzeichnis suchen". |
| [4] Search ResultEntry:............ | Mit dieser Protokoll-Operation gibt der Server einen Treffer Eintrag
für einen SearchRequest zurück. Es können Sich in einem
Paket mehrere solcher Blöcke befinden, falls mehrere Objekte in
einer Suche als Treffer zurückgegeben werden sollen. Die Rückgabe
der Treffer kann allerdings auch in mehreren getrennten Netzwerkpaketen
erfolgen. |
| [5] Search ResultDone:............ | Als Abschluss der Antwort auf einen SearchRequest gibt der LDAP-Server
ene SearchResultDone zurück. Diese Antwort wird sofort zurückgegeben,
wenn eine Suche erfolglos oder fehlerhaft verlief. |
| [6] Modify Request:.................. | Dieses Kommando dient dazu, auf Attribute eines Objektes zuzugreifen.
Es gibt dazu die Möglichkeiten ADD, REPLACE und DELETE, wobei
sich diese Möglichkeiten nicht auf das gesamte Object, sondern
nur auf die Attribute darin beziehen. In ADSI-Scripts wird ein ModiyRequest verwendet, wenn man die Methode Put oder PutEx benutzt. |
| [7] Modify Response:............... | Die Antwort des LDAP-Servers auf einen ModifyRequest. |
| [8] Add Request:...................... | Hier kann ein Verzeichnisobjekt neu erzeugt werden. In ADSI-Scripts
wird ein AddRequest verwendet, wenn man die Methode Create bei
Container-Obekten aufruft. |
| [9] Add Response:.................... | Die Antwort des LDAP-Servers auf einen AddRequest. |
| [10] Del Request:..................... | Hier kann ein Verzeichnisobjet gelöscht werden. In ADSI-Scripts
wird ein AddRequest verwendet, wenn man die Methode Delete bei
Container-Objekten aufruft. |
| [11] Del Response:.................. | Die Antwort des LDAP-Servers auf einen DelRequest. |
| [12] ModifyDN Request:.......... | Dieses Kommando kann ein Objekt umbennenen - damit wird der Relative
Distinguished Name des Objekts im Verzeichnis geändert. Andererseits
kann hier auch der restliche Pfadname des Objekts geändert werden:
Das Objekt wird dadurch in einen anderen Container verschoben. In ADSI-Scripts wird diese LDAP-Operation verwendet, wenn man die Methode MoveHere aufruft. MoveHere ist übrigens von ADSI aus auch die einzige Möglichkeit, ein Objekt umzubenennen. |
| [13] ModifyDN Response:........ | Die Antwort des LDAP-Servers auf einen ModifyDNRequest. |
| [14] Compare Request:............ | Hier können Clients am Server überprüfen, ob Attribute
von Objekten bestimmte Werte haben. In ADSI wird diese LDAP-Operation
nicht direkt verwendet. |
| [15] Compare Response:......... | Die Antwort des LDAP-Servers auf einen CompareRequest. |
| [16] Abandon Request:............ | Mit diesem LDAP-Request kann der Client eine laufende Anfrage abbrechen.
Dies spielt vor allem bei umfangreichen oder komplexen Search-Requests
eine Rolle, die den Server unter Umständen stark belasten, deren
Ergebnisse aber vom Client unterdessen gar nicht mehr benötigt
werden. |
| [17] SearchResult Reference: | Eine spezielle Antwort eines LDAP-Servers auf eine Suchanfrage eines
Clients. Hierbei werden keine Ergebnisse direkt vom Server zurückgeliefert,
sondern der Server verweist auf andere LDAP-Server, die entsprechende
Verzeichnisobjekte oder -bereiche beherbergen und bei denen der Client
seine Suche fortsetzen kann. |
| [18] Extended Request:........... | Diese Art von Anfrage wurde im LDAP-Standard spezifiziert, um diversen
Implementierungen die Möglichkeit zu geben, eigene Funktionalitäten
hinzuzufügen, z.B. signierte LDAP-Anfragen. Die einzelnen Unterarten
des ExtendedRequests werden durch so genannte OBJECT IDENTIFIER OIDs
festgelegt. Diese Festlegung bleibt der jeweiligen Implementation als "Privatsache" überlassen. |
| [19] Extended Response:........ | Die Antwort des LDAP-Servers auf einen ExtendedRequest. |
| [20] Intermediate Response:.. | Dieser LDAP-Antworttyp wurde erst nach der eigentlichen LDAPv3-Definition
in RFC
3771 spezifiziert. Er legt die Möglichkeit fest, dass der
Server dem Client "vorläufige Antworten" zurückgeben
kann. Dies gilt vor allem für Anfragen des Clients, die vom Server
in mehreren Abschnitten bewältigt werden müssen, z.B. Löschen
von gesamten Sub-Strukturen im Verzeichnis oder das Anlegen und Synchronisieren
von neuen Replicas auf anderen Servern. Es gibt zwar im normalen Standard keine solchen Anfragen, es ist jedoch ohne weiteres möglich, dass durch die LDAP-Operation ExtendedRequest derartige Erweiterungen implementiert werden. Durch die IntermediateResponse kann diese Möglichkeit noch flexibler benutzt werden. |
Das Datenmodell des Verzeichnisses
LDAP-Server speichern Daten über Objekte in einer hierarchischen Baumstruktur, dem so genannten Directory Information Tree (DIT). Hierfür ist auch der Begriff "Naming Context" gebräuchlich. Der LDAP-Server selbst wird oft auch als DSA (Directory Services Agent) bezeichnet und kann auch mehrere DIT-Baumstrukturen / Naming Contexts beinhalten.
Eine LDAP-Hierarchie besteht aus Objekten, die jeweils 0 bis n untergeordnete Child-Objekte enthalten können. Jedes Child-Objekt besitzt jedoch genau ein einziges Parent-Objekt, kann also nicht in mehreren derartigen Containern enthalten sein. Eine Ausnahme bildet das Root-Objekt an der Spitze der Naming Context Hierarchie - es besitzt selbst kein übergeordnetes Objekt. Gebräuchliche Beispiele für normale Container-Objekte sind Organizational Units (OUs).
Jedes Objekt besitzt einen Namen, der innerhalb seines Containers eindeutig sein muss - dies ist der Relativ Distinguished Name (RDN). Wenn man nun die RDNs des Objektes und aller seiner obenliegenden Parent-Container-Objekte hinereinanderhängt, dann bekommt man eine eindeutige Kennung des Objektes innerhalb der LDAP-Hierarchie - dies ist dann der komplette Distinguished Name (DN) des Objektes. Ein Beispiel:
Genaue Erläuterungen zum Aufbau von LDAP-Pfadnamen lesen Sie die Erläuterungen im entsprechenden Abschnitt des SelfADSI Tutorials.
Objektklassen und Attribute
Die Objekte innerhalb einer LDAP-Hierarchie werden in Klassen eingeteilt. Jede Klasse wird durch einen Namen und eine Menge von Attributen definiert. Manche der Attribute müssen bei allen Objekten einer bestimmten Klasse zwingend vorhanden sein ("MUST"-Attribute). Andere Attribute sind optional - sie können bei den konkreten Objekten auch nicht gesetzt sein oder ganz fehlen ("MAY"-Attribute).
Die Definition der Klassen und Ihrer Attribute geschieht im Schema des Verzeichnisdienstes. Hier werden die Klassen wiederum nach einem hierarchischen System organisiert: Klassen können von anderen Klassen abstammen - Objekte übernehmen dann zusammen mit Ihrer tatsächlichen Klasse (der so genannten Structural Objectclass) auch die Attributeigenschaften der Oberklassen, von dem ihre eigene Klasse abstammt. Meist gibt es im Schema eines Verzeichnisdienstes eine abstrakte Objektklasse namens "top", von der alle anderen Klassen abstammen.
Das RootDSE Objekt
Bei RootDSE handelt es sich um einen Satz von Informationen, über die man allgemeine Eigenschaften eines LDAP-Servers abfragen kann. Man könnte auch sagen, dass es sich bei RootDSE um einen server-spezifischen Eintrag handelt, der an der Wurzel des Verzeichnisbaumes (DIT - Directory Information Tree) zur Verfügung steht, ohne selbst Teil eines Namenskontexts zu sein.
-
Technisch gesehen ist RootDSE ein Objekt, dass sich ohne weitere Angaben eines LDAP-Pfades direkt vom Server abrufen läßt:
rootDSE = GetObject("LDAP://server/rootDSE")
Über eine LDAP-Suchabfrage (z.B. über ADO) erhält man das RootDSE Objekt, wenn man bei der Suche eine leere Basis-DN ("") und dann folgenden LDAP-Suchfilter verwendet: "(objectClass=*)".
Diese Abfrage müsste an jedem LDAP-Server auch als anonymer LDAP-Benutzer möglich sein, wenn dieser Server LDAP v3 unterstützt. RootDSE wird dementsprechend als Standard-Attribut eines LDAP-Servers in RFC 2251 - Lightweight Directory Access Protocol (v3) festgelegt. Im LDAP-Standard werden für das RootDSE-Objekt insgesamt sieben Hauptattribute genannt, die ein LDAP-Server mindestens zurückgeben sollte:
- namingContexts
- subSchemaSubentry
- altServer
- supportedExtensions
- supportedControl
- supportedSASLMechanisms
- supportedLDAPVersion
Die verschiedenen LDAP-Server geben darüber hinaus typischerweise
eine Reihe von zusätzlichen Attributen zurück. Informieren Sie
sich in den Verweisen auf die entsprechenden Herstellerseiten:
Microsoft Active Directory RootDSE Attribute
Novell Edirectory RootDSE Attribute
Freie und kommerzielle LDAP-Software
Seit der Verbreitung von LDAP als Standard für Verzeichnissysteme und -zugriffe hat sich eine Menge an Software für LDAP-Client und LDAP-Server installiert. Man muss hier bei den Servern zwischen den folgenden Typen unterscheiden:
- Reine LDAP-Verzeichnisserver (z.B. OpenLDAP, Sun iPlanet / Sun Java Systems Directory Server, Siemens DirX)
- X.500 Server, die eine LDAP-Schnittstelle bieten (z.B. Isode M-Vault X.500)
- Diverse Applikationsserver, die eine LDAP-Schnittstelle bieten (z.B. Microsoft Active Directory , Novell eDirectory, IBM Lotus Domino)
- Datenbank-Server, die eine LDAP-Schnittstelle bieten (z.B. Oracle Internet Directory)
Eine sehr gute Übersicht zum Thema LDAP-Produkte finden Sie hier: Verzeichnisdienst.de - Die Webseite für Verzeichnisdienste.
