Hauptseminar Telekommunikation Directory Service LDAP (Vergleich mit X.500)

Transkript

1 Technische Universität München Lehrstuhl für Kommunikationsnetze Prof. Dr.-Ing. Jörg Eberspächer Hauptseminar Telekommunikation Directory Service LDAP (Vergleich mit X.500) Verfasser: Walter Werther Matrikelnummer: Anschrift: Magdalenenweg Kirchheim Betreuer: Dr. Ing. Martin Maier Vortrag: 26. Mai 2003

2 Abstract In Zeiten von immer schneller wachsender IT-Infrastruktur wird es immer wichtiger, eine große Menge von Informationen zentral zu speichern und übersichtlich zu verwalten. Gleichl ob es sich hierbei um Personaldaten (Loginname, Personalnummer, Passwort) oder beispielsweise der Konfiguration von Freigaben bei Fileservern handelt. Jeder Systemadministrator wünscht sich hierfür eine einfache, zentrale, strukturierte und ausfallsichere Speicherung der Daten. Ebenso wichtig ist neben der reinen Speicherung auch noch eine Kontrolle über die Zugriffsrechte auf die Daten. Darüber sollten die Möglichkeiten der Skalierbarkeit nicht zu schnell an ihre Grenzen kommen. Kurzum wird nach einer eierlegenden Wollmilchsau verlangt, die alles kann. Einen guten Ansatz bieten hier Verzeichnisdienste. Bereits 1988 spezifizierte die ITU im Umfang von zehn Dokumenten den X.500- Standard. In diesen wird die Struktur der zu Grunde liegenden Datenbank ebenso wie die Kommunikationsprotokolle der implementierenden Dienste festgelegt. X.500 fand aber anfangs keine besonders große Akzeptanz, da es extrem aufwendig gestaltet war. Es verlangte nach einer kompletten Implementierung der OSI-Schichten und unterstützte nicht die Nutzung vorhandener Kommunikationsprotokolle wie TCP/IP. LDAP wurde erstmals 1993 spezifiziert. Es ersetzte die aufwendige Schnittstelle zwischen Client und Server, die in X.500 durch das DAP-Protokoll repräsentiert wurde. Außerdem basierte es auf TCP/IP. Der Funktionsumfang und die Funktionsweise von LDAP sowie die Änderungen zum zur Grunde liegenden Standard X.500 ist Thema dieser Hauptseminarsarbeit

3 Inhaltsverzeichnis Inhaltsverzeichnis ABSTRACT...2 INHALTSVERZEICHNIS EINLEITUNG VERZEICHNISSE UND VERZEICHNISDIENSTE X.500 BASICS PROTOKOLLE UND VERNETZUNG BEI X STRUKTUR EINES X.500-VERZEICHNISSES X.500 BENUTZERZUGRIFF BEISPIELE FÜR X.500-IMPLEMENTIERUNGEN LDAP GRÜNDE FÜR X.500-ALTERNATIVEN PROTOKOLL VERSUS SERVER LDAP-SITZUNG SUCHEN MIT LDAP DER LDAP-SERVER Zugriffskontrolle Das Schema Weitere Funktionalität ZUSAMMENFASSUNG NOTATIONEN UND ABKÜRZUNGEN ABBILDUNGSVERZEICHNIS TABELLENVERZEICHNIS LITERATURVERZEICHNIS

4 1 Einleitung Kapitel 1 Einleitung Diese Arbeit beschäftigt sich mit dem LDAP-Protokoll und dessen Implementierung. Außerdem wird ein Vergleich zu dem älteren Standard X.500 gezogen. Um jedoch zu verstehen, wie LDAP arbeitet und wo es ansetzt, werden am Anfang der Arbeit die Grundlagen zu Verzeichnissen und Verzeichnisdiensten erklärt. Um LDAP genau verstehen zu können, werden anschließend die Grundlagen von X.500 erläutert. So wird zunächst erklärt, welche Funktionen ein X.500-Verzeichnis bietet. Nachdem die Grundzüge von Partitionierung und Replizierung dargestellt sind, wird die hierarchische Struktur des X.500 beschrieben. Der Unterschied zwischen einem Attribut und einem Objekt wird ebenfalls erläutert. Danach werden die von X.500 unterstützten Benutzerzugriffe beschrieben. Außerdem werden Beispiele für verschiedene X.500-Implementierungen gegeben. Im nächsten großen Kapitel geht es dann um LDAP. Zunächst wird verdeutlicht, warum man nicht den von X.500 vorgesehenen Standard verwendet. Danach wird der Unterschied zwischen LDAP und LDAP-Server erklärt und dargelegt, wie eine LDAP- Sitzung abläuft. Dann werden am Beispiel der "Suche" die Abläufe dargestellt, die vorkommen, wenn ein Sucheintrag nicht auf dem angesprochenen Server liegt. Als letztes Kapitel wird der LDAP-Server 'SLAPD' erläutert. Abschließend wird noch ein Ausblick auf die Möglichkeiten gegeben, die LDAP für die Systemadministration bietet

