Printout Header
RSS Feed

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
RFC Standards
Das Kommunikationsmodell
Aufbau von LDAP-Paketen
LDAP Kommandos
Das Datenmodel des Verzeichnisses
Objektklassen und Attribute
Das RootDSE Objekt
Freie und kommerzielle LDAP Software

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.


LDAP Protocol Flow


Aufbau von LDAP-Paketen


Eine LDAP-Anfrage (hat folgenden Aufbau:


LDAP Frame

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.

Screenshot Wireshark LDAP

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 SearchRequest

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:

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

Microsoft Active Directory RootDSE Capabilities - Wie man die Version des Domänencontrollers am RootDSE-Eintrag erkennt

Microsoft Active Directory RootDSE Modify Operations - Wie man mit Schreib-Requests auf RootDSE spezielle Aktionen durchführt

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.



Tweet