Verzeichnisdienste
Von X.500 zu LDAP

von Peter Schober (Ausgabe 06/3, Oktober 2006)

 

Kasten: Neugierig?

Vernetzte Computersysteme sind ohne den Einsatz von Verzeichnisdiensten kaum mehr denkbar. Ob es um die Zustellung von eMail, den Status bzw. die Berechtigungen eines Accounts oder um die Information geht, von welchem Fileserver das Home-Verzeichnis geholt werden soll: Verzeichnisse versammeln für den Betrieb relevante Informationen in standardisierter, menschen- wie maschinenlesbarer Form und ermöglichen damit erst die großen und komplexen Netzwerke und Netzwerk-Anwendungen, auf die wir heute oft angewiesen sind.

Einer der wichtigsten Verzeichnisdienste ist LDAP, das Lightweight Directory Access Protocol. Neben diesem Beitrag zum Problemkontext und zur historischen Entwicklung werden sich künftige Comment-Artikel anhand des LDAP-Einsatzes an der Uni Wien auch mit praktischen Fragen beschäftigen.

Überall Verzeichnisse

Im Alltag pflegen wir einen ganz selbstverständlichen Umgang mit verschiedensten Verzeichnissen: gedruckte und elektronische Telefonbücher, Gebäudepläne (etwa um einen Hörsaal in einem Universitätsgebäude zu finden), Kataloge (z.B. gewisser schwedischer Möbelfabrikanten), TV-Programm-Guides oder das Vorlesungsverzeichnis der Universität Wien. Verzeichnisse helfen uns, Informationen zu verwalten und wieder zu finden. Im Idealfall vereinheitlichen sie versammelte Informationen aus verschiedenen Quellen und werden damit selbst zur maßgeblichen (autoritativen) Quelle für diese Daten.

Moderne vernetzte Computer sind ebenso von Verzeichnissen umgeben: Verzeichnisse gültiger User-Accounts, Gruppen von BenutzerInnen (etwa zur Rechteverwaltung), namentlich bekannte Maschinen im lokalen Netzwerk und weltweiten Internet, Services, die im Netzwerk zur Verfügung gestellt werden, usw. All diese Informationen wollen versammelt und mehr oder weniger ständig aktualisiert werden - auf jedem einzelnen Rechner, bei stetig zunehmender Zahl der vernetzten PCs. Daher entwickelte man spezialisierte Verzeichnisdienste (naming services), die diese Informationen zentral im Netzwerk zugänglich machen, sodass die Wartung auf den einzelnen Maschinen entfallen kann. Ein solcher Netzwerk-Verzeichnisdienst sind z.B. die Yellow Pages (in Analogie zu den Gelben Seiten, also dem Branchenverzeichnis), die später aus markenrechtlichen Gründen Network Information System (NIS) getauft wurden. Auch das Domain Name System (DNS), das im Internet die IP-Adressen in Hostnamen umsetzt (und umgekehrt), ist im Prinzip ein spezialisierter Verzeichnisdienst.

Der Einsatz von spezialisierten Verzeichnisdiensten führt aber in der Regel zum N+1 directory problem: Für jede zusätzliche Anwendung (z.B. ein zentrales eMail-Service, eine Groupware-Software oder ein webbasiertes Content Management System) muss ein weiteres, spezialisiertes Verzeichnis betrieben und verwaltet werden, was zu redundanten Daten und erschwerter Administration sowie in weiterer Folge zu höheren Betriebskosten und Sicherheitsproblemen führt. Ein möglicher Weg aus diesem Dilemma ist der Einsatz von standardbasierten, erweiterbaren Verzeichnisdiensten, die für den jeweiligen Zweck adaptiert werden können. X.5001) und heute LDAP sind Versuche in diese Richtung.

X.500

Mitte der 1980er Jahre trafen Bestrebungen zweier Normierungsorganisationen (ITU, ISO) aufeinander, die später zum ISO OSI Directory Standard (CCITT Recommendation X.500) führen sollten:

Das Comité Consultatif International Téléphonique et Télégraphique (CCITT, heute ITU-T) der Internationalen Fernmeldeunion (ITU) gibt technische Standards heraus, die in Kategorien von A bis Z sortiert und durchnummeriert werden. In der Kategorie X (Data networks and open system communications) finden sich die bis heute weiterentwickelten Bündel von Standards wie X.400 (Messaging systems) und eben X.500, das Online-Verzeichnisdienste standardisiert. Anliegen der CCITT war es nun, ein globales elektronisches Telefonverzeichnis zu schaffen, das gleichzeitig auch Faxnummern und eMail-Adressen2) beinhalten sollte: "If only we could computerise the entire set of global telephone directories, and interconnect them, and give people access to them all via a standard interface, then we would have a real directory service. X.500 of course is designed to provide this service, and many more besides." (Chadwick, 1996)