5 Kapitel 2 Verzeichnisse und Verzeichnisdienste 2 Verzeichnisse und Verzeichnisdienste Bevor man sich um die Details von LDAP kümmert, sollte man sich zunächst einmal klar machen, was ein Verzeichnisdienst ist und wie sich die Speicherung eines Verzeichnisses von der in relationalen Datenbanken unterscheidet. Während eine relationale Datenbank ihre Daten in Tabellen, Zeilen und Spalten - mit fester Bedeutung der einzelnen Zellen - speichert, verwendet ein Verzeichnisdienst eine Baumstruktur. Diese enthält Objekte (z.b. einen BigMac ) die nach Kategorien (Rezepte, Personal) sortiert abgelegt sind. Diese sind selbst wiederum Objekte. Das Verzeichnis selbst stellt die lose Ansammlung der Informationen dar, auf die ein Zugriff gewährleistet sein muss. Einen Zugriff auf die Daten im Verzeichnis bietet ein Verzeichnisdienst (engl: directory service (DS)). Die Speicherung in Verzeichnissen erfolgt in einer bestimmten Reihenfolge. Zum Beispiel sind in einem Telefonbuch die Namen alphabetisch sortiert. Die Details zum Namen, wie die Anschrift und Rufnummer werden in folgenden Kontext stets als Attribute bezeichnet. In einem Verzeichnis hat der Anwender die Möglichkeit nach bestimmten Informationen Rezepte Mc King Big Mac Cheeseburger FishMac Gurke Fleisch Salat Majonäse Käse Fleisch Salat Majonäse... Personal Gurke Fisch Salat Majonäse Abbildung 2-1Das Mc-King Verzeichnis zu suchen. Betrachten wir das an nebenstehenden Beispiel. Kennt der Kunde den Burger den er essen möchte, so ist es ihm möglich im Verzeichnis nach den verwendeten Zutaten zu suchen. So erhält er auf die Anfrage, was ein Cheeseburger alles beinhaltet die Attribute Käse, Fleisch, Salat, Majonäse zurück. Umgekehrt ist es aber auch möglich, nach Objekten zu suchen, die bestimmten Kriterien entsprechen. Mag der Kunde kein Fleisch, so wird ihm das Objekt FishMac zurückgegeben. Sucht er nach allen Objekten, die Gurke beinhalten, so erhält er die Objekte BigMac und FishMac zurück. Die abgespeicherten Daten werden in einem Verzeichnis flexibel, dynamisch und sicher aufbewahrt. Flexibel bedeutet, dass die Struktur vom Anwender bestimmt werden kann und nicht von der Datenbank an sich vorgegeben ist. Es wäre ein leichtes, noch Menüs oder Kalorienangaben in das Verzeichnis mit aufzunehmen. Dynamisch bedeutet, dass sich Informationen verändern können. So kann sich unsere Burgerfirma entscheiden, statt Gurken lieber Zucchini in die Burger zu packen. Diese Änderungen sind allerdings eher selten (wer würde das auch essen?). Deshalb geht man bei Verzeichnisdiensten im Gegensatz zu relationalen Datenbanken davon aus, dass die Daten nicht hochdynamisch sind. DS sind von ihrer Konzeption eher auf effektive Suchalgorithmen als auf eine hohe Zahl von Schreibzugriffen ausgelegt. Sicher bedeutet in diesem Zusammenhang, dass bestimmte Objekte mit unterschiedlichen Zugriffsrechten ausgestattet werden können. Anhand der obigen Abbildung bedeutet das, dass die Personaldaten nicht von jedermann einsehbar sind. Verzeichnisdienste zeichnen sich dank ihrer Baumstruktur dadurch aus, dass sie leicht aufteilbar sind. Die Funktionsweise ist in einem späteren Kapitel erklärt. Diese Zugriffsfunktionen werden von einer API zur Verfügung gestellt. Diese API ist der Verzeichnisdienst

