Verzeichnisdienst LDAP/OpenLDAP. Stefan Drzazga 02INF

Transkript

1 Verzeichnisdienst LDAP/OpenLDAP Stefan Drzazga 02INF

2 Inhaltsverzeichnis 1 Der Verzeichnisdienst Objektorientierte Strukturen Der Weg zu LDAP LDAP im Einsatz Die Administration in Netzwerken mit LDAP 8 2 Grundlagen X Objekte Attribute Verzeichniseinträge Vererbung Polymorphismus in Klassen Standardisierung von Attributen und Objektklassen Objektklassentypen Verzeichnisbaum Aliase Referenzierung durch Namen Relative Distinguished Name Zusammengesetzter RDN Überführung RDN zu DN 19 3 Die LDAP Sitzung Messages und Operationen 20 4 Die Verteilung des Verzeichnisses Naming Context Referrals und Continuations 23 5 Sicherheit Zugriffskontrolle im LDAP Authentifizierung Der Strong Bind 27 6 Schema Klassen unter LDAP Allgemeiner Aufbau eines Schemas Eigene Schemata entwerfen Referenzierung von Objekten durch Name oder OID Der Object Identifyer (OID) AttributeTypes ObjectClasses 32 7 Das LDIF Die Anweisungen Versionsnummer Datensatz 35 8 Ein Blick in die Zukunft 36 Literaturverzeichnis 38 2

3 1 Der Verzeichnisdienst Für was und und warum brauchen wir eigentlich Verzeichnisdienste, wo wir doch die große Auswahl zwischen relationalen Datenbanken, Textdateien oder andere Möglichkeiten für die Haltung unserer Daten haben? Dabei liegen die wesentlichen Vorteile auf der Hand: auf Verzeichnisse wird meist meistens eher lesend als scheibend zugegriffen, ein Verzeichnis organisiert seine Daten in einer baumartigen Hierarchie, dem Verzeichnisbaum, die Teilbäume des Verzeichnisbaums können auf unterschiedliche Hosts verteilt sein, Teilbereichen des Verzeichnisbaums können durch Delegation einfach administriert werden, durch den Verzeichnisbaum wird es ermöglicht, das Suchen von vornherein auf interessante Teilbäume zu beschränken, viele Verzeichnisdienste basieren auf dem X.500-Modell und unterstützen damit von vornherein ein objektorientiertes Datenmodell Ein einfaches Beispiel für die Anwendung eines Verzeichnisses stellt das Domain Name System dar. Selbst wenn man sich darauf beschränkt, das DNS nur als ein System zur Abbildung von menschenlesbaren Zonennamen wie,, auf IPv4- Adressen wie,, wahrzunehmen, dann erkennt man, dass zur Bewältigung dieser Aufgabe ein System mit verteilter Datenhaltung und Administration notwendig ist. Man erkennt auch, wie die oben aufgelisteten Vorzüge von Verzeichnisdiensten im Jahre 1984 gefällte Entscheidung beeinflussten, zur Verwaltung der Zonennamen in Zukunft einen Verzeichnisdienst zu verwenden. Ein deutlicher Anwendungsfall für Verzeichnisse ist die Abbildung von Organisationen. Die Tatsache, dass Organisationen dazu neigen, hierarchisch aufgebaut zu sein, harmonisiert mit dem hierarchischen Aufbau eines Verzeichnisbaumes. In diesem Zusammenhang erweist sich auch die Option, die Verwaltung von Teilbäumen nach unten zu delegieren als vorteilhaft: In einem Konzern können kleinere Organisationseinheiten, z.b. die Niederlassungen einzelner Teilfirmen, ihre eigenen Verzeichnisse aufbauen; Teilfirmen können die Verzeichnisse ihrer einzelnen Niederlassungen oder Abteilungen zusammenfassen und die Verzeichnisse der 3

4 Teilfirmen werden auf der Ebene des Konzerns gemeinsam erfasst, so dass man ganz oben den vollen Überblick hat. Die Administration eines solchen organisationsorientierten Verzeichnisses kann bis zur Ebene der einzelnen Benutzer herunter delegiert werden: Adressverzeichnisse, in denen die Benutzer ihre eigenen Adressbucheinträge unter Benutzung eines Web-Frontends selber verwalten sind ein Beispiel für diese Art der Delegation(User Based Administration). 1.1 Objektorientierte Strukturen Aber welche Daten sollte eine Firma überhaupt in einem Verzeichnis erfassen wollen? Sehr oft werden zum Beispiel die Daten der Angestellten einer Firma erfasst. Diese Datensätze können Dinge wie Namen, Adressen, Telefonnummern, -Adressen oder Ähnliches enthalten. In einer Tabelle muss für jedes Element des Datensatzes eine Tabellenspalte vorgesehen sein. Bei Verzeichnisdiensten, die dem X.500-Standard entsprechen, verwendet man stattdessen so genannte Objektklassen, um die Struktur der Datensätze zu beschreiben. Was geschieht nun, wenn es notwendig wird, die Personendatensätze um eine neue Komponente zu erweitern? Es wird zum Beispiel in der Praxis oft nötig, die Verwaltung von -Adressen oder kryptographischen Schlüsseln nachträglich in Verzeichnisse zu integrieren. Während eine solche Änderung bei einer relationalen Datenbank entweder die Erweiterung oder das Neuanlegen einer Tabelle erfordert beides Änderungen, die zentral erfolgen müssen ; kann man bei einem X.500-kompatiblen Verzeichnis durch Vererbung eine neue Objektklasse erzeugen, die eine vorhandene Klasse um das entsprechende Feld erweitert. Diese Veränderung des Verzeichnisses kann auch auf einer niedrigen administrativen Ebene erfolgen, was es ermöglicht, Verzeichnisse ohne zentrale Eingriffe flexibel an die Erfordernisse niedriger Hierarchieebenen anzupassen. 1.2 Der Weg zu LDAP Mit den X.500-Standards und LDAP haben sich zwei Arten von Spezifikationen für Verzeichnisdienste etabliert, die in einer sehr engen Beziehung zueinander stehen. Dies hat vor allem historische Gründe, die bis auf das frühe PC- und Client/Server-Zeitalter zurückgehen. In dieser Frühzeit vor und bis etwa zum Jahr 1985 existierten in den typischen Firmennetzen allerlei historisch gewachsenen Systemarchitekturen nebeneinander her. Der Datenaustausch zwischen verschiedenen Systemen gestaltete sich aber meist schwierig oder 4