Ähnliche Bedürfnisse hatten die Internationale Organisation für Normung (ISO) und die private Normungsorganisation ECMA, die auf der Suche nach einem naming service für OSI-Netzwerke und -Anwendungen waren. X.500 und das dazugehörige Directory Access Protocol (DAP) wurden daher auf dem OSI-Stack realisiert, einem siebenschichtigen Netzwerkarchitekturmodell mit entsprechender Protokollimplementierung (dem stack), der von der ISO als Standard für interoperable, heterogene Computernetzwerke entwickelt wurde. Der OSI-Stack konnte sich jedoch letztlich nicht gegen das Internet-Protokoll TCP/IP behaupten: TCP/IP war einfacher, schneller und günstiger umzusetzen.

Neben der technischen Komponente ist hier auch ein kultureller Bruch erkennbar, wie technische Standards überhaupt zustande kommen sollen: Auf der einen Seite die als bürokratisch, langsam und politisch motiviert empfundenen Entscheidungsprozesse innerhalb der ISO, dem "Standards elephant". Dem gegenüber die TechnikerInnen und AkademikerInnen der IETF (des "Standards body" der Internet Community), die sich in konsensdemokratischen bzw. meritokratischen Prozessen schneller, flexibler und realitätsnäher fühlten: "We reject: kings, presidents, and voting. We believe in: rough consensus and running code.", wie David Clake 1992 auf einer Krisensitzung der IETF das Motto der Internet Community pointiert formulierte. Dieser Bruch3) ist heute weitgehend überwunden, was neben einer gewissen personellen Konvergenz der verschiedenen Standardisierungsgremien nicht zuletzt am durchschlagenden Erfolg des Internet liegt.

The Directory

Verzeichnisdienste nach X.500 waren groß und komplex angelegt, wie von den involvierten Gremien nicht anders zu erwarten. Eigentlich gab es in der Vision der EntwicklerInnen nur einen einzigen Verzeichnisdienst: The Directory - ein globales Verzeichnis mit u.a. diesen Eigenschaften:

  • Ein verteiltes System (was zum Teil Verfügbarkeit, Verlässlichkeit und Geschwindigkeit durch Lokalität mit sich bringt) mit verteilter Administration (denn die beste Information ist immer vor Ort verfügbar und sollte daher dort gepflegt werden);

  • general-purpose, d.h. für verschiedene Anwendungen geeignet und bereits erweiterbar konzipiert;

  • mächtige Suchfunktionen für verschiedene Arten von Abfragen;

  • basierend auf offenen, internationalen Standards, damit Interoperabilität (zwischen Systemen, Herstellern, Ländern etc.) gewährleistet ist.

Durch die Komplexität der Standards und Protokolle waren die ersten X.500-Implementierungen sehr fehlerbehaftet und wenig performant; echte Interoperabilität wurde erst spät erreicht. Auch waren die Datenquellen, aus denen sich ein Verzeichnisdienst möglichst automatisch speisen soll, oft von schlechter Qualität (das ist bis heute ein zentraler Problembereich), was die Attraktivität des Verzeichnisses natürlich schmälerte und dem weiten Einsatz des global directory nicht gerade zuträglich war. Die zunehmende Bedeutungslosigkeit des OSI-Modells gegenüber dem Internet trug ebenfalls dazu bei, die Entwicklung der X.500-Services zu bremsen.

LDAP

Da Internet-basierte Klientenprogramme für die Nutzung des Verzeichnisses leichter zu realisieren waren, wurden bald TCP/IP-Gateways entwickelt (DAS, DIXIE), die Anfragen der IP-Klienten übersetzten und via DAP/OSI an X.500-Server weiterleiteten. Beide Projekte sind heute obsolet; ihr Erfolg bestand aber darin, erstmals die große Nützlichkeit eines IP-Zugriffs auf Verzeichnisse gezeigt zu haben.

Um die Verwendung von X.500-Verzeichnissen zu fördern (nicht etwa, um diese abzulösen), wurde schließlich von der IETF das IP-basierte Lightweight Directory Access Protocol (LDAP) spezifiziert und - aufbauend auf den Erfahrungen der vorangegangenen Projekte - ein Gateway von LDAP zu DAP an der University of Michigan entwickelt. Der längere Einsatz dieses so genannten ldapd (LDAP daemon) zeigte jedoch, dass Mitte der 1990er Jahre über 99% der Zugriffe auf den Verzeichnisdienst via LDAP (also über das Gateway) statt direkt über DAP erfolgten. Etwa zur gleichen Zeit stellte sich auch die Erkenntnis ein, dass es mit dem global interconnected X.500 directory wohl nichts mehr wird, womit die X.500-Services als Ganzes in Frage gestellt wurden.