6 3 X.500 Basics Kapitel 3 X.500 Basics 3.1 Protokolle und Vernetzung bei X.500 Durch X.500 ist eine verteilte Datenbank definiert. Nicht alle Daten müssen auf einem einzigen Rechner liegen, sondern können auf verschiedene Server verteilt sein. Diese Funktion nennt sich Partitionierung. Die einzelnen Server werden als Directory System Agents (DSA) bezeichnet. So könnte beispielsweise ein DSA die Personaldaten verwalten und physisch in der Firmenzentrale stehen. Ein weiterer DSA würde dann die Rezepte für die verschiedenen Burger speichern. Für den Anwender bleibt dieser Vorgang transparent. Er verbindet sich mit einem der beiden Server und fragt nach den benötigten Informationen. Hat der zugehörige Server die Information nicht, so fragt er wiederum bei dem anderen Server nach und liefert anschließend die erhaltene Datenmenge zurück. Eine weitere praktische Eigenschaft von X.500 ist die Replikationsfähigkeit. Sie ermöglicht es, verschiedene Teilbäume zu vervielfachen und auf mehreren Servern vorrätig zu halten. So könnte zum Beispiel jede Filiale unserer Burger-Kette einen eigenen Server mit den Rezepten besitzen. Dieser Server gleicht dann automatisch seine Daten mit denen des Masterservers in der Zentrale ab. Um diese Dienste zur Verfügung stellen zu können, sieht X.500 verschiedene Protokolle vor, die auf den sieben Schichten des OSI-Modells aufbauen. Zum einen gibt es das DAP (Directory Access Protocol). Dieses definiert die Kommunikation zwischen dem DUA (Directory User Agent) und dem Directory System Agent (DSA). Vereinfacht ist der DUA der normale Anwender und der DSA der Server, von dem er Informationen will. Des weiteren ist das DSP (Directory System Protocol) definiert, das für die Kommunikation zwischen unterschiedlichen DSAs zuständig ist. Das DISP (Directory Information Shadowing Protocol) wiederum dient zum Austausch der Informationen für die Replikation zwischen Master und Slave-Servern. Als letztes Protokoll ist noch das DOP (Directory Operational Binding Management Protocol) definiert. Es wird zum administrativen Austausch von Informationen zwischen zwei Directory System Agents verwendet. 3.2 Struktur eines X.500-Verzeichnisses DSA 1 Verzeichnis Teil 1 DSA 3 Verzeichnis Teil 3 Abbildung 3-1 Replikation und Partionierung DSA 2 Verzeichnis Teil 2 Wie oben schon kurz angerissen, verwenden DS zur Speicherung ihrer Daten eine Baumstruktur. Wie bei Baumstrukturen üblich gibt es ein namenloses Wurzelobjekt. Dieses wird root genannt. Unterhalb dieser Wurzel erfolgen sämtliche Einträge. Der gesamte Baum wird als DIT (directory information tree) bezeichnet. Innerhalb des DIT befinden sich Objekte, die eindeutigen Objektklassen zugeordnet sind. Jeder Eintrag gehört mindestens einer Objektklasse an. Eine Objektklasse definiert, welche Attribute ein Eintrag besitzen muss und darf. Jede Objektklasse muss wiederum mindestens einen Attributtypen beinhalten. Ein Eintrag in einem DIT ist also eine Instanz einer/mehrere Objektklasse(n). Client DSA 4 Replica Teil 1-6 -

7 Kapitel 3 X.500 Basics Als einen Sondertyp stellt X.500 Alias-Einträge zur Verfügung. Es ist damit möglich, einen Eintrag an mehreren Stellen im Verzeichnisbaum zu verwenden. Wird ein Wert innerhalb des Eintrags verändert, so verändert sich der Wert auch bei sämtlichen Alias- Einträgen. Wie in der nebenstehenden Abbildung zu sehen, verwendet die Mensa bei ihren Tagesgerichten einfach einen Alias auf BigMac der Firma McKing. Abbildung 3-2 Ein X.500 Verzeichnisbaum Bei X.500-Verzeichnissen besitzt jeder Eintrag einen eindeutigen Namen. Dieser wird als Distinguished Name bezeichnet. Dieser lässt sich einfach zusammensetzen. Er besteht aus dem eigenen Namen des Eintrags, der als Relative Distinguished Name (RDN) auf der Ebene eindeutig sein muss, auf der dieser Eintrag im Baum hängt. Daran wird der DN der Ebene in der er eingeklinkt ist angehängt. Dieser DN setzt sich nach dem gleichen System zusammen, bis man bei der Wurzel angekommen ist. Eine Besonderheit weist der Name des Eintrags selber auch noch auf. Jeder Eintrag gehört einer Hauptobjektklasse an, dessen Hauptattributtyp (als Primary Distinguished Value bezeichnet) im Namen vorkommen muss. Nehmen wir den BigMac den McKing herstellt. Sein Hauptattributtyp ist CN, das als Kurzschreibweise für CommonName steht. Also wird dieser Attributsname dem eigentlichen Wert vorangestellt. Der RDN ist also Hauptattributtyp CN= + Wert BigMac = CN=BigMac. Sein DN ist nach obiger Definition CN=BigMac;CN=Rezepte;DC=McKing;DC=DE. 3.3 X.500 Benutzerzugriff X.500 definiert 9 verschiedene Arten des Zugriffs auf das Verzeichnis. Diese werden allesamt vom DUA angefordert. Man kann 3 Klassen von Zugriffen unterscheiden. Es gibt lesende, modifizierende und Systemzugriffe. Lesende Zugriffe READ LIST DC=TUM CN=Mensa CN=Tagesgerichte ALIAS BigMac Liefert die Attribute und deren Werte eines angefragten DNs zurück Listet alle RDNs auf, die direkt unter einem gegeben Eintrag stehen SEARCH Sucht in einem Teilbaum des Verzeichnisses nach bestimmten Einträgen COMPARE Schreibende Zugriffe ADD REMOVE CN=Personal CN=BigMac DC=McKing WURZEL DC=DE CN=Rezepte CN=FishMac CN=Personal DC=PizzaFix CN=Cheeseburger DC=US CN=Rezepte Führt einen Vergleich eines gegebenen Wertes mit einem Attribut durch. Mit dieser Funktion lassen sich zum Beispiel Passwörter überprüfen Ermöglicht das Einfügen eines neuen Objekts in einen Verzeichnisbaum und setzt die übergebenen Attribute Löscht einen Eintrag aus dem DIT. Es dürfen nur Blattobjekte gelöscht werden