5 war mitunter unmöglich, da es entweder keine oder nur sehr schlechte Schnittstellen zwischen den verschiedenen Systemen gab. Mit der fortschreitenden Computerisierung der Arbeitsplätze verstärkte sich aber das Bedürfnis, Daten auch zwischen verschiedenen Systemen austauschen zu können. Typischerweise wollte man mit dem MAC, PC oder Amiga am Arbeitsplatz auf einen Unix-Server bzw. eine Mainframe im Hintergrund zugreifen. Bei der Entwicklung von Interfaces, die ad hoc zwei Architekturen miteinander verbanden, geriet man schnell in ein Dilemma. Dieser Ansatz hat nämlich einen entscheidenden Nachteil:Der Aufwand wuchs quadratisch mit der Anzahl der zu verbindenden Systeme. Erschwerend kam hinzu, dass man zur Implementation eines Interfaces zwischen System A und System B Kenntnisse der Systeme A und B haben musste. Die langfristig bessere Alternative zum oben beschriebenen Interfacemodell stellt das Schichtenmodell dar. Dabei wird ein zentrales Kommunikationsprotokoll definiert, so dass auf jedem der zu verbindenden Systeme nur eine Schnittstelle zu diesem zentralen Protokoll implementiert werden muss. Bekanntlich setzte sich im Laufe der 80er Jahre die Erkenntnis durch, dass der bessere Weg zur gewünschten Interoperabilität ein solches gemeinsames Kommunikationsprotokoll zum Datenaustausch ist. Aus der Sicht dieser Zeit boten sich zwei Möglichkeiten an, um zu einer solchen universellen Kommunikationsschicht zu kommen: 1. Der komplette Neuentwurf einer solchen Schicht. 2. Die Adaption der TCP/IP-Protokollfamilie. Der Aufgabe des universellen Neuentwurfes widmete sich die CCITT(Comité consultatif international télégraphique et téléphonique), eine Unterorganisation der Vereinten Nationen mit Sitz in Genf, die später zur International Telecommunication Union (ITU) mutierte. Die ITU produzierte im Laufe der Jahre zahlreiche Standards, die als X-Serien bekannt sind, da sie Kurzbezeichnungen haben, die mit einem großen X beginnen(z.b. X.200, das ISO/OSI- Modell). Auch für Verzeichnisdienste existieren eine Reihe von X Standards: die X.500 Serien. Diese X.500-Standards definieren, wie Verzeichnisdaten zur Verfügung gestellt und abgerufen werden sollen, wie Verschlüsselung,Authentifizierung, Replikation und Verwaltung der Verzeichnisdaten gehandhabt werden, und zu guter letzt liefern sie die funktionalen Modelle und den Begriffsapparat auch für solche Verzeichnisdienste, die nicht mehr vollkommen auf dem X.500-Standard beruhen, namentlich für LDAP. X.500 definiert zwei Subprotokolle namens DSP und DAP. Ersteres steht für Directory System Protocol, letzteres bedeutet Directory Access Protocol. Während das DSP zur 5

6 Kommunikation der Server untereinander gedacht ist, soll das DAP zur Interaktion zwischen Benutzerprozess und Serverprozess dienen. (In der X.500-Terminologie wird die Clientanwendung als Directory User Agent, kurz DUA, die Serveranwendung Directory Server Agent oder kurz DSA genannt). Das DAP erwies sich aber in gewisser Weise als Hemmschuh für die weitere Verbreitung von X.500-basierten Directory Services. Während nämlich die X.500-Standards auf dem komplizierten 7-schichtigen OSI Modell basieren, setzte sich in der Praxis das einfachere TCP/IP-Modell als Standard für die Vernetzung unterschiedlicher Systeme durch. Ab Mitte der 90er Jahre wurden immer mehr lokale Netze mittels der Protokolle aus dem TCP/IP- Modell zu Intranets verbunden oder an das Internet angeschlossen. Mit dieser Entwicklung hin zu großen, potenziell unübersichtlichen Netzen tat sich für Verzeichnisdienste eine Fülle von neuen Einsatzmöglichkeiten bei der Verwaltung solcher Netze auf. Die Entwicklung von Clients wurde aber durch die Komplexität des DAP- Protokolls erschwert: DAP setzt auf der Transportschicht des ISO Protokollstacks, und nicht auf dem verbreiteten TCP auf. Ein OSI Protokollstack war in den Desktop-Betriebssystemen nicht implementiert und hätte wahrscheinlich auch die damalige Hardware völlig überfordert. Ein TCP/IP-Stack konnte hingegen selbst bei den 16-bittigen DOS/Windows-Versionen nachgerüstet werden. Heute findet man IP Stacks auch schon in Telefonen und Spielkonsolen. Als Ausweg aus dem DAP-Dilemma wurde im Juli 1993 im RFC 1487 das Lightweight Directory Access Protocol spezifiziert. Die Essentials beim Entwurf dieses Protokolls waren: 1. Das LDAP sollte eine wesentliche Teilmenge des DAP-Protokolls implementieren. 2. Das LDAP sollte direkt auf der TCP-Schicht aufsetzen, damit der OSI-Overhead entfallen konnte. Ebenfalls im Juli 1993 wurde von den Autoren des RFC 1473 an der University of Michigan (UMich) die erste LDAP-Implementation ldapd vorgestellt. Eine überarbeitete LDAP-Version LDAPv2 wurde im Jahr 1995 vorgestellt und in den ldapd implementiert. LDAPv2 ist nach wie vor weit verbreitet und wird nur langsam durch LDAPv3 verdrängt. Ein weiteres Update der LDAP-Spezifikation erfolgte 1997 mit RFC 2251, der die dritte Version des LDAP (LDAPv3) spezifiziert. 6

7 Seit August 1998 wird das LDAP-Projekt der UMich unter dem Namen OpenLDAP von einer eigens gegründeten Non-Profit-Organisation, der OpenLDAP Foundation koordiniert. 1.3 LDAP im Einsatz Die ursprüngliche Idee hinter LDAP war, dass dieses Protokoll serverseitig durch eine Middleware implementiert werden sollte, die per LDAP mit den Clients und über die X.500-Protokolle mit einem oder mehreren X.500-DSP(s) kommuniziert. Abbildung XX zeigt diesen typischen Anwendungsfall. Für den wachsenden Erfolg von LDAP ist aber auch ein Paradigmenwechsel mitverantwortlich, durch den sich die Einsatzgebiete dieses Protokolls verlagern, und zwar weg von einer Middleware, die zwischen TCP/IP und X.500 vermittelt, hin zu einer Serversoftware die LDAP-fähigen Clients den Zugriff auf eine fast beliebige Datenbasis vermittelt. OpenLDAP enthält einen slapd genannten Standalone LDAP Daemon, mit dem man auf verschiedene Backends zugreifen kann. Trotz der partiellen Abkehr von der X.500-Datenhaltung kann LDAP aber seine Wurzeln nicht verleugnen, denn wie auch immer das Backend geartet ist, die Grundlage für das zugrunde liegende Datenmodell, basiert nach wie vor auf den X.500-Standards. Die aktuelle LDAP-Version ist LDAP Version 3, kurz LDAPv3 genannt. LDAPv3 ergänzt die Version 2 in vielerlei Hinsicht. Neuheiten umfassen u.a: starke Authentifizierung durch SASL, optionaler Integritätsschutz und Verschlüsselung durch das auf SSL basierende TLS-Protokoll, Internationalisierung durch Unicode, Verweise auf andere LDAP-Server, so genannte Referrals und Continuations, Veröffentlichung der Datendefinition durch den Server (Schema Discovery). Die Kernbestandteile von LDAPv3 werden in einer Reihe von RFCs, den so genannten LDAPv3 Core Specifications beschrieben. Der Name Core Specs lässt bereits ahnen, dass auf der Grundlage dieser Spezifikationen weitere Spezifikationen entstanden sind. Die Internet Engineering Task Force (IETF) hat dazu eine Expertengruppe, die LDAP Extension Working Group eingerichtet. Die Intension dieser Gruppe ist es u.a. sich mit den Themen: Authentifizierung und 7

