\documentclass[a4paper,11pt]{article} \usepackage{ngerman} \usepackage[latin1]{inputenc} \setlength\parskip{\medskipamount} \setlength\parindent{0pt} \begin{document} % LDAP % Copyright Thomas Bendler, Steffen Dettmer % Lizenz: GFDL % % $Name: $ % $Revision: 1.5.2.15 $ % $Source: /cvsroot/selflinux/tutorial/advanced/netzwerk_advanced/ldap/ldap,v $ % SelfLinux-0.7.2 % % Diese Datei ist Teil von SelfLinux http://www.selflinux.de % %%% $Id: ldap,v 1.5.2.15 2002/12/01 17:46:40 std Exp $ \title{Das Lightweight Directory Access Protocol} \author{Thomas Bendler} %\url{mailto:project@bendler-net.de} \author{Steffen Dettmer} %\url{mailto:steffen@dett.de} \maketitle %\ref{../index.tex} %\ref{netzwerk_basic1.tex} Linux im Netzwerk - Einführung \ref{LDAP} \par{Layout} Torsten Hemm %\url{mailto:T.Hemm@gmx.de} Steffen Dettmer %\url{mailto:steffen@dett.de} \par{Lizenz} GFDL \tableofcontents{} \section{Prolog} \label{d40e69} \par Die von mir beschriebene Installation bezieht sich auf die aktuelle Debian-Distribution Version 2.2 (Potato). Um eine möglichst distributionsunabhängige Installation zu beschreiben, beziehe ich mich auf die Installation des Tarballs unter {\bf /usr/local}. Sollte ein distributionsabhängiges Binär-Paket verwendet werden, sind ggf. die Pfade anzupassen. \subsection{Lizenz} \label{d40e80} \par Dieses Dokument ist urheberrechtlich geschützt. Das Copyright liegt bei Thomas Bendler. \linebreak Das Dokument darf gemäß der GNU General Public License verbreitet werden. Insbesondere bedeutet dies, dass der Text sowohl über elektronische wie auch physikalische Medien ohne die Zahlung von Lizenzgebühren verbreitet werden darf, solange dieser Copyright-Hinweis nicht entfernt wird. Eine kommerzielle Verbreitung ist erlaubt und ausdrücklich erwünscht. Bei einer Publikation in Papierform ist der Autor hierüber zu informieren. \subsection{Bezugsquellen} \label{d40e91} \par Die aktuelle Version des ''OpenLDAP''-Paketes findet sich unter ftp://www.openldap.org/pub/OpenLDAP/ Distributionsabhängige Pakete finden sich in der Regel auf den beigelegten CDs respektive auf den FTP-Servern des jeweiligen Distributors. \subsection{Literatur} \label{d40e103} \par Da ich weder Lust noch Zeit habe, das ''OpenLDAP''-Paket bis ins letzte Detail zu beschreiben, verweise ich bei weiterführenden Fragen auf die gelistete Literatur. \subsubsection{Bücher} \label{d40e111} \par \begin{list}{*}{} \item Jens Banning, ''LDAP unter Linux - Netzwerkinformationen in Verzeichnisdiensten verwalten'', Addison-Wesley, geb., 250Seiten, DEM 79,90, ISBN 3-8273-1813-0 \item ''Implementing LDAP'' by Mark Wilcox \item ''Programming Directory-Enabled Applications with Lightweight Directory Access Protocol'' by Howes and Smith \item ''Understanding and Deploying LDAP Directory Servers'' by Howes, Smith and Good \end{list} \subsubsection{RFC's} \label{d40e135} \par \begin{list}{*}{} \item RFC 1558: A String Representation of LDAP Search Filters \item RFC 1777: Lightweight Directory Access Protocol \item RFC 1778: The String Representation of Standard Attribute Syntaxes \item RFC 1779: A String Representation of Distinguished Names \item RFC 1781: Using the OSI Directory to Achieve User Friendly Naming \item RFC 1798: Connectionless LDAP \item RFC 1823: The LDAP Application Programming Interface \item RFC 1959: An LDAP URL Format \item RFC 1960: A String Representation of LDAP Search Filters \item RFC 2251: Lightweight Directory Access Protocol (v3) \item RFC 2307: LDAP as a Network Information Service \end{list} \subsubsection{Adressen im Internet} \label{d40e180} \par \begin{list}{*}{} \item OpenLDAP HomePage \linebreak http://www.openldap.org \item Einführung im Linux Magazin \linebreak http://www.linux-magazin.de/ausgabe/1998/09/LDAP/ldap.html \item slapd und slurpd Administrator's Guide \linebreak http://www.umich.edu/\~{}dirsvcs/ldap/doc/guides \item Introducing to Directory Service (X.500) \linebreak http://www.nic.surfnet.nl/surfnet/projects/x500/introducing \item Linux Directory Service unter \linebreak http://www.rage.net/ldap/ \end{list} \subsection{Haftung} \label{d40e233} \par Für die hier vorgestellten Verfahren übernehme ich keine Haftung. Sollten sich Fehler eingeschlichen haben oder Verfahren nicht funktionieren, bitte ich um Feedback (Adresse siehe unten). \subsection{Feedback} \label{d40e242} \par Bei Fragen und Kommentaren zu diesem Dokument sowie bei Anregungen und Verbesserungsvorschlägen wenden Sie sich bitte an den Maintainer Steffen Dettmer \section{Eine kleine Einführung in LDAP} \label{d40e258} \subsection{Was ist LDAP?} \label{d40e263} \par {\bf LDAP} ist die Abkürzung von ''{\bf L}ightweight {\bf D}irectory {\bf A}ccess {\bf P}rotocol''. Das LDAP entstand ursprünglich als Front-End für den X.500-Verzeichnisdienst. Da X.500 als kompletter OSI-Stack implementiert ist, war es nicht möglich, diesen Verzeichnisdienst flächendeckend zu implementieren. LDAP ist ein Verzeichnisdienst, der auf dem TCP/IP-Protokoll basiert und somit ressourcenschonender für die Netzwerk-Infrastruktur ist. Obwohl LDAP nur einen Teil der Funktionen des DAP zur Verfügung stellt, reicht es aus, um die fehlenden Funktionen vollständig zu emulieren. Basis für LDAP sind die im Abschnitt {\bf Literatur} aufgeführten RFC's. \subsection{Welche Informationen kann LDAP zur Verfügung stellen?} \label{d40e290} \par LDAP speichert seine Informationen in einer Baumhierarchie. Diese Hierarchie kann diverse Informationen enthalten. Einen Überblick verschafft RFC 2307, in dem mögliche Inhalte der LDAP Hierarchie spezifiziert sind: \begin{list}{*}{} \item Benutzer \item Gruppen \item IP-Dienste \item IP-Protokolle \item RPC's \item NIS-Netzwerkgruppen \item Boot-Informationen \item Einhängepunkte für Dateisysteme \item IP-Hosts und Netzwerke \item RFC 822 konforme Mail-Aliase \end{list} \subsection{Strukturierung der Informationen} \label{d40e332} \par Hat man Daten in Datenbanken, so ist es wichtig, diese Informationen zu strukturieren. Besonders, wenn viele verschiedene Clients auf die Datenbank zugreifen wollen, zum Beispiel Netscape, Outlook und andere, muss die Struktur genau definiert sein. Wenn ein Mailclient eine eMail-Adresse braucht, muss er wissen, wie er diese bekommt. \par Es gibt viele Definitionen, an die man sich halten muss, soll am Ende auch etwas funktionieren. Bei LDAP werden Objekte mit Eigenschaften verwendet. Jedes Objekt hat zunächst einen eindeutigen Namen, an dem es von allen anderen unterschieden werden kann (''distinguished name'', kurz: DN). Die Eigenschaften eines Objekts hängen davon ab, zu welcher Klasse es gehört (es kann sogar zu mehreren Klassen gehören). \subsubsection{Klassen von Objekten} \label{d40e343} \par Es sind nun Klassen für Personen definiert. Zu einer Person (''person'') gehören zwingend {\bf objectClass} (die Objektklasse selbst), {\bf sn} (der Nachname) und {\bf cn} (commonName, etwa: üblicher Name, hier wird üblicherweise Vor- und Nachname verwendet). Zusätzlich gibt es optionale Attribute, die nicht unbedingt angegeben werden müssen. Diese sind hier {\bf description} (beliebige Beschreibung), {\bf seeAlso} (verweist auf ein anderes Objekt), {\bf telephoneNumber} (Telefonnummer), {\bf userPassword} (ein Password). Da häufig noch mehr Attribute mit einer Person verknüpft sind, gibt es auch eine Objektklasse organizationalPerson. Diese hat die gleichen geforderten Eigenschaften wie Person, aber erlaubt viele optionale Eigenschaften, wie zum Beispiel Felder der Adresse und eine FAX-Nummer. Es gibt noch mehr Klassen, zum Beispiel {\bf newPilotPerson} (die als optionale Eigenschaft eine eMail-Adresse {\bf mail} einführt) und natürlich Klassen für Organisationen/Firmen, Abteilungen, Bilder, Dokumente, Geräte und so weiter. \subsubsection{Eigenschaften von Klassen} \label{d40e379} \par Wenn man also irgendwo eine Person im Verzeichnis hat, ist klar, dass diese ein {\bf cn} haben muss, und eine Telefonnummer haben kann (und dass diese genau {\bf telephoneNumber} heißt). Soll ein Programm eine eMail-Addresse suchen, muss es nur nachschauen, ob es ein Attribut {\bf mail} gibt. Es kann eben nicht sein, dass diese Eigenschaft {\bf email} oder anders heißt. {\bf mail} ist vorgeschrieben, und nichts anderes. \par An diesem Beispiel kann man zeigen, dass eine natürliche Person zu mehreren Klassen gehört: {\bf person}, {\bf organizationalPerson} und {\bf newPilotPerson}. Eine weitere Klasse ist {\bf top}. Im Prinzip gehört so ziemlich jedes Objekt auch zur Klasse {\bf top}, die lediglich vorschreibt, dass die Eigenschaft {\bf objectClass} gesetzt sein muss (was bei allen Personenklassen ohnehin gefordert ist). \par Durch das Verwenden der Klassen definiert man, welche Eigenschaften vorhanden sein müssen, und welche vorhanden sein können. Eine Person darf zum Beispiel keine Farbtiefe haben, ein Bild hingegen schon. Verwendet man mehrere Klassen, so muss das entsprechende Objekt alle von mindestens einer Klasse geforderten Eigenschaften haben, und kann alle insgesamt erlaubten Eigenschaften haben. \subsubsection{Typen von Eigenschaften} \label{d40e427} \par Den Eigenschaften sind Typen zugeordnet. Es gibt Typen, die eine Zeichenkette enthalten, und andere, die eine Telefonnummer enthalten. Diese Typen definieren weiterhin, wie Werte verglichen (und damit sortiert und gesucht) werden. Zeichenketten beispielsweise kann man abhängig von Groß- und Kleinschreibung vergleichen oder auch nicht. Bei Telefonnummer spielen gewisse Füllzeichen möglicherweise keine Rolle. Passwörter hingegen müssen genau übereinstimmen. \par Es gibt nun also Objekte (die zu bestimmten Klassen gehören). Diese werden nun anderen Objekten untergeordnet (beziehungsweise werden anderen Objekte viele zugeordnet, dies ist die richtige Reihenfolge). Diese baumartige Struktur kann man (mit etwas Phantasie) auch in der Realität finden: In Ländern gibt es Firmen, in Firmen gibt es Abteilungen und in Abteilungen letztlich Personen. So wird das in LDAP auch gesehen. Die Baumstruktur wird hier ''Directory Information Tree'' genannt, kurz {\bf DIT}. Es gibt Länder (also Objekte der Klasse {\bf country} [Land]) mit u.A. der Eigenschaft {\bf c} (kurz für country), Firmen ({\bf organisation}s mit der Eigenschaft {\bf o}), Abteilungen (Organisations Einheit, {\bf organisationalUnit} mit der Eigenschaft {\bf ou}). Hierbei enthalten diese Objekte normalerweise viele weitere Eigenschaften; eine Firma hat zum Beispiel eine Postanschrift. \subsubsection{Schema} \label{d40e460} \par Ein Schema ist eine Sammlung von Strukturdefinitionen. Dazu gehören die Schreibungen vieler Klassen und der verwendeten Typen. Es gibt verschiedene Schemata, und es ist möglich, eigene zu definieren (oder bestehende zu erweitern) was jedoch nicht interoperabel mit anderen Diensten sein muss. Das ist außerhalb der Betrachtungen dieses Dokumentes. \subsubsection{Zusammenfassung} \label{d40e469} \par Der LDAP-Server speichert seine Informationen in einer baumartigen Struktur. Diese wird auch ''Directory Information Tree'' genannt, kurz {\bf DIT}. \par Zum Speichern benutzt der LDAP-Server Objekte, die er mit Attributen versehen kann. Dadurch kann man die Struktur flexibel an die eigenen Bedürfnisse anpassen. Das RFC 2256 spezifiziert die Standard-Objekte des LDAP-Servers. Man wird zwar von niemandem gezwungen, diese Vorgaben auch zu benutzen. Um aber eine möglichst große Konformität zu erzielen, sollte man diese Vorgaben einhalten. \section{Technische Daten des LDAP Server} \label{d40e486} \par Der Zugriff auf den LDAP-Server erfolgt über das LDAP-Protokoll via TCP/IP. Per Default lauscht der {\bf slapd} (''Stand-alone LDAP Daemon'': Der LDAP-Dienst) auf dem Port 389. Dies ist im RFC 1777 spezifiziert. \section{Installation des OpenLDAP} \label{d40e501} \par Beschrieben wird im folgenden die Installation des OpenLDAP in der Version 1.2.1. Die Installation zukünftiger Releases sollte nicht grundlegend von der hier vorgestellten Methode abweichen. Sollte dies trotzdem der Fall sein, werde ich das in zukünftigen Versionen dieses Dokumentes berücksichtigen. \subsection{Quellen für den OpenLDAP-Server} \label{d40e509} \par Der Quellcode der aktuellen Version des OpenLDAP-Servers in einem komprimierten Archiv findet sich auf der Homepage der OpenLDAP Foundation. Die aktuellen Quellen können von ftp://ftp.OpenLDAP.org/pub/OpenLDAP/openldap-release.tgz bezogen werden. \linebreak Eine einfachere Möglichkeit der Installation bieten sogenannte rpm/deb-Archive. Dies sind bereits kompilierte Pakete, die auf die Besonderheiten der jeweils eingesetzten Distribution zugeschnitten sind. Die jeweilige Installationsprozedur entnehmen Sie bitte Ihrem Handbuch. \subsection{Installation des OpenLDAP-Servers} \label{d40e523} \par Haben Sie den OpenLDAP mit Hilfe der distributionseigenen rpm/deb-Archive installiert, können Sie diesen Abschnitt auslassen. \par Wenn Sie sich die Quellen des OpenLDAP-Servers gezogen haben, müssen Sie diese noch installieren. Zu diesem Zweck kopieren sie die Quellen nach ''/usr/local/src/'' und entpacken sie die Quellen mit dem Befehl {\bf tar xvfz ./openldap-release.tgz} \par Anschließend müssen Sie mit {\bf cd ldap} in das Installationsverzeichnis wechseln. Dort befindet sich die Datei {\bf include/ldapconfig.h.edit}. In ihr kann man den LDAP an die eigenen Bedürfnisse anpassen. In der Regel sollten aber die voreingestellten Werte in Ordnung sein. Das ''OpenLDAP'' Paket wird per Default nach {\bf /usr/local/} installiert. \linebreak Nun geht es ans Übersezten und Installieren des Programmpaketes. Führen Sie dazu folgende Befehle aus: \begin{tt} \begin{scriptsize} user@linux / \$ configure \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux / \$ make depend \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux / \$ make \end{scriptsize} \end{tt} \linebreak \par Um die Kompilation zu testen, können noch folgende Anweisungen ausgeführt werden: \begin{tt} \begin{scriptsize} user@linux / \$ cd test \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux / \$ make \end{scriptsize} \end{tt} \linebreak \par Die Installation des Paketes muss als Superuser (root) mit folgendem Befehl erfolgen: \begin{tt} \begin{scriptsize} user@linux / \$ su \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux / \$ make install \end{scriptsize} \end{tt} \linebreak \par That's it. \linebreak Nun sollte der OpenLDAP-Server installiert sein. \subsection{Besonderheiten von RPM-Packeten} \label{d40e593} \par Es gibt Unterschiede zwischen dem Orginal-OpenLDAP-Paket und den rpm-Archiven (hier am Beispiel von SuSE). \par Die beiden Pakete sind zwar nach der Installation inhaltlich fast identisch, unterscheiden sich aber gravierend in den verwendeten Pfaden. Folgende Übersicht soll die Unterschiede verdeutlichen: \par OpenLDAP-Original in der Default-Konfiguration: \linebreak \begin{list}{*}{} \item {\bf /usr/local/etc/openldap/} Konfigurationsdateien \item {\bf /usr/local/bin/} Hilfsdateien \item {\bf /usr/local/sbin/} Server \item {\bf /usr/local/src/ldap/doc/} Dokumentation \item {\bf /usr/local/include/} Include-Dateien \item {\bf /usr/local/lib/} Bibliotheken \item {\bf /usr/local/share/} Dateien für X.500 Gateway \item {\bf /usr/local/var/openldap-ldbm/} Datenbankdateien \end{list} \par SuSE rpm-Archive Konfiguration: \begin{list}{*}{} \item {\bf /etc/openldap/} Konfigurationsdateien \item {\bf /usr/bin/} Hilfsdateien \item {\bf /usr/libexec/openldap/} Server \item {\bf /sbin/init.d/ldap} Startskript \item {\bf /usr/doc/packages/openldap/} Dokumentation, zusätzliche Tools \item {\bf /usr/include/} Include-Dateien \item {\bf /usr/lib/} Bibliotheken \item {\bf /usr/share/openldap/} Dateien für X.500 Gateway \end{list} \section{Anpassen der Konfigurationsdateien} \label{d40e719} \par Mit dem OpenLDAP-Server werden mehrere Konfigurationsdateien ausgeliefert, die teilweise noch an die lokalen Gegebenheiten angepasst werden müssen. \subsection{Liste der Konfigurationsdateien} \label{d40e727} \par \begin{list}{*}{} \item {\bf ldap.conf} -- Client Konfiguration \item {\bf ldapfilter.conf} -- Filterregeln \item {\bf ldapsearchprefs.conf} -- Bevorzugte Suchkriterien \item {\bf ldaptemplates.conf} -- Templates für Formulare \item {\bf slapd.conf} -- Server Konfiguration \item {\bf slapd.at.conf} -- Beschreibung der Attribute \item {\bf slapd.oc.conf} -- Beschreibung der Objektklassen \end{list} \par Zusätzlich zu den dem Paket beiliegenden Konfigurationsdateien gibt es nochmal denselben Satz mit der Endung ''*.default''. Diese kann man getrost löschen oder sich in ein extra Verzeichnis kopieren um evtl. nochmal die möglichen Einstellungen überprüfen zu können. \subsection{Konfigurieren der ldap.conf} \label{d40e784} \par In der Datei ldap.conf wird die Basis-Domain für den LDAP-Client festgelegt. Für das folgende Beispiel im Abschnitt ''Erstellen eines Beispielverzeichnisses'' wird die Basisadresse mit der Domain gleichgesetzt. Das weicht von dem vielleicht intuitiveren ''Land-Organisation-Organisationseinheit''-Schema ab, schafft dafür aber ''private'' Namensräume. Dies löst folgendes Problem: Wenn Firma A Firma B in Ihrem LDAP listet, kann es Herrn Meier aus B im LDAP von Firma A und dem von Firma B geben. Beide Meiers sind der gleiche, haben den gleichen eindeutigen Namen (DN); jedoch sind es verschiedene Objekte (in Firma B kann Herr Meier ein Passwort haben, das Firma A nicht kennt!). \par Deshalb hat man sich überlegt, dass Firmen einfach ihren Internet-Domainnamen verwenden können, um ihre Namen zu bilden. Diese werden {\bf dc} (Domain Component, Domainkomponente) genannt. {\bf selflinux.de} besteht zum Beispiel aus den Komponenten {\bf selflinux} und {\bf de}, also {\bf dc=selflinux,dc=de} (Ansonsten würde man {\bf c=DE,o=Bendler Projekte} oder sowas verwenden, was jedoch eigentlich international vergeben werden müßte). \begin{tabular}{|l|} \hline \begin{tt} /usr/local/etc/openldap/ldap.conf\end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} # /usr/local/etc/openldap/ldap.conf # # Thomas Bendler, 19.06.2000, 17:05:06 # # Bitte beachten Sie auch ldap.conf(5) # Diese Datei sollte fuer alle lesbar sein # BASE dc=selflinux,dc=de HOST voyager.bendler.net \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Was bewirkt die hier vorgestellte {\bf ldap.conf}? Mit der Variable BASE wird der standardmäßig abgefragte Teilbaum festgelegt. Hier bedeutet das, alle Anfragen sind unterhalb von {\bf dc=selflinux,dc=de} durchzuführen. Dies wird häufig ''Suchbasis'' (Searchbase) genannt. Die Variable {\bf HOST} gibt den Server an, der standardmäßig abgefragt wird. Über die Variable PORT kann alternativ auch ein anderer Default Port eingestellt werden. \subsection{Konfiguration der slapd.conf} \label{d40e835} \par Die Datei {\bf slapd.conf} enthält die Einträge für die Konfiguration des slapd Standalone-Server. Der slapd beantwortet die LDAP Anfragen der Clients - es ist der LDAP-Server oder Verzeichnis-Server. Für das folgende Beispiel bekommt die Datei folgenden Inhalt: \begin{tabular}{|l|} \hline \begin{tt} /usr/local/etc/openldap/slapd.conf \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} # /usr/local/etc/openldap/slapd.conf # # Thomas Bendler, 27.06.2000, 15:37:02 # überarbeitet von Steffen Dettmer, 2001 # # Bitte beachten Sie auch sldapd.conf(5) # # Modifizierte Version der slapd.conf aus # dem Debian OpenLDAP Packetes # http://www.debian.org/ # # # -- Einzubindende Dateien -- # # Schema und ObjectClass Definitionen include/usr/local/etc/openldap/slapd.at.conf include/usr/local/etc/openldap/slapd.oc.conf # Schema und ObjectClass Definitionen fuer Netscape Roaming include/usr/local/etc/openldap/netscape_roaming.at.conf include/usr/local/etc/openldap/netscape_roaming.oc.conf # Schema for supporting Debian Package Directory entries #include/usr/local/etc/openldap/debian.at.conf #include/usr/local/etc/openldap/debian.oc.conf # # -- Servereinstellungen -- # # Wenn Schemacheck auf ";on" gesetzt wird, wird bei der Modifizierung # mit Hilfe von "ldapadd" ueberprueft, ob die Eintraege in Objektklassen # spezifizert sind. # In Produktion sollte dies auf "on" gesetzt werden, um zu # vermeiden, dass "falsche" Eigenschaften (zum Beispiel # Nachname eines Landes) gesetzt werden können. schemacheck off # Wenn lokal nichts gefunden wird frage folgenden Rechner # Dieser gilt nur bei eingetragener Domain referral ldap://root.openldap.org # Prozess ID und Log Level, siehe auch man slapd.conf pidfile /var/run/slapd.pid argsfile /var/run/slapd.args loglevel 256 # # -- Datenbankeinstellungen -- # # Welche Datenbank wird benutzt und wo ist sie gespeichert database ldbm directory "/usr/local/var/openldap-ldbm" # Basis Domain (unser "root") suffix "dc=selflinux,dc=de" # Aenderungen werden mit Datum versehen # Achtung, erfordert bestimmte Klassen! lastmod on # # -- Indizierung -- # # Art der Indizierung in der Datenbank index cn pres,eq,approx,sub index objectclass pres,eq index default none # # -- Zugriffskontrolllisten -- # #Man kann hier einen Manager global definieren. Das ist zum # Beispiel zum Anlegen der initialen Daten sinnvoll #rootdn "cn=Manager,dc=selflinux,dc=DE" #rootpw geheim> # Standardrechte gibts nicht defaultaccess none # Die Manager (Administratoren) bekommen Zugriff auf das gesamte # Verzeichnis: access to * by group/organizationalRole/roleOccupant="cn=Manager, dc=selflinux, dc=de" write by group/organizationalRole/roleOccupant="cn=Manager, dc=selflinux, dc=de" read by group/organizationalRole/roleOccupant="cn=Manager, dc=selflinux, dc=de" search # Das eigene userPassword kann von einem Benutzer geaendert # werden. Die anderen Nutzer koennen es vergleichen (d.h. prüfen) access to attr=userpassword by self write by group="cn=Manager,dc=selflinux,dc=de" write by * compare # Jeder eingetragene Benutzer darf lesen, der Rest # darf nichts access to * by self write by dn=".+" read by * none \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Was bewirkt die hier vorgestellte slapd.conf? \par Die include-Anweisungen bewirken ein Einbinden der angegebenen Dateien. In diesem Fall werden Objektklassen (oc) und deren Attribute (at) eingelesen. Die ''Netscape Roaming''-Dateien gehören nicht zum Standard-Umfang des LDAP-Tarballs. Sie können auf meiner Homepage unter http://www.bendler-net.de/projects/config/ldap-config.tar.gz runtergeladen werden. \par Mit dem schemacheck wird überprüft, ob modifizierte oder neu installierte Daten den Regeln der Objektklassen entsprechen. In produktiven Systemem sollte das immer auf ''on'' stehen. Dabei werden leider nur Objektklassen geprüft, die LDAP in einer Konfigurationsdatei wie zum Beispiel slapd.oc.conf bekannt sind. Bei allen anderen Klassen akzeptiert der Server leider alle Attribute. \par Ist der LDAP-Server nicht in der Lage, eine Anfrage zu beantworten, fragt er den unter {\bf referral} angegebenden LDAP-Server. \par Die Zeilen {\bf pidfile} und {\bf argsfile} sind für den laufenden Betrieb (pid=prozess id, args=argumente). \par Mit dem Schlüsselwort {\bf database} wird festgelegt, welches Datenbankformat bzw. welche Datenbank benutzt wird. Es sind auch Abfragen von anderen Datenbanken möglich. Im {\bf directory} wird spezifiziert, wo die Datenbankdateien zu finden sind bzw. angelegt werden sollen. Unter Umständen muss dieses Verzeichnis noch nachträglich angelegt werden wenn z.B. ein kompiliertes Paket installiert wird, in dem das Verzeichnis nicht angelegt wird (war bei SuSE 6.2 der Fall, das hat sich mittlerweile jedoch geändert). \par Die unter {\bf suffix} angegebene Struktur legt fest, welche Anfragen über die lokale Datenbank beantwortet werden können. Der Suffix legt sozusagen den Namensraum des Verzeichnisses fest - hiermit wird also die ''Wurzel'' / ''Root'' festgelegt. \par Mit Hilfe der {\bf index}-Anweisung wird der Datenbank mitgeteilt, wie sie ihre Indizes anlegen soll. \par Zum Schluß werden noch die Zugriffsrechte auf dem LDAP-Server festgelegt. Standardmäßig erhält jeder Benutzer Lesezugriff. Die einzelnen Zugriffskontrolllisten (ACL, ''Access Control List'') entnehmen Sie bitte der Konfigurationsdatei. \subsection{Sonstige Konfigurationsdateien} \label{d40e907} \par Wie man bereits in der Konfigurationsdatei slapd.conf sehen kann, werden mehrere Konfigurationsdateien eingebunden, unter anderem {\bf slapd.at.conf} und {\bf slapd.oc.conf}. Diese Dateien sollten nicht geändert werden. Möchte man eigene Definitionen einbinden sollte das über gesonderte Dateien geschehen, z.B. {\bf slapd.local.at.conf} und {\bf slapd.local.oc.conf}. Die Dateien enthalten die Standard-Objektklassen und die Attribute für die Objektklassen. Die standardmäßig gegebenen Dateien sind für die meisten Anwendungen (Ausnahmen bestätigen die Regel, siehe auch ''Netscape Roaming'') ausreichend. Für weitere Informationen konsultieren Sie bitte die entsprechenden Manual-Pages. \linebreak Sollen die Benutzer ihre Einträge selbst verändern können, so empfielt sich noch eine Anpassung der ldaptemplates.conf an die eigenen Bedürfnisse. Sie stellt die Voreinstellungen zur Verfügung, die Programme geliefert bekommen, die auf den LDAP-Server zugreifen. \section{Erstellen eines Beispielverzeichnisses} \label{d40e934} \subsection{Erstellen der LDIF Dateien} \label{d40e939} \par Nach der Installation und Konfiguration des LDAP-Servers muss dieser mit Daten gefüttert werden. Das folgende Beispiel erklärt einen ''Directory Information Tree'' anhand einer Firma mit mehreren Abteilungen. Die einzelnen Felder müssen den lokalen Gegebenheiten nur angepaßt werden, um eine simple Konfiguration aufzusetzen. \linebreak Für das folgende Beispiel wird im Verzeichnis {\bf /usr/local/etc/openldap} das Unterverzeichnis {\bf ldif/} angelegt. In diesem Verzeichnis kann mit jedem x-beliebigen Editor, der ASCII unterstützt, eine Datei mit dem Namen struktur.ldif erstellt werden. Der Name und das Verzeichnis für die Beispiel-LDIF-Dateien sind beliebig. Es müssen für den Fall, dass andere Namen oder Pfade verwendet werden, diese nur an die lokalen Gegebenheiten angepaßt werden. \par Kommen wir aber nun zu der LDIF-Datei. Wir definieren einen neuen ''Namensraum'' {\bf selflinux.de}. In LDAP-''Sprache'' heißt das{\bf dc=selflinux,dc=de}. Alles, was definiert wird, spielt sich unter diesem Punkt ab, damit gibt es keine Konflikte mit anderen Verzeichnissen. \par Das Verzeichnis besteht zunächst aus einer Firma (bzw. Organisation) SelfLinux. Neben dieser Firma wird noch ein separater Eintrag eingerichtet, in dem die Administratoren (Manager) referenziert werden. Verzeichnis-Manager gehören also zu keiner Organisation oder Abteilung. Logisch gesehen ist das ja so auch korrekt. \par Die Firma Selflinux bekommt drei Abteilungen (''Unterorganisationen'') spendiert: Development, Sales und Support. Die Mitarbeiter werden dann mit den Abteilungen referenziert. Daraus ergibt sich folgende Struktur: \begin{tabular}{|l|} \hline \begin{tt} Struktur der Firma Selflinux \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} selflinux.de: | +-- Manager | +-- Selflinux | | +-- Development | | | +-- Mitarbeiter 1 (Thomas Bendler) | | | +-- Mitarbeiter 2 (Steffen Dettmer) | +-- Sales | | | +-- Mitarbeiter 4 (Sonja Essler) | +-- Support | +-- Mitarbeiter 3 (Thomas Lippert) \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Hat man keinen {\bf rootdn}-Eintrag in der {\bf slapd.conf}, sollte unbedingt ein Manager-Account in dieser Struktur mit angegeben werden, da ansonsten kein Schreib-Zugriff auf das Verzeichnis möglich wäre. \subsection{Beispiel LDIF struktur.ldif} \label{d40e989} \begin{tabular}{|l|} \hline \begin{tt} Beispiel LDIF: struktur.ldif \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} dn: cn=Manager, dc=selflinux, dc=de cn: Manager description: Directory Manager description: Verzeichnis-Manager objectClass: organizationalRole objectclass: top roleOccupant: cn=Thomas Bendler,ou=Development,dc=selflinux,dc=de roleOccupant: cn=Steffen Dettmer,ou=Development,dc=selflinux,dc=de dn: o=Selflinux,dc=selflinux,dc=de objectclass: top objectclass: domain objectclass: organization o: Selflinux l: Hamburg postalcode: 21033 streetadress: Billwiese 22 dn: ou=Development,o=Selflinux,dc=selflinux,dc=de objectclass: top objectclass: organizationalunit ou: Development dn: ou=Sales,o=Selflinux,dc=selflinux,dc=de objectclass: top objectclass: organizationalunit ou: Sales dn: ou=Support,o=Selflinux,dc=selflinux,dc=de objectclass: top objectclass: organizationalunit ou: Linux dn: cn=Thomas Bendler,ou=Development,o=selflinux,dc=selflinux,dc=de objectclass: top objectclass: person objectclass: organizationalperson objectclass: inetorgperson cn: Thomas Bendler sn: Bendler ou: Development mail:project@selflinux.de l: Hamburg postalcode: 21033 streetadress: billwiese 22 telephonenumber: 040-7654321 facsmiletelephonenumber: 040-7654321 userpassword: {CRYPT}saHW9GdxihkGQ dn: cn=Steffen Dettmer,ou=Development,o=Selflinux,dc=selflinux,dc=de cn: Steffen Dettmer sn: Dettmer ou: Development mail: steffen@dett.de telephoneNumber: +49 (30) 1234567 objectClass: person dn: cn=Sonja Essler,ou=Sales,o=Selflinux,dc=selflinux,dc=de cn: Sonja Essler sn: Essler ou: Sales mail: sonja@bendler-net.de telephoneNumber: +49 (30) 1234568 objectClass: person dn: cn=Thomas Lippert,ou=Support,o=Selflinux,dc=selflinux,dc=de cn: Thomas Lippert sn: Lippert ou: Support mail: tom@bendler-net.de telephoneNumber: +49 (30) 1234569 objectClass: person \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Das in diesem Beispiel eingesetzte Passwort {\bf {CRYPT}saHW9GdxihkGQ} wurde mit Hilfe von Perl erzeugt. Dazu muss in der Shell folgender Befehl eingegeben werden. Das Ergebnis wird auf dem Bildschirm angezeigt und muss 1:1 in die LDIF Datei übertragen werden. Dieser Aufruf ist exemplarisch und nur zum Testen geeignet, da ''salt'' konstant und nicht zufällig ist! {\bf perl -e 'print(''{CRYPT}''.crypt(''secret'',''salt'').''$\backslash$n'');' } \par Damit wird das Passwort in ein für den Server verständliches Format gebracht. Möchten sie ein anderes Passwort verwenden, müssen sie stattdessen das gewünschte einsetzen. Sie können es nachträglich mit dem Befehl {\bf ldappasswd} ändern. \par Es ist in der Praxis einfacher, sofort das Passwort mit ldappasswd zu setzen (es beim Erstellen der Ursprungsdatei erstmal wegzulassen, wie im Beispiel bei den anderen Personen). \par Falls man nicht über Rollen sondern Gruppen arbeiten möchte, kann man beispielsweise auch folgenden Manager-Eintrag benutzen: \begin{tabular}{|l|} \hline \begin{tt} Auszug LDIF struktur.ldif \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} dn: cn=Manager,dc=selflinux,dc=de cn=Manager objectclass: top objectclass: groupofnames member: cn=Thomas Bendler,ou=People,dc=selflinux,dc=de \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Das Rollen-Modell ist jedoch üblicher und natürlicher, denn es ist hier klar, dass die Mitglieder bestimmte Rollen oder Aufgaben erfüllen. Der Begriff ''Gruppe'' hingegen suggeriert jedoch eher eine Personenaufteilung, technisch gesehen können natürlich Personen in mehreren Gruppen sein. Wenn die Gruppe jedoch eine bestimmte abstrakte Aufgabe hat, sollte man hier jedoch eher eine Rolle definieren. Dies wird oben im Beispiel so verwendet. Die Rolle ''Manager'' hat hier zwei ''Mitglieder''. \subsection{Umwandeln der LDIF-Datei in das LDBM-Format} \label{d40e1037} \par Als nächstes muss die LDIF-Datei ins LDBM-Format konvertiert werden. Dazu dient der Befehl {\bf ldif2ldbm}. Dieser ist unter ''/usr/local/sbin/'' zu finden. \linebreak Der Aufruf lautet: \linebreak {\bf ldif2ldbm -i /usr/local/etc/openldap/ldif/struktur.ldif -f /usr/local/etc/openldap/slapd.conf } \par Sollten sich irgendwelche Dateien nicht in den Standardpfaden befinden, so kann man so nach den Dateien suchen lassen: \linebreak {\bf locate ''Dateiname''} \par oder, falls das nichts hilft, über das jedoch sehr langsame Kommando: \linebreak {\bf find / -name ''Dateiname''} \par Ist die LDIF-Datei konvertiert, muss der LDAP-Server gestartet werden. Die meisten Distributionen stellen dafür ein Skript zur Verfügung welches sich unter {\bf /etc/init.d/}, {\bf /etc/rc.d/init.d/} oder unter {\bf /sbin/init.d} befindet. Für gewöhnlich schimpft sich dieses {\bf ldap} und kann mit diversen Parametern aufgerufen werden. Unter SuSE z.B. würde man mit folgendem init-Script den Server starten: \linebreak {\bf /sbin/init.d/ldap start} \par Ist kein Startskript vorhanden, wird der LDAP-Server mit folgendem Kommando gestartet: \linebreak {\bf /usr/local/libexec/slapd -f /usr/local/etc/openldap/slapd.conf} \par Damit der slapd beim Hochfahren automatisch gestartet wird, muss man ein Skript im {\bf initd/} Verzeichnis anlegen. Das befindet sich je nach Distribution an einer anderen Stelle, so dass dem Leser nichts übrig bleibt als ein bisschen zu suchen. Normalerweise bieten die Distributionen ein Skeleton an, das an die jeweiligen Bedürfnisse angepasst werden muss. Ausführliche Informationen entnehmen Sie bitte der Dokumentation über das ''Sys V System'' Ihrer Distribution. Wahlweise hilft meistens auch ein {\bf man init}, um etwas mehr über selbiges zu erfahren. \subsection{Testen des LDAP-Servers} \label{d40e1109} \par Um den LDAP-Server zu testen, kann man jetzt eine Anfrage an selbigen schicken. Dies geschieht mit folgendem Befehl: {\bf ldapsearch $\backslash$ \linebreak -D ''cn=Thomas Bendler,ou=Develpoment,o=Support,dc=selflinux,dc=de'' $\backslash$ \linebreak -W objectclass=$\backslash$* \linebreak } \par Der Server sollte nun eine Struktur, wie in der Datei beschrieben, als Antwort übergeben. \subsection{Hinzufügen von Datensätzen} \label{d40e1130} \par Nun geht es an das Hinzufügen von Datensätzen. Dazu werden die bereits erstellten LDIF-Dateien benutzt. Das Hinzufügen geschieht mit Hilfe des Befehls {\bf ldapadd} entsprechend der Syntax für die zwei erstellten LDIF-Dateien: \linebreak {\bf ldapadd -v $\backslash$ \linebreak -D ''cn=Thomas Bendler,ou=Develpoment,o=Support,dc=selflinux,dc=de'' $\backslash$ \linebreak -W $\backslash$ \linebreak -f /usr/local/etc/openldap/ldif/people.ldif } {\bf ldapadd -v $\backslash$ \linebreak -D ''cn=Thomas Bendler,ou=Develpoment,o=Support,dc=selflinux,dc=de'' $\backslash$ \linebreak -W $\backslash$ \linebreak -f /usr/local/etc/openldap/ldif/zuordnung.ldif } \par Auf diese Weise können auch weitere Einträge hinzugefügt werden.. Neben der reinen Kommandozeile gibt es auch Tools, die eine ``komfortablere'' Eingabe zulassen (auch wenn's meiner Meinung nach nichts komfortableres als die Kommandozeile gibt). Diese werden in der zweiten LDAP-Serie beschrieben. \subsection{Bilder im Verzeichnis} \label{d40e1167} \par Man kann Bilder im JPEG-Format ebenfalls in das Verzeichnis aufnehmen. Das folgende Beispiel zeigt, wie man zu einem Personeneintrag ein ''Paßfoto'' hinzufügt. \par Angenommen, das Bild heißt ''/tmp/pic.jpg''. Nun muss der DN der betreffenden Person natürlich bekannt sein und man benötigt selbstverständlich Schreibzugriff auf das Verzeichnis. \par Man erzeugt eine Datei, in der der DN und der Bild-Eintrag stehen. Diese ''pic.datei'' könnte wie folgt aussehen: \begin{tabular}{|l|} \hline \begin{tt} pic.datei \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} dn: cn=Thomas Bendler,ou=People,dc=selflinux,dc=de jpegphoto: /tmp/pic.jpg \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Nun kann man mit dem Kommando {\bf ldapmodify} den Eintrag dieses DNs ändern (indem man das Attribut jpegphoto hinzufügt). Damit nicht der Bildpfad, sondern dessen Dateiinhalt in das Verzeichnis aufgenommen wird, muss dem ldapmodify der Parameter ''-b'' mitgegeben werden. Diese Option veranlaßt die ldap*-Werkzeuge, absolute Pfade als Binärdaten zu betrachten. Der Beispielaufruf: \par {\bf ldapmodify $\backslash$ \linebreak -D ''cn=Thomas Bendler,ou=Develpoment,o=Support,dc=selflinux,dc=de'' $\backslash$ \linebreak -W -b \verb+<+ pic.datei } \par Noch ein Hinweis zur Arbeitserleichterung. Da gerade beim ersten Aufsetzen in der Regel nur ein Manager benötigt wird, empfielt es sich, diesen Account über die Parameter ''rootdn'' und ''rootpw'' in der slapd.conf einzustellen. Man bindet in diesem Fall über: \par ... \linebreak {\bf -D ''cn=Manager,dc=selflinux,dc=de''} \linebreak ... \linebreak \par und spart etliches an Tipparbeit. In der Produktion ist dies dann jedoch unzulänglich, da ein Manager ja auch mal Urlaub macht, und auch in dieser Zeit jemand beispielsweise vergessene Paßwörter ändern können muss. Man benötigt hier also immer mehrere Manager. Die Parameter ''rootdn'' und ''rootpw'' sollte man dann auskommentieren und den slapd neustarten. \subsection{Ändern von Indizes} \label{d40e1224} \par Werden in der slapd.conf neue Indizes konfiguriert, so gelten die Einstellungen natürlich sofort für neue Einträge. Die bereits vorhandenen Einträge sind in diesen neuen Indizes aber nicht enthalten. Suchanfragen führen in diesem Fall zu merkwürdig aussehenden Resultaten: Alle neuen Datensätze werden gefunden, jedoch nie alte. In solchen Fällen müssen die Indizes neu erzeugt werden. Dazu stoppt man den slapd, erzeugt sich eine LDIF-Kopie der Datenbank und indiziert diese (der Indexer kann nur LDIFs indizieren). Letztlich startet man den slapd neu. Hier die Kommandos (ohne start/stop): \begin{tt} \begin{scriptsize} user@linux / \$ ldbmcat /var/lib/ldap/id2entry.gdbm \verb+>+ id2entry.dump \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux / \$ ldif2ldbm -i id2entry.dump \end{scriptsize} \end{tt} \linebreak \par Dieser Vorgang kann einige Zeit in Anspruch nehmen, wenn man große Datenbestände hat. Technisch gesehen exportiert man die gesammte Datenbank und importiert sie anschließend. \subsection{Datensicherung} \label{d40e1245} \par Es gibt mehrere Möglichkeiten, Daten zu sichern. Die eleganteste Lösung ist, mehrere sich untereinander replizierende LDAP-Server zu verwenden. Für kleine Installationen ist dies jedoch zu aufwendig. Leichter ist es, sich einfach mit ldapsearch alle Datensätze ausgeben zu lassen, und in einer Datei zu speichern. Ein besserer Weg ist, das Werkzeug {\bf ldbmcat} zu verwenden, um sicherzugehen, wirklich alle Einträge zu erhalten. Um Inkonsistenzen zu vermeiden, sollte der slapd unbedingt gestoppt werden. Um die Ausfallzeit gering zu halten, kopiert man einfach die Datenbankdatei. Unter SuSE-Distributionen könnte man folgende Kommandofolge verwenden: \par {\bf rcldap stop $\backslash$ \linebreak \&\& cp /var/lib/ldap/id2entry.gdbm id2entry-snap.gdbm ; $\backslash$ \linebreak rcldap start $\backslash$ \linebreak id2entry-snap.gdbm \verb+>+ id2entry-snap \linebreak } \par Man erhält id2entry-snap.gdbm im Datenbankformat und eine LDIF-Datei id2entry-snap. Es empfielt sich letztere zu sichern, da über diese Datei notfalls auch in andere Verzeichnisserver zurückgesichert werden kann. Das GDBM-Format hingegen ist versions- und plattformabhänig. \par Der Backup-Vorgang muss vorher unbedingt durchgetestet werden, um vor Überraschungen sicher zu sein. Dieser Test muss auch eine Rücksicherung einschließen, denn nur so kann man sicher sein, dass alles funktioniert. In der Praxis kann es sonst zu bösen Überraschungen kommen, denn das Verzeichnis wird schnell zu einem wichtigen Dienst in der Organisation werden! \section{Tuning des LDAP-Servers} \label{d40e1280} \par Es gibt unterschiedliche Möglichkeiten, den LDAP-Server zu tunen. Diese Möglichkeiten beziehen sich in erster Linie auf die LDBM-Datenbank. Deutliche Performancegewinne lassen sich aber erst in Verbindung mit großen Datenbeständen erzielen. Der ''The SLAPD and SLURPD Administration Guide'' bietet einen Überblick der Möglichkeiten zum Tunen des LDAP-Servers. Weitere Informationen finden sich im FAQ-O-MATIC auf der Homepage des OpenLDAP Projekt. \ref{inhalt.tex} \end{document}