8 MODIFY MODIFY DISTINGUISHED NAME Systemzugriff ABANDON Tabelle 3-1 Benutzerzugriff bei X.500 Kapitel 3 X.500 Basics Soll ein ganzer Teilbaum entfernt werden muss dies also rekursiv erfolgen Ermöglicht Änderungen an einem Eintrag wie Löschen, Hinzufügen oder Ändern von Attributen Mit dieser Funktion wird der RDN eines Objekts geändert. Werden hierbei auch andere Komponenten im DN geändert, so wirkt sich das wie eine Verschiebung des gesamten Teilbaums an eine andere Stelle aus Abbrechen einer Operation. Benötigt ein Directory User Agent das Ergebnis einer Abfrage nicht mehr, kann er die Operation abbrechen Da ein Verzeichnisservice theoretisch weltweit, aber zumindest von sehr vielen Geräten aus zugänglich ist, muß es natürlich auch möglich sein, die Zugriffsrechte auf bestimmte Einträge zu beschränken. Auch hier bietet X.500 weitreichende Möglichkeiten. Man kann festlegen, welche Objekte auf welche Attribute und Einträge zugreifen dürfen. Die hierfür notwendige Authentifizierung kann auf zwei Wegen erfolgen. Entweder über einen einfachen Passwortvergleich oder über Public-Key- Zertifikate. So kann sichergestellt werden, dass nur berechtigte Personen oder Programme auf bestimmte Teile des Baums zugreifen. 3.4 Beispiele für X.500-Implementierungen Am Ende dieses Kapitels sollen nun noch ein paar Anwendungen / Dienste erwähnt werden, die auf X.500-Verzeichnissen basieren. Zum einen gibt es da Novells edirectory, das zur Verwaltung von Zugriffsrechten, Usern und anderen Netzwerkressourcen verwendet wird. Es steht für die wichtigsten Plattformen zur Verfügung: Netware (ab Version 5), Windows NT/2000, Linux und Solaris. Novells edirectory bietet eine gut unterstützte Schnittstelle zu LDAP. Sehr bekannt ist auch Microsofts Active Directory. Dieser ab Windows 2000 verfügbare X.500 konforme Dienst ermöglicht Abfragemöglichkeiten nach Internet-Standards, LDAP, DNS und DDNS. Wie bei Microsoft nicht anders zu erwarten existiert bis jetzt nur eine Implementierung für Windows-Systeme. Auch Siemens bietet mit DirX einen Verzeichnisdienst an. Er ist besonders auf die Bereitstellung von Adressen, Personaldaten, Fax und Telefonnummern ausgelegt. Er steht für Unix-Varianten und Windows NT/2000 zur Verfügung. Über spezielle Gateways kann dieser Dienst auch über eine Webschnittstelle oder WAP abgefragt werden. Allerdings ist auch eine Schnittstelle zu LDAP-fähigen Clients implementiert. Schließlich und endlich gibt es noch LDAP selbst, das im weiteren Verlauf näher betrachtet wird. Der wohl am häufigsten zum Einsatz kommende Server hierfür stammt aus dem OpenLDAP Projekt und läuft unter dem Namen SLAPD (Standalone LDAP). Er zeichnet sich durch eine hohe Geschwindigkeit und Verfügbarkeit aus. Im Gegensatz zu seinen kommerziellen Vertretern ist dieser Dienst im Sourcecode verfügbar