8 Verschlüsselung, Verarbeitung von Suchergebnissen, dynamische Verzeichnisse und Standardisierung von APIs für die Cliententwicklung auseinander zu setzen. 1.4 Die Administration in Netzwerken mit LDAP Obwohl man mit Verzeichnisdiensten und deren unaufwändigster Variante LDAP vom Kaufhauskatalog bis zum weltweiten Telefonbuch allerlei schöne Dinge realisieren kann, ist es der Einsatz von LDAP zur Verwaltung von Netzwerkinformation, der ein starkes Interesse an LDAP auslöst. LDAP ist in die Verzeichnisdienste NDS (Novell) und ADS (Microsoft) integriert und erlaubt es endlich, Benutzerinformationen für heterogene Netzwerke zentral zu verwalten. Im Idealfall hat der Anwender mit einem Username und Passwort Zugriff auf alle Informationen im Netz und der Administrator seine Ruhe, da er sich nicht mehr um die Benutzerverwaltungen kümmern muss. RFC 2307 beschäftigt sich schon mit der zentralen Verwaltung weiterer Netzwerkinformation mittels LDAP: Benutzer und Gruppen (/etc/passwd, etc/groups), IP-Dienste (Zuordnung zwischen Diensten, Portnummern), IP-Protokolle (/etc/protocols), RPCs (Zuordnung von Remote-Procedure-Call-Nummern zu RPC-Diensten wie in /etc/rpc), NIS-Informationen, Boot-Informationen (MAC-Adressen und Boot-Parameter), Mountpoints für Dateisysteme (/etc/fstab), Mail-Aliase. 8

9 2 Grundlagen X.500 Die Welt der X.500 Protokolle und das davon abgeleitete LDAP besteht aus,,objekten. Wer Vorkenntnissen in objektorientiertem Design hat wird feststellen, dass wesentliche OO- Konzepte wie,,objekte,,,klassen,,,vererbung,,,polymorphie und deren intensive Wiederverwertung in der Welt des X.500 wichtige eine Rolle spielen, wenn auch manchmal unter verändertem Namen. Die Aufgabe des Verzeichnisses ist es, die Objekte abzubilden und miteinander in Beziehung zu setzen. Ein Objekt wird im Verzeichnis durch einen Verzeichniseintrag repräsentiert. Der Verzeichniseintrag besteht im Wesentlichen aus einer Liste von Eigenschaften des Objektes, den so genannten Attributen, sowie aus einem Namen, dem Distinguished Name. Wie der Name einer Datei im Dateisystem oder der Name einer Zone im DNS wird der Distinguished Name in einen hierarchischen Namensraum eingeordnet. Auf diese Weise entsteht eine Baumstruktur, in der die Einträge angeordnet sind, der Directory Information Tree. Abbildung 1 zeigt einen Ausschnitt aus den Organisationsverzeichnis der Firma MySQL AB, die aus einem Mitarbeiter und aus einem Notebook besteht. Organisation O: MySQL AB L: Hamburg DESC: MySQL Niederlassung Deutschland Person cn: Michael Monty Widenius telephonenumber: Abbildung 1 - DIT der Firma MySQL Device cn: MyNotebook serialnumber: Im Verzeichnis der MySQL AB finden wir alle Elemente eines Verzeichnisses wieder: einen Verzeichnisbaum, der die Firma in der Hierarchie höher ansiedelt als beispielsweise den Mitarbeiter oder den Notebook, Einträge für die Firma, den Mitarbeiter und den Notebook, viele Attribute: O, L und DESC für die Firma, 9

10 CN und telephonenumber für den Mitarbeiter, CN und serialnumber für das Notebook. Man kann an diesem Beispiel auch erkennen, dass Einträge und Attribute einer Standardisierung unterliegen: Einträge gehören zu bestimmten Objektklassen, die die Attribute des Eintrages vorschreiben. Hier sind das die Objektklassen Organisation, Person und Device für die Firma, den Mitarbeiter und das Notebook. Auch die hier verwendeten Attribute sind standardisiert. Dies merkt u.a. daran, dass die Namen der meist verwendeten Attribute bis zur Unkenntlichkeit abgekürzt sind, zum anderen sieht man, dass das Attribut cn sowohl beim Mitarbeiter (Person) als auch beim Notebook (Device) vorkommt. Die Bedeutung der nicht offensichtlichen Attributnamen ist die folgende: O: Organisation, der Name einer Organisation. L: Location, ein geographischer Ort. DESC: Description, menschenlesbare Beschreibung. CN: Common Name, der Name, unter dem das Objekt gewöhnlich angesprochen wird. 2.1 Objekte Was ist ein Objekt? Diese Frage kann an dieser Stelle gar nicht wirklich beantwortet werden, denn die Objekte der realen Welt sind etwas Vorgegebenes, etwas, das man zu akzeptieren und mit dem man zu arbeiten hat. Trotzdem ist eine wichtige Eigenschaft die folgende: Ein Objekt verfügt über einen Menge von Eigenschaften (Attribute). Ein besonderes Attribut ist der Name des Objektes. Natürlich hat ein Objekt in der realen Welt, wie z.b. ein Mensch, eine große Zahl von Eigenschaften. Dies ist aber für die maschinelle Verwaltung von Objekten von geringer Bedeutung, da es üblicherweise nur wenige standardisierte Attribute sind, die an einem Objekt interessieren. Für die Postzustellung ist es eher uninteressant, ob ein Mensch eine besondere musikalische Begabung hat, hier interessieren lediglich der Name und die Anschrift. Man fasst daher Objekte zu Objektklassen (engl.: object classes) zusammen. Eine solche Objektklasse besteht aus einem Satz von notwendigen und/oder optionalen Attributen, mit denen sich ein Objekt dieser Klasse beschreiben lässt. Für die Postzustellung könnte dies z.b. die standardisierte Objektklasse residential Person sein. 10

11 2.2 Attribute Verglichen mit den Feldern eines Datensatzes im relationalen Modell sind die Attribute des X.500-Modells recht komplexe Objekte. Ein Attribut besteht aus: einem Namen, mit dem das Attribut innerhalb des Objektes eindeutig referenziert werden kann, keinem, genau einem oder einer Liste von Attributsausprägungen. Um die Wiederverwendung von Attributen in verschiedenen Objektklassen zu unterstützen, werden Attribute getrennt von den Objekten definiert, und zwar in Form von Attributtypen (engl. Attribute Type). Der Attributtyp enthält die folgenden Komponenten: Den Namen und/oder die OID, die den Attributtyp eindeutig bestimmt. Optional eine menschenlesbare Beschreibung (Description). Optional Definitionen darüber, welche Regeln für Gleichheit (EQUALITY), Treffer von Teilzeichenketten (SUBSTR) und die lexikalische Anordnung (ORDERING) dieses Attributes gelten sollen. Eine Syntaxbeschreibung, meist in Form einer OID. Dadurch wird z.b festgelegt, ob es sich um eine Zahl, eine Zeichenkette, ein binäres Objekt oder um etwas noch ausgefalleneres handelt. Einem Qualifier, der festlegt, ob ein Attribut einen einfachen Wert (SINGLE-VALUE) oder eine Liste von Werten COLLECTIVE haben kann. Im letzten Fall kann auch zusätzlich noch eine Listenlänge (LENGTH) angegeben werden. 2.3 Verzeichniseinträge Ein konkretes Objekt wird in einem Verzeichnisdienst durch einen Verzeichniseintrag (engl. directory entry oder einfach entry) repräsentiert. Um einen solchen Eintrag von einer bestimmten Objektklasse zu erhalten, weist man einfach den für diese Objektklasse vorgesehenen Attributen bestimmte Werte zu. In diesem Sinne entsprechen die Einträge eines Verzeichnisses den Ausprägungen im objektorientierten Design bzw. in der objektorientierten Programmierung. Je nachdem, ob man mit dem Denken in Objekten vertraut ist oder nicht, sollte man sich einen Eintrag wahlweise als eine Ausprägung von Objektklassen oder als eine 11