In der Folge ersetzte der slapd (standalone LDAP daemon) den ldapd, es gab also kein dahinterliegendes X.500-Verzeichnis mehr, an das lediglich Anfragen weitergeleitet wurden. LDAP war damit von X.500 losgelöst und wurde mit kleinen Erweiterungen und einigem Straffen (etwa der Reduktion auf nur neun Funktionen bei gleichzeitigem Erhalt zukünftiger Erweiterbarkeit ohne Änderungen am Protokoll) als Grundlage eines kompletten Verzeichnisdienstes neu definiert. Die aktuelle Version des Standards heißt LDAPv3 (siehe LDAP Technical Specification) und zeichnet sich u.a. durch folgende Eigenschaften aus:

  • Durch volle Unicode-Unterstützung in UTF-8-Kodierung4) können theoretisch sämtliche Zeichen sämtlicher Sprachen verarbeitet werden, es lassen sich aber auch ASCII- oder Binärdaten speichern.

  • Mittels Verkettung (chaining), Verweisen (referrals), Zusammenkleben (glueing) oder Replikation können auch mit dem slapd aus mehreren LDAP-Servern vernetzte Systeme aufgebaut werden. Teile der Komplexität von X.500 kommen also in kleinen Dosen wieder, allerdings optional.

  • Die Nutzung von TLS (Transport Layer Security, bekannter als SSL) und SASL (dem geradezu irrwitzig unpassend benannten Simple [!] Authentication and Security Layer) ermöglicht sichere Authentifizierung und Datenübertragung, ist modular und vom LDAP-Protokoll unabhängig. Sowohl TLS als auch SASL werden von vielen anderen Technologien, Protokollen und Projekten verwendet, was z.B. die einfache und sichere Authentifizierung mit SMTP AUTH oder IMAP/POP über einen LDAPv3-Verzeichnisdienst ermöglicht.

  • So genannte extended operations und controls können zusätzliche Funktionalität bieten oder bestehende Funktionen modifizieren, ohne das Protokoll selbst verändern zu müssen (z.B. zum Ändern des eigenen Passworts).

  • Diese Erweiterungen - wie auch andere Funktionen oder unterstützte Standard-Datentypen des Servers - kann dieser ankündigen und Klienten können diese selbständig "entdecken", ähnlich der capabilities-Funktion von IMAP, wo Mailklienten (z.B. Mozilla Thunderbird) im "Gespräch" mit dem IMAP-Server dessen unterstützte Funktionen und Erweiterungen abfragen, um sich entsprechend darauf einzustellen (z.B. Kann StartTLS benutzt werden, um die Verbindung zu verschlüsseln? Welche SASL-Mechanismen werden zur Authentifizierung angeboten?).

Neben proprietären Angeboten von Novell, Sun, Oracle, IBM, Microsoft u.a. gibt es heute mittlerweile auch drei größere Open Source-Implementierungen des LDAP-Service: OpenLDAP, Fedora Directory Server (früher Netscape DS) und neuerdings Sun OpenDS5). Weiters existieren kommerzielle Varianten dieser Open Source-Implementierungen, z.B. die OpenLDAP-Distribution Connexitor von Symas oder Apples Open Directory, das auf OpenLDAP und MIT-Kerberos aufbaut.

Diese Unterstützung durch alle relevanten Hersteller, Systeme, Plattformen und Programmiersprachen sowie die freie Verfügbarkeit von hochqualitativer, standardkonformer Software (von Apache bis Zope) sind wichtige Gründe für den immer noch zunehmenden Einsatz von LDAP-Verzeichnissen in Unternehmen und im Internet. Auch an der Universität Wien wird LDAP als wichtige Infrastruktur-Komponente auf- und ausgebaut; zwei Anwendungsmöglichkeiten sind im Artikel Wie sag ich's meinem LDAP-Server? beschrieben. 

Neugierig?

Über die Struktur von LDAP-Verzeichnissen, über Klientenprogramme und Abfragemethoden soll in der nächsten Ausgabe des Comment berichtet werden. Wer nicht so lange warten bzw. es ganz genau wissen will, sei auf die folgende Literatur verwiesen:

LDAP


X.500


ISO vs. Internet

1) Hintergrundinformationen zu X.500: In der englischen Wikipedia finden Sie u.a. Erläuterungen zu folgenden Begriffen und Abkürzungen: CCITT, ITU, ITU-T, ISO, X.400, X.500, ECMA, OSI, Whois, TCP/IP, IETF, RFC, DAS (RFC 1202) und DIXIE (RFC 1249).

2) Die rasche Verbreitung von eMail erschien diesbezüglich besonders problematisch, da es für Mailadressen im Gegensatz zu Telefonnummern keine etablierten (z.B. gedruckten) Verzeichnisse gab: Um mit jemandem per eMail in Kontakt zu treten, musste die Mailadresse oft erst telefonisch erfragt werden.

3) Näheres dazu siehe z.B. www.alvestrand.no/x400/debate/itu-vs-ietf.html

4) siehe Artikel Unicode: Kiss Your ASCII Goodbye? in Comment 04/3

5) Sun OpenDS ist komplett in der Programmiersprache Java geschrieben und nicht zu verwechseln mit dem immer noch proprietären Sun Java System Directory Server, der verwirrenderweise nicht in Java geschrieben ist.