9 4 LDAP Kapitel 4 LDAP 4.1 Gründe für X.500-Alternativen Sicherlich stellt sich dem geneigten Leser jetzt die Frage, warum sich LDAP und die anderen Verzeichnisdienste überhaupt entwickelt haben, zumal sie alle ein X.500 Verzeichnis verwenden. Nun wohl einer der ausschlagebensten Gründe ist der, dass die X.500-Protokolle unglaublich komplex zu handhaben waren. Sie waren nicht dazu geeignet, auf bereits bestehenden Transport-Protokollen wie TCP/IP angewandt zu werden. Sie erforderten eine volle Repräsentation des OSI-Schichten-Modells. Insbesondere für die Schnittstelle zwischen DUA, also dem Endbenutzer und dem DSA stellte das ein Hindernis dar, da beim Client ein erheblicher Mehraufwand an Programmierung und Rechenleistung notwendig wurde. Um dieses Schwergewichtigkeit des Protokolls loszuwerden entwickelte sich eine Leichte -Variante. Eben LDAP. 4.2 Protokoll versus Server Sehr häufig wird vom X.500-Protokoll sowie vom LDAP-Protokoll gesprochen. Was ist damit nun gemeint? X.500 wie es von der ITU vorgeschlagen wurde ist mehr als ein Protokoll. Es beinhaltet unter anderem auch noch die Spezifikationen zum Verzeichnis an sich. Deshalb wird, wenn nur das Protokoll gemeint ist, eben von den X.500 Protokollen gesprochen. LDAP bietet eine Ersetzung für DAP aus der X.500 Welt. Eben ein leichtes DAP. Der Begriff LDAP-Protokoll ist also genaugenommen falsch. Wenn man LDAP ausschriebe, würde sich Lightweight-Directory-Access-Protocol-Protokoll daraus ergeben, was nun nicht sehr logisch klingt. LDAP selbst ist also nur das zu Grunde liegende Protokoll. Weshalb also immer die Verwechslung mit dem Server? Das Programm das für den Benutzer die Abfragen durchführt, bezeichnet man als Client. Nachdem er zur Kommunikation das LDAP verwendet, nennt man ihn LDAP-Client. Auf der Serverseite sieht das genauso aus. Nachdem der Server LDAP versteht, handelt es sich um einen LDAP-Server. Wie der Server nun auf das Verzeichnis zugreift, bleibt dem Client verborgen. Anfangs war es so, dass ein LDAP-Server die Anfragen des einen Protokolls in die eines anderen übersetzte (X.500). Dabei fungierte er selbst als Client, der über eine OSI- Implementierung auf einen X.500-Server zugriff. Der wiederum griff auf das eigentliche Verzeichnis zu. LDAP- Client TCP/IP LDAP- Server X.500 Client OSI X.500 Server Verzeichnis Abbildung 4-1 LDAP als X.500 Gateway Allerdings hat man schnell festgestellt, das diese Art des Zugriffs extrem aufwendig und umständlich war. Also entfernte man die Protokollübersetzung und den X.500-Server und integrierte das Verzeichnis direkt in den LDAP-Server, der nun selbst die vollständige Kontrolle über das Verzeichnis (das noch immer nach der X.500 Spezifikation aufgebaut ist) übernommen hat. Der Standalone LDAP-Server ist daraus hervorgegangen