12 Menge von Attributen vorstellen: Objektorientierte Definition: Ein Verzeichniseintrag ist eine Ausprägung einer oder mehrerer Objektklassen. Er wird angelegt, indem man allen für diese Objektklassen obligatorischen Attributen und einigen der fakultativen Attribute Werte zuweist. Attributorientierte Definition: Ein Verzeichniseintrag besteht aus einer Menge von Attributen und gehört einer oder mehreren Objektklassen an. Durch die Objektklassen wird festgelegt, welche Attribute obligatorisch und welche Attribute fakultativ sind. 2.4 Vererbung Ein weiteres Konzept, das auch in der Objektorientierten Welt eine zentrale Rolle spielt, ist das Konzept der Vererbung. Eine Objektklasse kann als Unterklasse einer anderen Klasse definiert werden und erbt dann deren Attributdefinitionen. Ein Entwickler, der eine vorhandene Klasse um bestimmte Attribute erweitern will, leitet einfach eine neue Klasse von ihr ab und braucht die schon vorhandenen Definitionen nicht zu wiederholen. Wenn an der Superklasse nachträglich etwas geändert werden muss, dann machen alle davon abgeleiteten Klassen diese Änderung automatisch mit, ohne dass weitere Aktionen des Entwicklers notwendig wären. X.500 Objektklassen erlauben nur eine einfache Vererbung, d.h., eine Objektklasse darf nur von einer anderen Objektklasse abgeleitet sein. Hierin unterscheiden sich die X.500 Klassen von Klassen in einigen OOSprachen, die wie C++ oder Perl die Mehrfachvererbung unterstützen. 2.5 Polymorphismus in Klassen Ein Verzeichniseintrag hat ein Attribut mit Namen objectclass, das festlegt, welchen Klassen der Eintrag angehört. Das objectclass-attribut ist Mehrwertiges, so dass ein Eintrag mehreren Objektklassen angehören und damit auch deren jeweilige Attributsätze erben kann. Dieses Konzept ähnelt der umstrittenen Mehrfachvererbung in OO-Sprachen. Der Unterschied ist aber, dass mehrfache Klassenzugehörigkeit im X.500-Modell bei den Einträgen auftritt, während sie in C++ oder Perl auf der Ebene der Klassen stattfindet, die den Objektklassen des X.500-Modells entsprechen. Diese Polymorphie der Verzeichniseinträge ist nicht die Ausnahme, sondern die Regel, denn jeder Eintrag muss entweder der Klasse top oder der Klasse alias angehören. Ein von top abgeleiteter Eintrag ist ein,,echter Eintrag, ein von alias abgeleiteter Eintrag ist nur ein 12

13 Verweis auf einen anderen Eintrag. Zu den beiden minimal vorhandenen Werten des objectclass-attributes können dann noch beliebig viele weitere geeignete Objektklassen hinzugefügt werden. 2.6 Standardisierung von Attributen und Objektklassen Häufig stellt sich in einem Anwendungsfall das Problem, Daten für,,anonyme Clients bereitzustellen, d.h. Clientanwendungen, die beim Entwurf des Verzeichnisses noch nicht bekannt waren und die ohne explizite Kenntnis des Verzeichnisses entworfen wurden. Ein typisches Beispiel für eine solche Situation sind LDAP-Adressverzeichnisse, die von Mailprogrammen, Web-Browsern oder Groupware benutzt werden. X.500/LDAP stellt zwar einen Mechanismus bereit, mit dem man Informationen zwischen Anwendung und Server austauschen kann, sagt aber nichts darüber aus, welche Struktur die Objekte haben, die ausgetauscht werden sollen, obwohl eine gewisse Kenntnis der vorhandenen Attribute (Namen, Vornamen, Telefonnummer,...) für das Funktionieren einer solchen Anwendung notwendig ist. Um die Interaktion von anonymen Clients und Verzeichnissen zu ermöglichen, werden häufig gebrauchte Objektklassen und Attribute standardisiert. Grundlegende Dokumente zu diesem Thema sind die X.500-Standards X.520 (The Directory: Selected Attribute types) und X.521 (The Directory: Selected Object classes). Sie definieren eine Vielzahl von Standardattributen bzw. Standardklassen, unter anderem die Klassen Person und organizationalperson, die die Grundlage für die meisten Benutzerverwaltungen bilden. Das RFC 2256 A summary of the X.500 User Schema for use with LDAPv3 bietet auf zehn Seiten eine kompakte Zusammenfassung der wichtigsten Attribut- und Objektklassen. Viele weitere Standardklassen werden auch in anderen RFCs definiert. Zum Beispiel definiert RFC 2798 die Klasse inetorgperson, die wahrscheinlich meist benutzte Klasse in der LDAP- Welt überhaupt. Aus den oben beschriebenen Gründen sollte man standardisierte Objekte verwenden, wo immer das möglich ist. Dies ist in einer erstaunlich großen Mehrzahl der Anwendungsfälle der Fall, denn eine sinnvolle Nutzung der Vererbungsmechanismen erlaubt es, gleichzeitig Objekte flexibel zu entwerfen und standardisierte Schnittstellen zu verwenden: Muss man z.b. ein Personenverzeichnis mit einer Personenklasse entwerfen, das zusätzliche Attribute zu einer solchen Klasse hinzufügt (z.b. Ausbildungsstand), dann kann man eine eigene Personenklasse von einer standardisierten Personenklasse ableiten und um eigene Attribute ergänzen. Damit ist dann garantiert, dass alle Attribute, die die Standardsoftware 13

14 erwartet, auch tatsächlich zur Verfügung stehen und dass Standardsoftware mit diesem Verzeichnis korrekt funktionieren kann. Ein gutes Beispiel für diese Strategie liefert RFC Hier wird die noch nicht an das Leben in einer vernetzten Welt angepasste X.500-Klasse organizationalperson um zahlreiche optionale Attribute erweitert. Abbildung 2 - Objektklasse Person 14

15 2.7 Objektklassentypen X.501 definiert drei Typen von Objektklassen: structural auxiliary abstract Eine Objektklasse sollte als structural deklariert werden, wenn sie elementare Attribute eines Objektes definiert. Beim Beispiel der Objektklassen zur Beschreibung von Personen ist dies die Objektklasse Person und damit ihre Subklassen. X.501 fordert, dass ein Eintrag immer von mindestens einer als structural deklarierten Klasse abgeleitet ist. Andererseits legt X.501 auch fest, dass nur eine Klasse eines Eintrags überhaupt strukturelle Klassen in ihrem Ableitungsbaum enthalten darf. Eine als auxiliary definierte Objektklasse fügt neue Eigenschaften zu einem Eintrag hinzu, determiniert aber nicht den Typ des Eintrages, der durch seine strukturelle Klasse bestimmt wird. Es ist gewissermaßen der Regelfall, dass eine Objektklasse vom Typ auxiliary ist. Es ist eigentlich nur dann gerechtfertigt, eine eigene Klasse als structural zu definieren, wenn darauf eine völlig neue Objekthierarchie aufgebaut wird. Einige wenige Objektklassen sind weder als structural, noch als auxiliary, sondern als abstract deklariert. Dieses Konzept entspricht den abstrakten Klassen, wie sie aus Objektorientierten Programmierung bekannt sind: Abstrakte Klassen sollen nicht initialisiert werden, sondern dienen als Vorlage, um von ihnen abgeleiteten konkreten Klassen bestimmte Eigenschaften zu geben. Beispiele für abstrakte Klassen sind die Objektklassen top und alias, die zur Beschreibung der Struktur des Verzeichnisbaumes verwendet werden. 2.8 Verzeichnisbaum Typisches Merkmal eines Verzeichnisdienstes ist die Anordnung von Objekten (bzw. der die Objekte repräsentierenden Einträge) in einer baumartigen Struktur. Dieser Baum wird in LDAP X.500-konform als Directory Information Tree oder kurz DIT bezeichnet. Der Verzeichnisbaum kommt dadurch zustande, dass manche Verzeichniseinträge anderen Einträgen übergeordnet sind. In anderen Verzeichnisdiensten (z.b. Novell Directory oder Microsofts Active Directory) werden solche übergeordneten Objekte auch Container genannt. Die Vorstellung dabei ist, dass ein Container untergeordnete Objekte enthält. Objekte, die keine weiteren Objekte enthalten, werden auch als Blätter bezeichnet. Jedes übergeordnete Objekt definiert durch die 15

16 in ihm enthaltenen Objekte einen Teilbaum des DIT. Die Suche nach Objekten und die Definition von administrativen Verantwortungsbereichen erfolgt auf der Basis solcher Teilbäume. So wird zum Beispiel im Verzeichnis einer Firmenhierarchie ein Eintrag für eine,,abteilung anderen Einträgen wie,,unterabteilung und,,unterunterabteilung übergeordnet werden. 2.9 Aliase Genaugenommen ist der DIT nicht immer ein echter Baum, bei dem es nur Verbindungen von einer untergeordneten Ebene auf eine höhere Ebene gibt, denn LDAP erlaubt auch so genannte Aliase. Ein Aliaseintrag ist ein Eintrag in einem DIT, der nur auf einen anderen Eintrag im DIT verweist, ähnlich wie ein Alias oder Softlink in einem Dateisystem nur auf ein anderes Objekt verweist. Alias Abbildung 3 - Alias Beliebige Aliase sind in LDAP nicht möglich, denn es müssen die so genannten Deadlocks vermieden werden, bei denen ein Alias (möglicherweise über eine Reihe von weiteren Aliasen) wieder im Kreis auf sich selbst verweist. Alias Abbildung 4 - Deadlock 16

17 2.10 Referenzierung durch Namen Will man mit einem Eintrag im Verzeichnisbaum sinnvolle Dinge anstellen, dann braucht man eine Möglichkeit, um den Eintrag eindeutig zu referenzieren. Der Mechanismus zum Referenzieren von Einträgen basiert; ähnlich wie das Referenzieren von Dateien in Dateisystemen auf einem System von absoluten und relativen Namen. Es wird in der ITU-Empfehlung X.501 beschrieben. Da der Name eines Eintrages im X.500-Modell dazu eingesetzt wird, um ihn von anderen Einträgen zu unterscheiden, spricht man im X.500-Kontext von Distinguished Names. Der häufig gebrauchte Begriff Distinguished Name wird meist mit DN abgekürzt Relative Distinguished Name Die Distinguished Names setzen aus kleineren Bausteinen zusammen, den sogenannten Relative Distinguished Names. Der häufig gebrauchte Ausdruck Relative Distinguished Name wird in der Praxis meist mit RDN abgekürzt. Der RDN wird benutzt, um Einträge unterhalb desselben übergeordneten Eintrages im Verzeichnisbaum eindeutig voneinander zu unterscheiden. Einträge an anderen Stellen im DIT können durchaus denselben RDN verwenden. Ein RDN besteht aus einem oder mehreren Attributen und ihren Werten. Diese können im Prinzip beliebig gewählt sein, solange sichergestellt ist, dass sie hinreichen, um einen Eintrag auf seiner Hierarchieebene eindeutig zu bestimmen. Häufig besitzen die Objekte, die durch einen Eintrag modelliert werden sollen, auch in der realen Welt so etwas wie einen Namen. Die meisten Europäer haben eine Kombination aus Vor- und Nachnamen, den man zur Unterscheidung heranziehen kann. Dafür steht das standardisierte Attribut CN zur Verfügung. Das Kürzel CN steht dabei für Common Name. Im Beispiel unserer Firma aus Abbildung 1 bietet es sich an, das CN-Attribut mit dem Wert Michael Monty Widenius als RDN für die Person und das CN-Attribut mit dem Wert MyNotebook für das Device (Computer) zu verwenden. Es gibt allerdings auch andere Möglichkeiten. Für Personen in überschaubaren Hierarchien, in denen es nicht vorkommt, dass zwei Personen denselben Namen haben, ist der CN üblicherweise die adäquate Wahl für den RDN. Anders sieht es aus, wenn Einträge andere Objekte, zum Beispiel Anlagen und Geräte, beschreiben. Für Inventarstücke von geringerem ideellen Wert bietet sich stattdessen die Verwendung einer Seriennummer als RDN an. Diese hat zudem den Vorteil, eindeutig zu sein. Ähnlich liegen die Dinge bei der Firma MySQL AB, die durch ein Objekt der Klasse 17

18 Organization repräsentiert wird. Hier steht überhaupt kein CN-Attribut zur Verfügung, stattdessen sollte hier das Attribut O (Organization) für den RDN verwendet werden Zusammengesetzter RDN Leider reicht es nicht immer aus, ein einziges Attribut als RDN zu verwenden. In einer Minifirma mag es vorkommen, dass in einer Organisationseinheit die Kombination von Vor- und Nachnamen ausreicht, um eine Person eindeutig zu referenzieren. In den Telefonverzeichnissen größerer Städte wird man aber bestimmte Namen (z.b. Klaus Müller) mehr als einmal vorfinden. Dann stellt sich die Frage, wie man in solchen Fällen einen RDN sinnvoll bestimmt. TOP C=US C=AT C=DE C=IT C=DE L=Halle L=Leipzig L=Merseburg CN=Klaus Müller+STREET=Hallesche Str. 2 Abbildung 5 Nehmen wir z.b. an, dass die Daten von Telefonkunden weltweit in einem Verzeichnis verwaltet werden, wie es Abbildung 5 darstellt: Unterhalb von top befinden sich Einträge für die Länder, darunter die Orte, repräsentiert durch ein Objekt der Klasse Location. Ein Location-Objekt besitzt ein einfaches Attribut l (Location), das wir als RDN verwenden können, was z.b. für Merseburg in Sachsen-Anhalt wie folgt notiert wird: { l=merseburg, Sachsen-Anhalt } Unterhalb des Ortes werden die einzelnen Teilnehmer als Objekte der Klasse residentialperson verwaltet. Ist der Ort nicht allzu groß, dann kann man das Glück haben, dass keine zwei Kunden mit dem gleichen Vor- und Nachnamen existieren. In diesem Fall reicht es aus, das einfache Attribut CN als RDN zu verwenden. Der RDN besteht dann einfach aus dem Wertepaar CN=<Name>, also z.b.: 18