10 Diese schlanke Variante hat sich nun im Laufe der Jahre stark verbreitet. Die Strukturen in LDAP sind so weit vereinfacht, dass eine ressourcensparende Implementierung möglich wurde. Außerdem wurde bei der Datenübertragung die Kapitel 4 LDAP komplizierte Darstellung mit ASN.1 (Abstract Syntax Notation One) durch einfache Daten-Strings ersetzt. 4.3 LDAP-Sitzung Wie läuft nun eine LDAP-Sitzung ab? LDAP verwendet einzelne Nachrichten, die zwischen Client und Server ausgetauscht werden. Innerhalb dieser Nachrichten übermittelt der Client an den Server, welche Operation er durchführen will. Der Server wiederum antwortet ihm mit den Ergebnissen einer Abfrage und ggf. einem Fehlerwert. Diese Nachrichten müssen nicht in strenger zeitlicher Reihenfolge erfolgen. Ein Client kann mehrere Nachrichten an den Server schicken. Jede erhält eine eindeutige Nachrichten-ID. Der Server kann dann in einer von ihm bevorzugten Reihenfolge antworten (normalerweise aber FIFO) und versieht seinerseits wieder jede Message mit der dazugehörigen Nachrichtennummer. LDAP arbeitet verbindungsorientiert auf TCP/IP - Basis. Also werden auch sämtliche hierfür notwendigen Verbindungsaufbau und -Abbauoperationen durchgeführt. Am Anfang einer jeden Verbindung steht eine Authentifizierung. Bei LDAP wird dieser Vorgang als "bind" bezeichnet. Am Verbindungsende wird folglich ein "unbind" durchgeführt. Der Bind-Vorgang dient zur Überprüfung, welche Rechte einem Client auf dem Server zugestanden werden. Schritt Aktion Richtung 1 Beglaubigungswunsch (BIND) Client Server 2 Ergebnis der Beglaubigung Server Client 3 Senden der Anfragen Client Server 4 Ergebnis-Daten der Anfragen Server Client 5 Ergebnis-Code der Anfragen (Fehlerwert) Server Client 6 Verbindungsende signalisieren (UNBIND) Client Server 7 Verbindung beenden Server Client Tabelle 4-1 Ablauf einer LDAP-Sitzung 4.4 Suchen mit LDAP LDAP- Client TCP/IP Abbildung 4-2 Standalone LDAP LDAP- Server Verzeichnis Bei der Suche überträgt der Client an den Server den Namen aller Attribute, die er als Ergebnis zurückerhalten möchte. Zusätzlich übermittelt er den Context in dem er suchen will. Der Context ist ein DN. Eine Suche erfolgt innerhalb des Teilbaums, der von diesem DN angegeben ist. Ausserdem gibt er sein Suchkriterium bekannt. Bei LDAP können im Vergleich zu anderen Protokollen wie beispielsweise HTTP gleich mehrere Abfragen abgeschickt werden. Der Server schickt dann im folgenden die Ergebnisse aller Anfragen markiert mit der entsprechenden Nachrichtennummer zurück. Am Ende übermittelt er noch einen Ergebniscode, anhand dessen der Client entscheiden kann, ob seine Anfrage erfolgreich war. Hat ein Server in seinem Teilbaum die abgefragte Information nicht, sondern nur einen Verweis auf welchem Server sich diese Information befinden könnte, so gibt es unterschiedliche Varianten, wie der Server reagieren kann. Bis einschließlich Version 2

11 Kapitel 4 LDAP des Protokolls hat der Server von sich aus eine Verbindung mit dem zuständigen Server aufgebaut und dort die notwendige Information abgefragt. Seit Version 3 besteht die Möglichkeit, dass der Server dem Client einfach mitteilt, dass er nicht zuständig ist. Er übermittelt die notwendige Adresse des richtigen Servers weiter. 4.5 Der LDAP-Server Im folgenden soll die Mächtigkeit eines speziellen LDAP-Servers ein wenig näher betrachtet werden. Es handelt sich um den sehr weit verbreiteten "SLAPD" aus dem OpenLDAP-Projekt Zugriffskontrolle SLAPD beinhaltet ein sehr fein einstellbares System zur Zugriffskontrolle. Der Zugriff gestaltet sich in der Konfiguration immer nach dem Schema: Zugriff auf <was> von <wem> <mit welchen Rechten>. Für <was> können Attributwerte, DNs oder LDAP- Filterregeln angeben. Darüber hinaus gibt es die Möglichkeit zu entscheiden, ob nur das Objekt selber oder der gesamte Teilbaum betroffen sein soll. Bei dem <wem> Feld gehen die Möglichkeiten der Einstellung über die einer reinen Benutzerauthentifizierung weit hinaus. Neben DNs aus dem Verzeichnisbaum kann auch noch danach gefiltert werden, auf welchem Weg die Verbindung aufgebaut wurde (Socket, TCP/IP, Quell-IP-Adresse) oder welche Verschlüsselung verwendet wird. Gerade noch als Experimental und wahrscheinlich in der nächsten Version des Servers fest eingebaut ist eine Filterung nach den Zuständen eines Attributs. Bei der Zuteilung der Rechte werden unterschiedliche Stufen zur Verfügung gestellt. Diese gehen von kein Zugriff über Authentifizierung, Vergleichen, Suchen, Lesen bis hin zum Schreiben. Kein Zugriff muss vermutlich nicht näher erläutert werden. Interessant ist vor allem die Unterscheidung zwischen Authentifizierung und Vergleichen. Ist nur das Feld Authentifizierung gesetzt, so ist ein Zugriff auf das entsprechende Objekt nur während eines BIND-Zugriffes zulässig. Ein Vergleichen liefert stets nur ein Wahr oder Falsch zurück. Suchen lässt ein durchsuchen des Objekts (bzw. eines Teilbaumes) zu. Lesen erlaubt den Wert des Objekts direkt abzufragen. Schreiben muss natürlich wieder nicht näher erläutert werden Das Schema Bei der Einführung der X.500-Verzeichnisse war schon einmal die Rede von Objektklassen und Attributtypen. Welche hier existieren und was damit anzufangen ist, muss dem System bekannt gemacht werden. Der Client erhält die benötigten Informationen von seinem LDAP-Server. Aber der Server kann sie nicht aus dem Nirwana erraten. Um diesen mit der notwendigen Information zu versorgen, muss ein Schema vorhanden sein. Ein Schema besteht aus der Festlegung der Attributtypen und der Objektklassen. Wenn einem die zur Verfügung stehenden Schemata nicht ausreichen, kann man eigene Schemata erstellen. Dies geschieht in 5 Schritten: 1. Einen Objektidentifier (OID) wählen 2. Einen Namensprefix festlegen 3. eine Schema-Datei anlegen 4. benutzerdefinierte Attributtypen festlegen 5. benutzerdefinierte Objektklassen definieren Fangen wir bei dem ersten Schritt an. Was ist diese OID? Nun, sie stellt eine weltweit eindeutige Identifikation eines Schemaelements dar. Diese OIDs sind hierarchisch aufgebaut und werden von der IANA vergeben. Jeder kann seinen eigenen Namespace kostenlos bei der IANA beantragen. Die einem zugeschickte Nummernfolge ist quasi das Prefix für weitere eigene Definitionen. Als Beispiel sei hier