19 { CN=Klaus Müller } Wie erwähnt funktioniert dies natürlich nur dann, wenn die Namenskombinationen aller Teilnehmer voneinander verschieden sind. Da dies in der Regel nicht der Fall ist, muss man stattdessen den RDN aus einem Satz von mehreren Attributen bilden. In unserem Beispiel verwenden wir das Attribut STREET als weiteres Unterscheidungskriterium. Solche mehrfachen Attribute werden im RDN durch ein Pluszeichen»+«getrennt, so dass der RDN wie folgt notiert wird: { CN=Klaus Müller+STREET=Hallesche Str. 2 } Überführung RDN zu DN Der Schritt vom RDN, mit dem ein Eintrag auf seiner eigenen Hierarchiestufe eindeutig referenziert werden kann, zum DN, der einen Eintrag im gesamten Verzeichnisbaum eindeutig referenziert, wird in einer relativ offensichtlichen Art und Weise vollzogen: Dazu hängt man, ausgehend von der Wurzel des Verzeichnisbaumes, die RDNs aller übergeordneten Einträge bis hinunter zum Eintrag, für den der DN bestimmt werden soll, in einer kommaseparierten Liste aneinander und fügt dann noch den RDN des Eintrages dazu. Der DN besteht also einfach aus einer kommaseparierten Liste der RDN, die in absteigender Folge aufgelistet werden. Für die Person aus unserem Beispiel ergibt sich der DN: { C=DE, l=merseburg, Sachsen-Anhalt, CN=Klaus Müller+STREET= Hallesche Str. 2 } Der DN für den Ort sieht so aus: { C=DE, l=merseburg, Sachsen-Anhalt } Der DN des Landes ergibt sich zu: { C=DE } Und nicht zu vergessen das Root-Element, das einen ziemlich trivialen DN hat: { } Einige Sonderzeichen die im Wesentlichen das Komma, das im DN die Aufgabe hat, einzelne RDN-Komponenten voneinander zu trennen werden, wenn sie wie in 19

20 unserem Beispiel Merseburg, Sachsen-Anhalt als Bestandteil eines RDN-Wertes vorkommen, durch einen Backslash maskiert. Auch der Backslash muss, wenn er nicht als Escape-Symbol eingesetzt wird, ebenfalls durch einen weiteren Backslash maskiert sein. RFC 2253 beschäftigt sich ausführlich mit der Namenssyntax im LDAP. 3 Die LDAP Sitzung Das LDAP ist ein Sitzungsbasiertes Protokoll. Das heißt, ähnlich wie bei FTP, SMTP und POP muss zuerst eine Sitzung initialisiert werden, bevor Daten ausgetauscht werden können. Der Ablauf einer regulären LDAP-Sitzung umfasst drei Phasen: 1. In einem ersten Schritt meldet sich der LDAP-Client beim LDAP-Server an. Neben der Initialisierung werden auch Informationen darüber ausgetauscht, welche (erweiterten) LDAP-Features der Client unterstützt und gegebenenfalls erfolgt auch eine Authentifizierung und das Aushandeln der Verschlüsselung. Dieser Schritt wird als Binding genannt. 2. Nach dem erfolgreichen Binding tauschen Client und Server sogenannte Nachrichten (Messages) miteinander aus. 3. In einem letzten Schritt beendet der Client die Sitzung. Dieser Schritt wird unbinding begannt. 3.1 Messages und Operationen Die eigentliche LDAP-Sitzung besteht im wechselweisen Austausch von Nachrichten, den so genannten Messages. So initiiert der Client bestimmte Operationen (requests), der Server antwortet mit einer oder mehreren Antworten (responses). Das LDAP spezifiziert die folgenden, in Tabelle 1 aufgelisteten Operationen. Message bind unbind search modify add Bedeutung Initialisierung einer Sitzung, bei der der Client die Protokollversion spezifiziert und die Credentials für die Authentifizierung. Beenden einer Sitzung. Suche im Verzeichnis. Verändern (add, delete, replace)der Attribute eines Eintrags. Hinzufügen eines neuen Eintrags. Client spezifiziert den Namen und 20

21 delete modify RDN compare eine Liste der Attribute. Löscht einen Eintrag. Ändern den RDN eines Eintrags bzw. ganzer Teilbäume. Testet, ob ein Eintrag ein bestimmtes Attribut-/Wertepaar hat. abandon Teilt dem Server mit, das der Client das Ergebnis einer bestimmten Anfrage nicht mehr braucht. Tabelle 1 - DAP Messages Im klassischen Anwendungsfall einer Middleware für X.500-DSPs hat der LDAP-Server keinen lokalen Zugriff auf den vom Client nachgefragten oder manipulierten Datenbestand. Stattdessen sind die Daten auf einer Reihe von verstreuten X.500-Servern verteilt. Der LDAP- Server muss seinerseits die Anfrage oder Manipulation auf diesen Servern veranlassen und alle Rückmeldungen abwarten, bevor eine Antwort an den Client gesendet werden kann. Es muss also prinzipiell damit gerechnet werden, dass die Latenzzeit zwischen der Anfrage und dem Eintreffen aller Antworten recht lang werden kann. Um diese ansonsten nutzlose Latenzzeit auszufüllen, ermöglicht LDAP eine asynchrone Kommunikation zwischen Client und Server. Der Client darf nach dem Abschicken einer ersten Anforderung schon weitere Anforderungen abschicken, noch bevor die Antworten auf die erste Anforderung eingegangen sind. Wenn die Antworten auf eine frühere Anforderung eintreffen, können sie dann wieder der richtigen Anfrage zugeordnet werden, weil die Anfragen eine eindeutige Identifikation MessageID bekommen., die von der Antwort referenziert wird. Ähnlich wie bei anderen nachrichtenorientierten Protokollen nennt man den Teil einer Message, der administrative Informationen wie die MessageID enthält, den Envelope (Briefumschlag). Das Protokoll LDAP war von vornherein auf Erweiterbarkeit ausgelegt. Da in der LDAP- Welt alles ein Objekt ist, werden auch Protokollerweiterungen (bzw. deren Beschreibung) als Objekte behandelt. Objekte, die besondere Fähigkeiten von Client und/oder Server beschreiben, nennt man Controls. Je nachdem, ob Fähigkeiten von Client oder Server beschrieben werden, spricht man auch von clientcontrols oder servercontrols. Um die vom Client bzw. Server unterstützten Fähigkeiten zu beschreiben, gibt es in den Message- Envelopes besondere Felder, die eine Liste der Objekt-Identifier der unterstützten Controls enthalten. Es gib schon eine ganze Reihe von RFCs, die sich mit Controls zur Erweiterung des LDAP- Core-Standards beschäftigen, beispielsweise: RFC 2649 definiert ein Control signedoperationcontrol, das es erlaubt, LDAP- 21

22 Operationen kryptographisch zu signieren, RFC 2696 definiert ein Control pagedresultscontrol, mit dem sich ein Client Auszüge aus einer Menge von Anfragen anzeigen lassen kann, RFC 2891 definiert Controls, die ein serverseitiges Sortierender Anfrageergebnisse beeinflussen. Bei der Kommunikation mit LDAP kommt natürlich die ASN.1 (Abstract Syntax Notation Number 1) zu Einsatz. Die Bedeutung von ASN.1 für das LDAP liegt darin, dass ASN.1 zur Beschreibung der X.500 Datentypen verwendet wird. Für das LDAP sind vor allem die Basic Encoding Rules (BER) wichtig. 4 Die Verteilung des Verzeichnisses Das Wort Partitionierung bezeichnet im X.500 Sprachgebrauch die Verteilung eines Verzeichnisses auf mehrere Server. Dies dient der Vereinfachung der Administration und verbessert die Lastverteilung. Partitionierung ist ein wesentliches Merkmal (und Pluspunkt) von Verzeichnisdiensten. Mit dem Directory Server Protocol DSP stellt X.500 schon auf der Protokollebene Unterstützung für die Partitionierung von Verzeichnissen bereit. Ein X.500- kompatibler Directory System Provider, der von einem Client nach Objekten gefragt wird, die sich auf einem anderen Server befinden, wird diese Daten mittels des DSP-Protokolls von den entsprechenden anderen Servern einsammeln und an den Client schicken. Der Client merkt bei dieser Vorgehensweise nichts von der verteilten Verzeichnisstruktur, das Verzeichnis ist eine Blackbox, auf die er über einen einzigen Server (bzw. DSP) zugreifen kann. Im klassischen Anwendungsfall einer Middleware zwischen TCP/IP-Netzwerk und X.500- Verzeichnis ist also die Partitionierung von Verzeichnissen kein Thema für LDAP, das lediglich die Client-Server-Kommunikation beschreibt und nicht die Kommunikation der Server untereinander. 4.1 Naming Context Ein Eintrag im DIT wird von genau einem Server aus administriert, dieser wird als Administrative Authority, im X.500-Jargon auch als Master-DSA oder einfach Master bezeichnet. Ein Naming Context ist ein maximaler Teilbaum des DIT, dessen Einträge alle denselben Master haben. Maximaler Teilbaum heißt hier, dass der Naming Context bei einem einzigen Eintrag startet und sich über alle im DIT unterhalb von diesem Eintrag gelegenen 22

23 Einträge erstreckt, die noch von demselben Master administriert werden. Der von einem Master administrierte Ausschnitt aus dem DIT kann aus einem oder mehreren Naming Contexts bestehen. Der ganze DIT besteht also aus einer Menge von disjunkten Naming Contexts, wobei es durchaus möglich ist, dass mehrere davon von demselben Master administriert werden. Jeder Naming Context hat einen initialen Eintrag. Den Dinstinguished Name des des initialen Eintrags, der damit auch Bestandteil des DN aller anderen Einträge in diesem Naming Context ist, nennt man auch das Prefix oder Context Prefix dieses Naming Context. 4.2 Referrals und Continuations Mit dem Paradigmenwechsel vom X.500-Frontend hin zum,,standalone-ldap-server ergeben sich aber auch Probleme: Die oben beschriebene elegante Vorgehensweise ist für einen LDAP-Server nicht mehr möglich, wenn andere Backends als X.500-DSPs verwendet werden, es fehlt dann schlicht an einem LDAP-Kommunikationsprotokoll für die Server. Die Verwendung von DSP ist mangels OSI-Stack nicht möglich, und eine TCP/IP-basierte Lösung würde faktisch zu einem neuen Protokoll führen. Um diesen Problemen aus dem Weg zu gehen, wird die Navigation in verteilten Verzeichnissen seit LDAPv3 auf die Clients abgewälzt. Der Server kann dem Client in diesem Fall mit einem Referral antworten. Ein solches Referral ist ein Verweis auf einen Ort an andere Server, der das nachgefragte Objekt bereitstellt. Ähnlich wie bei Referrals funktionieren Continuations. Continuations sind Verweise auf andere Server, die bei Suchoperationen auftreten. Sie geben einen Ort an, an dem die bereits begonnene Suche fortgesetzt werden kann. Für die Partitionierung von Verzeichnissen sind zwei Typen von Referrals wichtig: Subordinate Referrals: Ein solcher Verweis auf einen LDAP-Server, der einen Teilbaum des DIT verwaltet, welcher unterhalb des vom verweisenden Server verwalteten Teilbaums angesiedelt ist. Diese Verweise stellen gewissermaßen den Leim bereit, der partitionierte Verzeichnisse zusammenhält. Superior Referrals: Ein solches Referral wird generiert, wenn der Server keine Information über den zu durchsuchenden Namensraum hat, und verweist in der Regel auf einen Server, der im DIT höher angesiedelt ist. 5 Sicherheit 23

24 Egal welcher Datenbasis ein LDAP-Server als Middleware vorgeschaltet ist, als Verbindung zwischen Datenbasis und Außenwelt bildet er das Einfallstor für entfernte Angriffe gegen die Datensicherheit. Diese kann im Wesentlichen auf zweierlei Arten beeinträchtigt werden: durch unautorisiertes Verändern von Daten, durch unautorisiertes (Mit-)Lesen von Daten, was im besonders schlimmen Fall das unautorisierte Mitlesen von wiederverwendbaren Authentifizierungsdaten sein kann. Autorisierung und Authentifizierung sind die zwei zentralen Begriffe beim Thema Sicherheit: Authentifizierung: Eine Authentifizierung befasst sich mit dem Problem, die Identität eines Objekts zu überprüfen. Dies kann zum Beispiel geschehen, indem Passwörter oder Schlüssel überprüft werden. Autorisierung: Die Autorisierung ist die Gewährung von Rechten. Dabei wird i.d.r. Davon ausgegangen, dass das Objekt, dem Rechte gewährt werden, bereits eine erfolgreiche Authentifizierung hinter sich gebracht hat. Nehmen wir beispielsweise die Zugangskontrolle und Rechteverwaltung bei einem Multiuser- Betriebssystem. Die Überprüfung der Identität des Benutzers beim Login ist eine Authentifizierung. Die Frage, welche Rechte dem Benutzer beim Zugriff auf Dateien und Prozessen zustehen, ist ein Problem der Autorisierung. 5.1 Zugriffskontrolle im LDAP Ein einheitliches Konzept für die Zugriffskontrolle war im LDAP zunächst nicht spezifiziert. Daran erkennt man die Tatsache, dass das LDAP nur ein Zugriffsprotokoll ist. Der Server führt vom Client angeforderte Aktionen aus oder nicht, und er muss den Client informieren, wenn eine Aktion wegen mangelnder Privilegien nicht ausgeführt werden wird. Die Frage, wie ein Server Zugriffsprotokolle und Privilegienverwaltung implementiert, liegt eigentlich schon ausserhalb der Reichweite des LDAP. Obwohl es lange keinen offiziellen Standard gab, der sich mit der serverseitigen Organisation der Zugriffsprotokolle befasst, verfügen natürlich alle wesentlichen LDAP-Implementationen über eine solche. Bei den meisten Implementationen orientiert sich deren Design an der Zugriffskontrolle des UMich-LDAP. 24