12 Kapitel 4 LDAP das NIS-Schema angeführt. Seine OID lautet xxxxxx. Die xxxx können anschließend frei vergeben werden. Die vorgegebenen Zahlen haben folgende Bedeutung: iso(1) org(3) dod(6) internet(1) directory(1) nisschema(1). Syntaxbeschreibungen finden sich dann unter Die Attributtypen wurden unter definiert und die Objektklassen unter Will man selber ein Schema erstellen, kann man zu Testzwecken den toten Namespace 1.1 verwenden, der für private Nutzung reserviert ist. Danach sollte man einen Namensprefix festlegen, der jedem Schemaelement mindestens einen eindeutigen Namen zuweist. Diese Namen sollten sich nicht mit den Bezeichnungen überschneiden, die in anderen Schemata definiert sind. Nachdem man eine neue Datei (3) angelegt hat, müssen in dieser nun die Attribute und Objektklassen festgelegt werden. Attribute werden gemäß RFC 2252 definiert. Grob kann man sagen, dass man Flags setzt. Diese sagen aus, ob von diesem Element ein anderes Element abgeleitet werden kann. Des weiteren welche Namen das Element hat, ob es nur einmal vorkommen darf, welchem Typ es entspricht (Integer, String) und welche Matching- Regeln bei der Suche ausschlaggebend sind (Exact Match oder unabhängig von der Gross- und Kleinschreibung). Objektklassen werden ebenfalls gemäß RFC 2252 definiert. Innerhalb dieser wird festgelegt, welche Attribute vorkommen dürfen, welche vorkommen müssen und welchen Status die Objektklasse selber besitzt Weitere Funktionalität SLAPD ist in der Lage, mehrere Datenbanken unabhängig voneinander zu verwalten. Außerdem gibt es Möglichkeiten auf andere Datenbanktypen zuzugreifen oder LDAP- Anfragen an den Userspace weiterzuleiten. So können die LDAP-Befehle zum Beispiel auf Shellprogramme oder auf Perl umgeleitet werden. Ebenfalls in SLAPD integriert sind sämtliche notwendige Funktionen, die die Partitionierung und Replizierung eines X.500-Verzeichnisses unterstützen