25 Unter dem Dach der IETF gibt es in letzter Zeit allerdings Bestrebungen, Zugriffsprotokolle und Autorisierung zu vereinheitlichen: RFC 2820 beschreibt Anforderungen an ein zukünftiges, auf Access Control Lists basierendes Modell der Zugriffskontrolle, draft-ietfldapext-acl-model Access Control Model for LDAP beschreibt ein Privilegiensystem. Beides scheint aber noch weit von einer Umsetzung entfernt zu sein. 5.2 Authentifizierung Auch wenn sich das LDAP nicht mit der Frage befasst, wie die Zugriffskontrolle realisiert wird, geht es dennoch davon aus, dass eine Zugriffskontrolle stattfindet und dass deswegen eine Authentifizierung des Clients beim Server notwendig ist. Seit den früheren LDAP- Versionen gib es dafür ein einfaches Verfahren, beim dem eine BenutzterID und ein Passwort im Klartext übermittelt werden. Dieses veraltete Verfahren wird heute oft als simple authentificaton bezeichnet. Einen Bind, der mit dieser Art von Authentifizierung durchgeführt wird, bezeichnet man als simple bind. Der simple bind ist allerdings beim anonymen bind, mit dem man sich öffentlich zugängliche Daten besorgt, nach wie vor Methode der Wahl. Eine einfache Methode, Authentifizierungsdaten zu verwalten, ist es, diese in einem Verzeichnis abzulegen und den DN des Objekts, das die Authentifizierungsdaten enthält, als Benutzeridentifikation zu verwenden. In einem solchen Szenario redet man davon, dass ein Benutzer sich als ein bestimmtes Objekt an das Verzeichnis bindet. Man findet die Sprechweise zum Beispiel in den Manual Pages der LDAP-Utilities wieder, wo von der BenutzerID als einem,,binddn die Rede ist. Die simple authentification kann in öffentlichen Netzen längst nicht mehr als sicher angesehen werden, da Benutzername und Passwort im Klartext über das Netz geschickt werden und mit geeigneten Sniffern wie ngrep oder ethereal abgefangen werden können. Da die Datenübertragung während der laufenden Sitzung bei LDAPv2 sowieso unverschlüsselt erfolgt, lassen sich mit derartigen Werkzeugen auch die während einer Sitzung übertragende Daten abfangen. 25

26 Abbildung 6 - unverschlüsselte LDAP Sitzung Moderne Gegenmaßnahmen gegen solche Angriffe beinhalten eine möglichst starke Authentifizierung zu Beginn einer Sitzung, sowie eine Verschlüsselung der Datenströme während einer Sitzung. In den LDAPv3-Core-Specs war noch kein Subprotokoll für Authentifizierung und/oder Verschlüsselung definiert. Stattdessen enthalten alle Core-Specs nur einen Hinweis auf das vorläufige Fehlen derartiger Mechanismen. Das erste RFC ließ aufgrund der Dringlichkeit zur Lösung dieses Problems lange auf sich warten. Erst im Mai 2000 wurden zwei RFCs zu Verschlüsselsmechanismen für LDAP veröffentlicht. Es wird aber kein eigener Mechanismus für Authentifizierung und Verschlüsselung entwickelt. Verschlüsselung und Authentifizierung für LDAP werden dedizierten Protokollen, den Protokollen SASL und der Kombination SSL/TLS überlassen. 26

27 RFC 2229 nennt u.a. vier Sicherheitsmechanismen, die in LDAP integriert sein sollen: 1. Client-Authentifizierung mittels SASL, optional zusätzlich durch SSL/TLS- Mechanismen, 2. Server-Authentifizierung durch das TLS-Protokoll, optional zusätzlich durch SASL- Mechanismen, 3. Schutz der Datenintegrität durch Integration von TLS- und/oder SASL-Mechanismen, 4. Schutz der Daten vor unautorisierten Mitlesen (snooping) durch Verschlüsselung mit TLS- und/oder SASL-Mechanismen. Zum Auslagern der Sicherheitsfunktionalität unterstützt LDAP das Simple Authentification and Security Layer (SASL). SASL stellt entweder eigene Funktionen für Verschlüsselung oder Authentifizierung zur Verfügung, oder die SASL-Implementierung wählt bei einer Verbindungsanfrage aus einer Reihe von Authentifizierungsmechanismen einem vom Client unterstützten externen Mechanismus (z.b. TLS) aus und führt damit die Authentifizierung durch. Nach einer erfolgreichen Authentifizierung ist es mit SASL auch möglich, eine Verschlüsselungsmethode auszuwählen, mit der die Sitzung verschlüsselt wird (z.b. IPSec oder SSL/TLS). Die Auswahl des Protokolls erfolgt anhand eines Schlüsselwortes, das der Client sendet. Die IANA (Internet Assigned Numbers Authority) pflegt eine Liste von unterstützten Protokollen und der zugehörigen Keywords. Wichtig im Zusammenhang mit LDAP/OpenLDAP sind insbesondere die folgenden Mechanismen: KERBEROS_V4: Kerberos Version 4. Noch gelegentlich anzutreffende ältere Version des Kerberos-Protokolls, GSSAPI: SASL-Mechanismus, mit dem Authentifizierungsmechanismen gestartet werden, die auf GSSAPI nach RFC 2078 basieren, EXTERNAL: Externe Authentifizierung. Delegiert die Authentifizierung an eine externe Anwendung. Wird bei der Benutzung von TLS oder IPSec gebraucht. 5.3 Der Strong Bind Die SASL-Unterstützung machte es mit LDAPv3 notwendig, den Bind-Request zu ergänzen. Wird eine stärkere Authentifizierung benötigt, dann steht seit LDAPv3 der sogenannte strong bind zur Verfügung. Beim strong bind muss der Client angeben, welche 27

28 Authentifizierungsmethode er sich wünscht, und außerdem müssen die Credentials, d.h. die an die jeweilige Authentifizierungsmethode angepassten Authentifizierungsdaten übergeben werden. 6 Schema Klassen unter LDAP Ein Verzeichnisdienst besteht aus Daten und Metadaten. Unter Metadaten versteht man konkret Informationen über die Struktur des Verzeichnisdienstes, zum Beispiel: Definition der verwendeten Attributtypen, Definition der verwendeten Objektklassen, Filter/Matching-Regeln bei Vergleichsoperationen, Rechte zum Anlegen oder Modifizieren von Datensätzen. Die Information über die verwendeten Attributtypen und Objektklassen wird in einem sogenannten Schema verwaltet. Ein eigenes Verzeichnis zu entwerfen bedeutet im Wesentlichen, ein Schema zu entwerfen bzw. ein vordefiniertes Schema ganz oder teilweise zu übernehmen. X.501 beschäftigt sich mit Schemata für X.500-basierte Verzeichnisdienste. OpenLDAP verwaltet die Schemata für den Server in Textdateien in einem eigenen Verzeichnis. Die OpenLDAP-Distribution bringt standardmäßig eine Reihe von vordefinierten x.schema- Dateien mit. Schemaübersicht: corba.schema: Enthält Datendefinitionen aus RFC 2714 für Common Object Request Broker Architekture (CORBA), einen offenen Standard zum Austausch von Objekten zwischen verschiedenen Anwendungen. core.schema: Eine umfangreiche Sammlung von für den Betrieb des LDAP-Servers wichtigen Schemata cosine.schema: Der RFC 1274 Cosine and Internet X.500 Schema definiert eine gigantische Menge von Attributen und Klassen, die ursprünglich für einen internetweiten Suchdienst gedacht waren. Einiges aus cosine.schema wird z.b. für nis.schema und openldap.schema gebraucht. 28