13 Kapitel 5 Zusammenfassung 5 Zusammenfassung Über LDAP ließe sich sehr viel schreiben. Denn dank eines einfach zu implementierenden Protokolls sind die Programme mannigfaltig, die ihre Konfiguration über LDAP beziehen. Die Gestaltungsbreite auf der Anwendungsebene ist enorm. Es beginnt bei einer einfachen Adressbuchfunktion (z.b. kann Outlook mit LDAP umgehen) und geht über die Konfiguration von Passwörtern für FTP-Server (z.b. ProFtp) bis hin zu sämtlichen Anwendungen die PAM unterstützen. So ist es denkbar, über LDAP die komplette Benutzerverwaltung einer Universität laufen zu lassen. Das würde bedeuten, dass jeder der sich immatrikuliert einmal einen immer geltenden Benutzeraccount zugeordnet bekommt. Es würde dann der zweite oder dritte zu merkende Account für diverse Praktika entfallen. Trotzdem bliebe die Möglichkeit unterschiedliche Passwörter zu vergeben. So könnte ein anderes Passwort haben (nachdem dieses auch meistens im Klartext übertragen wird), als der Login im lokalen Netz oder der per Einwahl. Genauso kann beispielsweise auch noch der Zutritt zu Räumen darüber geregelt werden, indem jeder Benutzer seine Keykarte in den Account des LDAP-Baums mit eingetragen bekommt. Die Stärke von LDAP zeigt sich aber genaugenommen nicht im Protokoll an und für sich, sondern in der großen Flexibilität des im Hintergrund arbeitenden X.500- Verzeichnisses. LDAPs Verdienst war es auch, zum ersten Mal einen einfachen schnellen Zugriff auf diese Daten zu ermöglichen. Ein weiteres Merkmal ist die große Zahl an Schnittstellen, die zumindest die LDAP- Server-Implementierung unter UNIX bietet. So ist es möglich, direkt Programme einzuklinken, die Anfragen bearbeiten. So könnte ein Perlskript dafür sorgen, dass manche Daten dynamisch und in Echtzeit generiert werden und dennoch immer über den gleichen DN abgreifbar sind. Das ganze bleibt transparent für den Benutzer. Des weiteren ist es extrem praktisch, dass für sehr viele Programmierer und Skriptsprachen fertige Bibliotheken existieren, die den Zugriff auf das Verzeichnis automatisch erledigen. So kann man Clients für PHP ebenso finden wie für Perl oder C/C++. Für jeden der sich näher dafür interessiert, sei empfohlen den Dienst an sich einfach auszuprobieren. Es empfiehlt sich hierbei auf alle Fälle bei vorbeizuschauen. Dort findet sich eine Anleitung zum schnellen Start mit LDAP. Leider lässt die Anleitung zur eigenen Erstellung von Schemata ein wenig zu wünschen übrig. Doch genau damit ist die große Flexibilität zu erreichen die LDAP ausmacht. Es führt daher kein Weg daran vorbei, einiges selbst auszuprobieren und damit Erfahrungen zu sammeln

14 6 Notationen und Abkürzungen Kapitel 6 Notationen und Abkürzungen API Application Programmer s Interface ASN.1 Abstract Syntax Notation One CES case exact string. Attribut, das zwischen Groß- und Kleinschreibung unterscheidet CIS case ignore string. Attribut, das nicht zwischen Groß- und Kleinschreibung unterscheidet CN Siehe COMMON NAME Common Name Attribut, das den Namen eines Blattobjekts enthält DAP Directory Access Protocol (X.500) Ursprüngliches Protokoll, das für die Kommunikation mit dem Verzeichnisdienst verwendet wurde DDNS Dynamic Domain Name Service DISP Directory Information Shadowing Protocol DIT Directory Information Tree DN Distinguished Name; gibt die Position eines Objekts im Verzeichnisdienst an DNS Domain Name Service DOP Directory Operational Binding Management Protocol DS Directory Service (Verzeichnisdienst) DSA Directory System Agents DSP Directory System Protocol DUA Directory User Agent FIFO First In First Out HTTP Hypertext Transmission Protocol IANA The Internet Assigned Numbers Authority IP Internet Protocol ITU International Telecommunication Unit LAN Local Area Network LDAP Lightweight Directory Access Protocol Objekt Eintrag in einem Verzeichnisdienst Objektklasse Typ eines Objekts OID Object Identifier; numerische Kennung eines Objekts OSI Open Systems Interconnect (7 Schichten 7: Applikation; 6:Presentation; 5:Session; 4:Transport; 3:Network; 2:Data Link 1:Physical) RDN relative distinguished name Referral Verbindet die Partitionen eines DS-Tree RFC Request for Comment Schema Struktur eines Verzeichnisdienstes mit allen möglichen Einträgen und Eigenschaften SLAPD Standalone LDAP Subtree Alle Objekte unterhalb eines Containers Suffix Beschreibt den Subtree, dessen Daten ein LDAP- Server in seiner Datenbank gespeichert hat TCP transmission control protocol

15 7 Abbildungsverzeichnis Kapitel 7 Abbildungsverzeichnis Abbildung 2.1 Das Mc King Verzeichnis Seite 5 Abbildung 3.1 Replikation und Partitionierung Seite 6 Abbildung 3.2 Ein X.500 Verzeichnisbaum Seite 7 Abbildung 4.1 LDAP als X.500 Gateway Seite 9 Abbildung 4.2 Standalone LDAP Seite 10 8 Tabellenverzeichnis Tabelle 3.1 Benutzerzugriff bei X.500 Seite 7/8 Tabelle 4.1 Ablauf einer LDAP-Sitzung Seite 10 9 Literaturverzeichnis [1] Jens Banning: LDAP unter Linux, Netzwerkinformationen in Verzeichnisdiensten verwalten. Addison-Wesley Verlag, München, 2001 [2] Lightweight Directory Access Protocol (v3), Request for Comment 2251, 1997 [3] [4]