1.7 Nicht nach Schema F: die OpenLDAP-Schemas

Transkript

1 Nicht nach Schema F: die OpenLDAP-Schemas 1.7 Das Objekt hat die Attribute eines Unix-Users: objectclass: inetorgperson Das Objekt besitzt Attribute wie Nachname, Telefonnummer und Mail-Adresse. objectclass: shadowaccount Das Objekt authentifiziert sich mit einem Shadow-Passwort. objectclass: sambasamaccount Dem Objekt sind die Attribute eines Samba-Users zugeordnet. Fazit Die durch einen Distinguished Name eindeutig adressierten Entitäten eines Verzeichnisdienstes nennt man Objekte. Objekte gehören einer oder mehreren Objektklassen an. Die Zugehörigkeit zu einer Objektklasse stattet das Objekt mit Attributen dieser Klasse aus. Die Attribute eines Objekts sind seine Eigenschaften, wie z. B. Name, Anschrift, Telefonnummer. Die Objektklassen bestimmen darüber, welche ihrer Attribute Werte besitzen müssen und welche optional sind. Bevor wir unseren LDAP-Server starten und mit den Kommandozeilentools beharken, müssen wir zum grundlegenden Verständnis auf jeden Fall noch einen Blick hinter die Kulissen der Schemadateien werfen. Denn sie bilden die Basis für alle Objekte und Attribute, und damit das Kernstück der»datenbank«die uns unser LDAP zur Verfügung stellt. Und vor allem sind sie eines nicht: nach Schema F 1.7 Nicht nach Schema F: die OpenLDAP-Schemas Unter einem Schema versteht man im Rahmen der KI-Forschung die Modellierung von Domänen der realen Welt mit dem Ziel eines strukturierten und fundierten Aufbaus von Wissensbasen, damit rechnergestützt maximales Wissen generiert werden kann. Und dieser Satz erklärt auch, warum theoretische Informatiker auf dem Arbeitsmarkt so schwer zu vermitteln sind. Dennoch: Der Satz ist richtig. Nehmen wir an, wir betrachten die Personalabteilung des Saftladens, der uns ständig viel zu 35

2 1 Vorab: Was man wissen sollte wenig Geld überweist, als eine Domäne der realen Welt, die es abzubilden gilt. Formulieren wir diese Abbildung wir können ja nicht anders aus dem Blickwinkel des Systemadministrators, und hoppla: Die Geordnete Welt der Personalabteilung teilt sich wie das Rote Meer in technische Ressourcen und Humanressourcen. Die wiederum bestehen jeweils aus Objekten mit Eigenschaften. Das kommt uns bekannt vor? Absolut richtig. Denn der Directory Information Tree kurz DIT ist genau so strukturiert. Denken wir uns nun die Objekte und ihre Eigenschaften auf einen Zweck hin organisiert, gelangen wir zu einem Schema. Damit kommen wir nun dem Ziel eines strukturierten und fundierten Aufbaus von Wissensbasen so nahe wie möglich. Genauso funktionieren die OpenLDAP-Schemas. Es gibt einen Zweck, und das Schema stellt die notwendigen Ressourcen zur Verfügung. Lautet der Zweck z.b.»anmeldung an ein Unix-System«, so ist das Mittel dazu das NIS- Schema, das die erforderlichen Objektklassen wie z.b. posixaccount und seine Attribute bereitstellt core, cosine, inetorgperson, samba und einiges mehr Die Schemadateien liegen im Unterordner /schema/ des eigentlichen LDAP- Arbeits-Ordners, typischerweise bei den meisten Distributionen unter /etc/ (open)ldap/*. Werfen wir nun einen kurzen Blick in das nis.schema, um den Aufbau besser zu verstehen: Das folgende Listing zeigt uns einen Teil des NIS-Schemas (Achtung, einige Zeilen sind hier umbrochen): # Attribute Type Definitions attributetype ( NAME 'uidnumber' DESC 'An integer uniquely identifying a user in an \ administrative domain' EQUALITY integermatch SYNTAX SINGLE-VALUE ) attributetype ( NAME 'gidnumber' DESC 'An integer uniquely identifying a group in an \ administrative domain' EQUALITY integermatch SYNTAX SINGLE-VALUE )...<schnipp>... attributetype ( NAME 'homedirectory' DESC 'The absolute path to the home directory' EQUALITY caseexactia5match SYNTAX SINGLE-VALUE ) 36

3 Nicht nach Schema F: die OpenLDAP-Schemas 1.7 attributetype ( NAME 'loginshell' DESC 'The path to the login shell' EQUALITY caseexactia5match SYNTAX SINGLE-VALUE ) # Object Class Definitions objectclass ( NAME 'posixaccount' SUP top AUXILIARY DESC 'Abstraction of an account with POSIX attributes' MUST ( cn $ uid $ uidnumber $ gidnumber $ homedirectory ) MAY ( userpassword $ loginshell $ gecos $ description ) ) Wir sehen hier eine eindeutige Unterteilung in Attribute und Objekte. Ebenfalls erkennen wir, dass die Attribute vor den Objektklassen definiert werden. Warum? Ganz einfach: Die Objektlassen werden aus einer Ansammlung der zuvor definierten Attribute gebildet. Also definitiv kein Henne-Ei-Problem. Wir erkennen Attribute wie loginshell und homedirectory und z.b. die Objektklasse posixaccount, also alles Details, die auf die Informationen hinweisen, die wir im Allgemeinen für Unix/Linux-User-Accounts benötigen. (Diese Informationen bzw.»datenbankfelder«liegen bei einer»normalen«, filebasierten Authentifizierung wie bereits erwähnt in den Dateien /etc/passwd und /etc/shadow.) Zurück zu den Objekten: Jedes Attribut und jede Objektklasse hat einen eindeutigen Namensbezeichner,»NAME«. Das ist nichts anderes als der menschenlesbare und von System interpretierte Alias der OID des Attributs oder der Objektklasse. Im Listing oben können wir so z.b. die bereits erwähnten Bezeichner uidnumber, gidnumber usw. ausmachen. Betrachten wir nun die Objektklasse mit dem Namensbezeichner posixaccount: Dort erkennen wir, dass einige Attribute aufgelistet sind, aus denen sich diese Objektklasse per Definition zusammensetzt. Dort fällt sofort die bereits erwähnte Unterteilung der Attribute auf, und zwar in»must«und»may«. Und das bedeutet, wie wir bereits wissen, die Unterteilung in Pflichtattribute (»MUST«) und optionale Attribute (»MAY«). MUST-Attribute müssen immer gesetzt werden, MAY-Attribute können gesetzt werden, müssen aber nicht. In einer gewissen Weise kann man sich auch den Bezug zwischen Objekten und Attributen wie in einer objektorientierten Programmiersprache vorstellen. In einer Hochprogrammiersprache könnte ein Objekt wie z.b. window die Eigenschaften (Attribute) color, width und height haben, von denen einige in jedem Fall Werte besitzen müssen, andere nicht. Die übliche Syntax hierbei wäre immer: 37

4 1 Vorab: Was man wissen sollte Objekt.Eigenschaft wobei ein Objekt fast immer mehrere Eigenschaften (Attribute) besitzen kann: window.color window.width window.height Ein Fenster müsste z.b. in jedem Fall die Eigenschaften Höhe und Breite besitzen; die Farbe ist dabei lediglich eine optionale Komponente, die für die Funktion des Fensters nebensächlich ist. Und um nun wieder Bezug zum schlauen Satz am Anfang dieses Abschnitts zu nehmen: Die Schemadateien enthalten also die notwendige Struktur, damit wir rechnergestützt maximales Wissen generieren können. Zusammenfassend können wir also sagen: Ein LDAP-Schema beschreibt die Liste möglicher Typen von Einträgen (die man als Objektklassen bezeichnet) zusammen mit den mit ihnen verknüpften Attributen: Die Attribute werden vor den Objektklassen definiert. Eine Objektklasse kann MUST- und MAY-Attribute besitzen. Schemadefinitionen werden in Dateien abgelegt, die üblicherweise nach dem Muster Schemaname.schema benannt werden. Jeder LDAP-Dienst greift auf (mindestens) eine oder mehrere Schemadefinitionen zurück. In ihnen sind die erforderlichen Standard-Objektklassen und ihre zugehörigen Attribute beschrieben. Es stehen immer nur die Schemas zur Verfügung, die beim Start des LDAP-Servers per Include-Statement in seine statische Konfiguration (slapd.conf) eingebunden sind. Bei der Laufzeitkonfiguration ab Version 2.4 können Schemas und damit Objektklassen und die ihnen zugehörigen Attribute z.b. im laufenden Betrieb hinzugefügt und somit auch repliziert werden. Der Beispieleintrag der Schema-Sektion in unserer slapd.conf könnte also z.b. so aussehen: include include include include /etc/openldap/schema/core.schema /etc/openldap/schema/cosine.schema /etc/openldap/schema/inetorgperson.schema /etc/openldap/schema/nis.schema 38

5 Nicht nach Schema F: die OpenLDAP-Schemas Die wichtigsten Schemas und ihre Funktion Schema core.schema cosine.schema inetorgperson.schema nis.schema openldap.schema samba(3).schema misc.schema dyngroup.schema ppolicy.schema Funktion Standard X.501 (93) enthält Standardattribute, die grundsätzlich eingebunden werden müssen. LDAPv3-Schema, das vom X.500 COSINE-Schema abgeleitet ist. Es enthält wichtige Standardattribute der Version 3. Enthält einige nützliche Attribute für den Aufbau eines organisationsorientierten Dienstes. Abhängig von core.schema und cosine.schema. Attributdefinition, um LDAP als Network Information Service (NIS) zu nutzen Standard für Linux/Unix-User. Einige wenige Zusatzattribute vom OpenLDAP-Projekt. Benötigt core, cosine und inetorgperson. Enthält die entsprechenden Objektklassen, um Userobjekte mit Samba-spezifischen Attributen auszustatten und via LDAP zu verwalten Enthält einige Entwürfe für zusätzliche Mail-Attribute. Der Kommentar aus dieser Datei: Not recommended for production use! Use with extreme caution! sollte ausreichend sein. Wird in Verbindung mit dem Overlay dynlist zur Erzeugung von dynamischen Gruppen-Objekten benötigt. Schema für die Bereitstellung von Passwort-Richtlinien. Leider noch kein Standard, und die gleichzeitige Verwendung von PAM ist nicht möglich. Tabelle 1.1 Schemas und Ihre Funktion Wir sehen also: alles recht nützliche Schemas, bis auf misc. Daher: misc du musst leider draußen bleiben Eine wichtige Anmerkung in Bezug auf Schemas und OpenLDAP in der Protokollversion 3: Seit der Version 3 ist von der Clientseite das so genannte Schema- Discovery möglich. Dadurch ist der Client imstande zu prüfen, welche Objektklassen und Attribute der LDAP-Server anhand der eingebundenen Schemas zur Verfügung stellt und welche Syntax, Matching Rules und Controls er kennt. Mehr zu diesen Begriffen in den folgenden Abschnitten. Beispiele zum Schema-Discovery finden wir im Abschnitt 2.3,»Fingerübungen«. Die globalen Versionsspezifikationen von LDAPv3 finden sich im Anhang. Noch ein Wort zu den Standard-Schemas im LDIF-Format (core.ldif, cosine.ldif usw.), die sich üblicherweise ebenfalls im OpenLDAP-Konfigurations-Unterordner../schema/ befinden: Hierbei handelt es sich um Schemas, die bereits im 39

6 1 Vorab: Was man wissen sollte LDAP Data Interchange Format (abgekürzt: LDIF) zur direkten Verwendung innerhalb der Online-Konfiguration vorkonfiguriert sind. Mehr zu dem Thema in den folgenden Kapiteln Eindeutige Identifikation mit OIDs Jede Objektklasse und jedes Attribut ist eindeutig durch einen numerischen OID (Object IDentifier, siehe unser Listing aus dem nis.schema aus Abschnitt 1.7.1,»core, cosine, inetorgperson, samba und einiges mehr«) gekennzeichnet. Die OIDs sind in den Standard-Schemas fest zugeordnet und sollten auf gar keinen Fall verändert werden. Wir können uns das am ehesten vorstellen wie die fest vergebenen MAC-Adressen auf Netzwerkkarten oder eindeutige IP-Adressen im Internet. Wir können allerdings für unsere Firma/Uni/etc. eine eigene OID beantragen und mit Hilfe dieser Kern-OID durch Erweiterung des Adressraums unser eigenes Schema erzeugen oder kollisionsfrei Attribute zu bestehenden Schemas hinzufügen. Die OIDs sind in einer Weise dargestellt, wie man sie seit Ludwig Wittgensteins»Tractatus logico-mathematicus«kennt: Punkt.Unterpunkt.Unterunterpunkt.etc.pp Das Ganze wird entsprechend durch Zahlenketten dargestellt, wobei der führende Teil der Kette, der ja immer gleich bleibt, durch einen zugeordneten Namen ersetzt werden kann. Ein Beispiel: 1.1 OID der Firma LDAP-Elemente Attribut-Typen meineattribute Objektklassen meineobjektklassen Nehmen wir an, die IANA hätte uns den ID-Block zugewiesen. Dann hätten wir eine Menge Zahlen zu tippen bei jeder Schemadefinition. Stattdessen lässt sich durch eine Zuweisung wie meineoid ersetzen. Man gelangt dann zu so etwas wie: MeineOID.1 MeineOID.1.1 MeineOID.1.2 Auf diese Weise wird es möglich, für eigene Anwendungen spezialisierte Schemas zu erzeugen. Ein Beispiel, das nahe liegt, wäre etwa ein sip.schema, das Internet-Telefonie an einen Verzeichnisdienst koppelt, insbesondere Attribute, die 40

7 Nicht nach Schema F: die OpenLDAP-Schemas 1.7 bisher nicht zur Verfügung standen, sagen wir: videophone (boolean: yes/no) oder transferspeed (numeric). Möglich ist es auch, vorhandene Schemas um firmenspezifische Attribute zu erweitern oder etwas in der Art von personal.schema auf die Bedürfnisse der Personalabteilung hin zu konstruieren. Aber Achtung! Bei all der Konstruiererei sollte man immer im Hinterkopf behalten, dass man nicht an den Standard-Schemas herumbiegen sollte, denn dadurch verscherzt man sich gegebenenfalls die Kompatibilität mit anderen OpenLDAP-Verzeichnissen, die unmodifizierte Standard-Schemas verwenden. Zudem lassen die vorhandenen Standard-Schemas in der Regel kaum Wünsche offen. Eine intelligente Alternative zur Modifikation von Standard-Schemas bietet wie bereits erwähnt- ein eigendefiniertes Schema. Wir werden diese Thematik der eigendefinierten Objektklassen, Attribute und Schemas im Abschnitt 3.9,»Selbst ist der Admin das selbstdefinierte Schema«, noch eingehend beleuchten. Fassen wir also noch einmal kurz zusammen: OID (Object Identifier) bezeichnen eindeutig die definierten Attribute und Objektklassen eines Schemas. Mit einer eigenen Root-OID lassen sich Ableitungen für eigene Attribute oder Objektklassen erzeugen. So lassen sich vorhandenen Schemas Attribute hinzufügen oder komplett neue Schemadefinitionen erzeugen. Beim Ändern von»standard-schemas«muss immer die Kompatibilität zu anderen Verzeichnissen im Hinterkopf behalten werden Erbschaftsangelegenheiten: die Welt der Objektklassen Damit s hier was zu erben gibt, muss niemand sterben. Und den Rechtsanwalt brauchen wir auch nicht. Hier geht es eher um die ewige Frage der Klassenzugehörigkeit. Klassenzugehörigkeit? Genau. Von Objektklassen ist die Rede. Wir haben von Objekten gehört als den»finalen«elementen des Directory Information Trees (DIT). Wir wissen mittlerweile, dass diese Objekte Eigenschaften haben, die Attribute genannt werden. Eine dieser Eigenschaften ist immer der (Distinguished-) Name des Objekts. Und wir können zwischen zwingend obligatorischen MUST- Attributen und den wahlweise mit Inhalt gefüllten (fakultativen) MAY-Attributen unterscheiden. Woher aber kommen all diese Attribute? Nein, die bringt weder der Storch noch der Osterbeagle. Sie werden üblicherweise vererbt. 41

8 1 Vorab: Was man wissen sollte Zunächst: Es gibt derzeit drei mögliche Typen von Objektklassen. Sie werden ABSTRACT, STRUCTURAL und AUXILIARY genannt. Betrachten wir der Reihe nach diese Objektklassentypen, dann wird die Vererbungsdefinition transparenter. ABSTRACT: Die Objektklasse des Typs ABSTRACT stellt im eigentlichen Sinne keine Objekte und Attribute zur Verfügung, sie dient nur dazu, dass andere Objektklassen von ihr abgleitet werden (wie eine Art Vorlage bzw. Template, siehe auch hier wieder die Analogie zur objektorientierten Programmierung). Sie ist also nicht»fassbar«, wenn man es so ausdrücken will, daher passt die Bezeichnung ABSTRACT auch recht gut. Sie dient dazu, um die von ihr abgeleiteten»echten«objektklassen mit bestimmten Eigenschaften auszustatten. Das perfekte Beispiel für eine AB- STRACT-Objektklasse ist top. top wäre in diesem Sinne wohl am ehesten als»mutter aller Objektklassen«zu bezeichnen. Ein weiteres Beispiel wäre alias. Ein entsprechender Eintrag in einem Datensatz für die Objektklasse top würde so aussehen: objectclass: top STRUCTURAL: Eine als STRUCTURAL definierte Objektklasse kann man sich am ehesten als Objektklasse vorstellen, welche die tatsächlich im DIT verwendeten»echten«objekte beschreibt. Ein praktisches Beispiel dafür ist die Objektklasse person, mit der sich eine»echte«person im DIT darstellen lässt. Gemäß X.501-Definition muss jeder DIT-Eintrag zumindest von einer»echten«objektklasse des Typs STRUCTURAL abgeleitet sein. Ein Objekt im DIT z.b. ein Userobjekt, das mit Hilfe einer bestimmten, strukturellen Klasse gebildet wurde, konnte in älteren OpenLDAP-Versionen NICHT im Nachhinein einer anderen strukturellen Objektklasse zugewiesen werden. So konnte zum Beispiel ein User-Objekt, das über die Objektklasse organizational- Person gebildet wurde, nicht nachträglich der vererbungstechnisch (s.u.) korrekten Objektklasse inetorgperson zugeordnet werden, die alle Attribute von organizationalperson enthält. Als Vorgehensweise in diesem Fall blieb nur Löschung und Neuanlage des Objekts mit der gewünschten Klassenzuordnung. Seit Version 2.4 können wir diese»einschränkung«mit Hilfe spezieller Mechanismen (manage-privilegien, ldap extended Operations), die wir in späteren Kapiteln noch ausführlich erörtern werden, umgehen. Inwiefern das sinnvoll, notwendig oder gar unumgänglich ist, hängt natürlich immer vom jeweiligen Szenario ab. Hierzu wie gesagt später mehr. 42

9 Nicht nach Schema F: die OpenLDAP-Schemas 1.7 AUXILIARY: (engl. zusätzlich) Mit dieser Objektklasse können einer bestehenden Objektklasse neue Eigenschaften (Attribute) hinzugefügt werden. Diese müssen jedoch bereits bekannt sein (Reihenfolge der Schema-Includes, dazu gleich mehr). AUXILIARY kann nicht»stand-alone«verwendet werden, es setzt zwingend eine übergeordnete, strukturelle Objektklasse voraus. Ein Beispiel für eine AUXILIARY-Objektklasse wäre posixaccount aus dem nis.schema. Und wie sieht das Ganze nun tatsächlich aus? Betrachten wir hierzu einfach drei typische strukturelle Objektklassen unseres DITs, die hierarchisch von top und schließlich voneinander abgeleitet sind: Die Vererbung geht exakt in dieser Reihenfolge vonstatten: objectclass: top ### ABSTRACT, nur zur Vererbung objectclass: person ### STRUCTURAL, abgeleitet von top objectclass: organizationalperson ### STRUCTURAL, abgeleitet von person objectclass: inetorgperson ### STRUCTURAL, abgeleitet von organizationalperson Die Objektklasse top, Typ ABSTRACT, steht wie bereits erläutert an der Spitze unserer Hierarchie. In den Schemadefinitionen (core.schema und inetorgperson.schema) findet sich die Vererbung/Ableitung jeweils in der Zeile SUP <Name der übergeordneten Klasse> STRUCTURAL der jeweiligen Objektklasse. Betrachten wir hierzu die Objektklasse»person«: Ein #> grep core.schema A 4 führt Folgendes zutage: objectclass ( NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userpassword $ telephonenumber $ seealso $ description ) ) Deuten wir die dritte Zeile: Der Eintrag SUP top STRUCTURAL besagt, dass die Objektklasse person von der übergeordneten (engl. SUPerior), abstrakten Objektklasse top abgeleitet wurde und somit automatisch ihre Attribute erbt. Es besagt weiterhin, dass person eine strukturelle Objektklasse (STRUCTURAL) darstellt, also eine eigenständige,»echte«objektklasse mit den dazugehörigen MUST-/ 43

10 1 Vorab: Was man wissen sollte MAY-Attributen abbildet, die auch»stand-alone«eingesetzt werden kann und eine eigenständige Objekthierarchie abbildet. Nun zur Objektklasse organizationalperson: Ein #> grep organizationalperson core.schema -A 3 führt nun Folgendes zutage: objectclass ( NAME 'organizationalperson' DESC 'RFC2256: an organizational person' SUP person STRUCTURAL Zeile 3 zeigt uns wiederum eindeutig, dass die Objektklasse organizationalperson von der Objektklasse person abgeleitet wurde und damit indirekt auch von top. In diesem Fall handelt es sich auch um eine»echte«objektklasse des Typs STRUCTURAL. Die strukturelle Objektklasse inetorgperson wiederum ist abgeleitet von organizationalperson. Hinweis: Die Objektklasse inetorgperson ist nicht mit der gleich lautenden Schemadatei zu verwechseln, der sie entstammt! Sie stellt übrigens eine der meistgenutzten Objektklassen überhaupt dar. Um die Thematik zu verdeutlichen, schauen wir uns den Kommentar im Header des Samba(3).schemas an: ## Prerequisite schemas - uid (cosine.schema) ## - displayname (inetorgperson.schema) ## - gidnumber (nis.schema) Die Objektklasse sambasamaccount (aus dem samba(3).schema, Typ AUXILI- ARY) leitet sich direkt von top ab und erweitert top um bestimmte Attribute, die jedoch zum Teil aus anderen Kern-Schemas unseres LDAP stammen, in diesem Fall cosine, inetorgperson und nis. Wie dem Kommentar unschwer zu entnehmen ist, ist es eine zwingende Vorgabe, dass die entsprechenden Schemas mit den erforderlichen Attributen unserem LDAP-Server auf jeden Fall bereits vor der Einbindung des samba(3).schema bekannt sein müssen. Wir erkennen: Die korrekte Lade-Reihenfolge der Schema-Dateien ist für unseren OpenLDAP zwangsläufig von immenser Wichtigkeit. Beim Start des LDAP- Daemons mit falsch angeordneten Schemas dürfte höchstwahrscheinlich die folgende oder eine ähnliche Fehlermeldung auf der Konsole auftauchen: AttributeType not found: <Platzhalter für Attributname> 44

11 Kleine Baumschule grundsätzliche Überlegungen zum Treedesign 1.8 Recht gut kann man das Einlesen der Objekte und Attribute aus den Schemas auch verfolgen, wenn man sich die Meldungen unseres OpenLDAP-Daemons in einem detaillierten Debug-Level ansieht, dazu später mehr. Einen weitaus tieferen und ausführlicheren Blick in die Eingeweide der Schemas, Objektklassen und Attribute werden wir im Abschnitt 3.9,»Selbst ist der Admin das eigendefinierte Schema«vornehmen. Und, wie der Titel bereits vermuten lässt, ein selbstgebautes Schema in unseren LDAP-Server importieren. So weit der Teil, der das grundlegende Verständnis der»datenbankfelder«unseres LDAP-Servers seiner Objektklassen, Attribute und Schemas behandelt. Bevor wir zum körperlich aktiveren Teil schreiten, dem Setup unseres LDAP-Servers, werfen wir noch einen Blick auf das, was jeder Admin vor der Einrichtung des eigentlichen Trees tun sollte: Er sollte sich Gedanken, darüber machen, wie er sein virtuelles Bonsai-Bäumchen so designen kann, das es auch später, wenn das Ding auf die Größe eines Mammutbaumes angewachsen ist, noch übersichtlich und pflegeleicht bleibt. 1.8 Kleine Baumschule grundsätzliche Überlegungen zum Treedesign Wir waren in der Schöpfung tätig, Abteilung Büsche und Bäume. Unsere letzte Entwicklung war 200 Meter hoch, knallrot und stank fürchterlich. Da hat ER uns gefeuert Time Bandits, GB 1981 Wir sehen, die Gestaltung von Bäumen ist bisweilen nicht ohne Risiko. Und auch bei der Konzeptionierung eines Directory Information Trees lauert der eine oder andere Fallstrick. Betrachten wir die Dinge der Reihe nach: Wir haben bereits gesehen, wie in einem LDAP-basierten Verzeichnisdienst Namen von Objekten gebildet werden, wie z.b.: cn=ldapadmin,dc=local,dc=site uid=ckent,ou=verkauf,dc=local,dc=site Auf diese Weise folgt eine Beschreibung vom Blatt über seinen Zweig und Ast zu Stamm und Wurzel des DITs. Klingt einfach, ist es auch. Der Teufel steckt aber, wie üblich, im Detail. Zuerst einmal: Size matters. Ein kleines Unternehmen mit einem kleinen Gesamtbaum kommt längst nicht so schnell in Schwierigkeiten wie ein multinationaler Konzern. Das liegt schon allein daran, dass kleine Unternehmen in der Regel 45

12 Fingerübungen OpenLDAP-Tools auf der Konsole Fingerübungen OpenLDAP-Tools auf der Konsole Die Technik entwickelt sich vom Primitiven über das Komplizierte zum Einfachen. Antoine de Saint-Exupéry In Zeiten grafischer Oberflächen, die von ihren Farben, 3D-Darstellungsmöglichkeiten und -Effekten her ohne Probleme jede Bildschirm-Statistenrolle im Star- Wars- oder Star-Trek-Filmuniversum übernehmen können, scheinen Kommandozeilen-Befehle archaisch und überholt. Als Leser dieses Buches werden Sie mit der Kommandozeile bereits mehr oder weniger vertraut sein. Auf jeden Fall aber gut zu wissen, dass die LDAP-(Remote-) Administration auf der Kommandozeile eine unkomplizierte und schnelle Angelegenheit ist. Zudem lässt sich die Leistungsfähigkeit der im Folgenden vorgestellten Tools in Verbindung mit kleinen Shellskripten hervorragend aufbohren wobei im Rahmen von Upgrades unseres slapd bzw. seiner Tools natürlich stets darauf geachtet werden muss, ob sich keine relevanten Befehls-Optionen geändert haben. Grundsätzlich gilt, dass jeder Administrator die wichtigsten LDAP-Kommandozeilen-Tools und ihre gängigsten Optionen aus dem Effeff beherrschen sollte. In Verbindung mit Perl-, Python- oder PHP-LDAP-Bibliotheken ist eine zusätzliche Interaktionsmöglichkeit vorhanden. An dieser Stelle noch ein kleiner Praxistipp: Wir alle kennen das bash-history-»problem«: Wir arbeiten auf mehreren Konsolen bzw. Remote-Sitzungen mit der gleichen Identität, und die einzige Befehls-History, die gespeichert wird, ist die der letzten Session, die wir beenden. Mit einigen kleinen Ergänzungen lässt sich das Manko schnell beheben, und wir haben alle verwendeten Befehle von allen Sessions in der History. Dazu editieren wir einfach die.bashrc des jeweiligen User-Accounts oder setzen die Parameter in der globalen bash-steuerungsdatei, bei SUSE z.b. /etc/bash.bashrc: shopt -s histappend PROMPT_COMMAND="history -a" Durch die shell-option shopt -s histappend ist die Shell in der Lage, neue Befehle an die History-Datei anzuhängen. PROMPT_COMMAND="history -a" sorgt dafür, dass die Shell vor der Ausgabe des nächsten Prompts die History-Daten sofort wegsichert. In dieser Konstellation kann es manchmal hilfreich sein, die History-Länge je nach gesetztem Defaultwert (HISTSIZE=1000 bei SUSE und nur 500 bei Debian) etwas aufzubohren. Und nun zu unseren Tools im Einzelnen. Damit wir etwas Leben in unseren DIT bekommen, müssen wir unsere im Moment noch leere LDAP-Datenbank mit einer Basisdatei vom Typ LDIF (Lightweight Database Interchange Format, defi- 71

13 2 OpenLDAP installieren und betreiben niert in der RFC 2849,»The LDAP Data Interchange Format (LDIF) Technical Specification«) befüllen. Die nachfolgend auszugsweise gelistete Datei (struktur.ldif) erstellt die elementaren Einträge in der LDAP-Datenbank, zunächst unsere BaseDN sowie ein Abbild unseres LDAP-Admin-Objekts als organisatorische Rolle; dazu gleich mehr. Anschließend werden alle weiteren Objekte wie organizationalunits, Gruppen und User-Objekte erzeugt. Wie in der LDIF-Spezifikation gefordert, müssen die Objekte durch eine Leerzeile voneinander abgegrenzt sein, die Kommentare sind nur hier im auszugsweisen Listing zum besseren Verständnis eingefügt und fehlen in der Beispieldatei: dn: dc=local,dc=site # 1.Eintrag: der DN (Distinguished Name) unsere Basis, liest # sich: local.site objectclass: dcobject # Objektklasse dcobject aus core.schema, stellt das Attribut # dc (MUST) zur Verfügung objectclass: Organization # Objektklasse Organization aus core.schema, stellt # das Attribut o (MUST) zur Verfügung dc: local # Attribut dc (domaincomponent) und Attributwert (local) o: Brainstorm # Attribut o (organization)und Attributwert (Brainstorm) # LEERZEILE ZUR TRENNUNG DER OBJEKTE dn: cn=ldapadmin,dc=local,dc=site # 2.Eintrag: ldapadmin.local.site (cn=commonname) objectclass: organizationalrole # Objektklasse organizationalrole aus core.schema, stellt # das Attribut cn (MUST) zur Verfügung cn: ldapadmin # Attribut cn und Attributwert (ldapadmin) Die Kommentarzeilen (#) dienen nur der Lesbarkeit. Im Klartext sieht der Anfang unserer LDIF-Datei struktur.ldif also so aus: dn: dc=local,dc=site objectclass: dcobject objectclass: Organization dc: local o: Brainstorm dn: cn=ldapadmin,dc=local,dc=site objectclass: organizationalrole cn: ldapadmin #...u.s.w., hier folgen die anderen Objekte... 72

14 Fingerübungen OpenLDAP-Tools auf der Konsole 2.3 Damit unser rootdn im DIT als»echtes«ldap-objekt über seinen DN greifbar ist und als solches auch ausgewertet/behandelt werden kann, bilden wir ihn bei der Befüllung unseres DIT zusätzlich als Objekt ab. Hierzu verwenden wir eine so genannte»organizationalrole«, also einfach ausgedrückt: eine Rolle. Dies kann man vielleicht am ehesten mit Film oder Theater vergleichen: Es gibt Haupt- und Nebenrollen. Und das DIT-Pendant zu unserem hartverdrahteten rootdn spielt aufgrund seines DNs die ultimative Hauptrolle, er darf einfach alles, ohne ihn geht überhaupt gar nichts. Eben so wie Käpt n Kirk auf der Enterprise. Weiter im Text: Das Passwort der Userobjekte in der LDIF-Datei wurde per slappasswd in der gleichen Vorgehensweise generiert wie für den rootpw-eintrag in unserer slapd.conf. Das Passwort ist für alle User-Accounts das Gleiche, nämlich wie üblich und stets hochinnovativ:»linux«. Kurze Anmerkung: Die OpenLDAP-Kommandozeilentools wie ldapadd oder ldapmodify unterstützen seit Version 2.4 auch die Möglichkeit, innerhalb einer LDIF-Datei per Include-Statement auf eine oder mehrere externe LDIF-Dateien zu verweisen: include: file:///root/admin2.ldif Ein weiteres, sehr interessantes Feature besteht darin, Informationen aus einer Datei direkt als Eingabe für ein Attribut zu verwenden: description:< file:///root/kents_description.txt Wobei statt»file:///«auch URI-Schemas wie ftp oder http unterstützt werden. Weitere ausführliche Informationen und Beispiele liefert man 5 ldif. Bereits an dieser Stelle lässt sich der Aufbau einer typischen LDAP-Objektdefinition unschwer erkennen: Zuerst der Distinguished Name (DN), der immer genau ein (1) Objekt innerhalb des DIT eindeutig (!) beschreibt. Dann folgen die benötigten Objektklassen (objectclass), die die erforderlichen bzw. gewünschten Attribute (hier dc, o, cn) zur Verfügung stellen. Zwischen zwei Objekten muss mindestens eine Leerzeile vorhanden sein, damit OpenLDAP beim Import oder bei Änderungen klar zwischen den Objekten unterscheiden kann. Das manuelle Anlegen von LDIF-Dateien per Editor gestaltet sich für den Anfänger meist etwas hakelig. Aber auch erfahrenere Admins können ein Lied davon singen, dass sich hier und dort bisweilen der Fehlerteufel einschleicht, die unser slapd jedoch meistens relativ aussagekräftig anmeckert. Und wenn nicht: Es gibt Gott sei Dank noch jede Menge Debug-Modes. Beim Import von LDIF-Dateien in die LDAP-Datenbank treten die meisten Fehler aus folgenden Gründen auf: 73

15 2 OpenLDAP installieren und betreiben suffix, rootdn, rootpw nicht oder falsch gesetzt (nur Erstbefüllung) Objektklassen/Attribute, die in der LDIF-Datei zwar angegeben sind, aber durch fehlende/ungeeignete Schemas nicht zur Verfügung stehen Vererbungsfehler durch Verwendung mehrerer Objektklassen vom Typ STRUCTURAL, die nicht voneinander abgeleitet sind Von Objektklassen geforderte MUST-Attribute sind in der LDIF-Datei nicht vorhanden oder syntaktisch falsch. Unterschiedliche Objekte wurden nicht durch eine Leerzeile getrennt. Zeilen beginnen mit einem Leerzeichen oder Tab. Es wurde kein UTF-8/ASCII-Zeichensatz verwendet (siehe unsere Anmerkung zum»editor Ihrer Wahl«der nächsten Seite). Die LDIF-Datei enthält unzulässige Sonderzeichen, die den Datensatz beim Einlesen in die Datenbank unbrauchbar machen. Die ersten sechs Punkte lassen sich anhand unserer bereits erworbenen Kenntnisse relativ schnell überprüfen. Eine ergänzende Anmerkung zum vorletzten Punkt: Der ASCII- und UTF-8-Zeichensatz sind, was die ersten 128 Zeichen betrifft, identisch. Zeichen aus anderen Zeichensätzen, die nicht in UTF-8 enthalten sind (z.b. Zeichen aus ISO8859), müssen konvertiert werden. Dafür kann man das Tool iconv verwenden. Aus unserer Erfahrung möchten wir zu diesem Punkt noch kurz Folgendes anmerken: Am besten auf die Verwendung von Sonderzeichen und Umlauten ganz verzichten. Das gibt im Betrieb am wenigsten Probleme. Alternativ lässt sich der vi(m) allerdings auch dazu bringen, UTF-8 zu verwenden (siehe weiter unten). Der letzte Punkt lässt sich ebenfalls recht einfach kontrollieren. Wir öffnen den vi mit der LDIF-Datei im Kommandomodus und geben das Kommando set list hinter dem Doppelpunkt ein. Dadurch werden Zeilenumbrüche, Tabs und einige andere Steuerzeichen angezeigt. Wie bereits in unserem Exkurs»uid? or not uid?«in Abschnitt 1.6,»Objekte, Klassen, Attribute«, über die Verwendung von Sonderzeichen in Verbindung mit LDAP-Daten erwähnt: Per Definition reagiert unser LDAP-Server auf Leerzeichen oder sonstige Sonderzeichen/Umlaute in den Attributwerten oder DNs beim Import von LDIF-Dateien mit sofortiger Base64-Codierung des Attributwertes/ DNs, was sich im importierten Datensatz typischerweise immer an dem doppelten Doppelpunkt»::«zwischen Attributbezeichner und Attributwert erkennen lässt. Typisches Beispiel hierfür ist der Attributwert für userpassword. Durch die Base64-Codierung ist der Attributwert auf der Kommandozeile in der Regel nicht mehr im Klartext lesbar, was uns bei Passwörtern mit Sicherheit nicht stört im 74

16 Fingerübungen OpenLDAP-Tools auf der Konsole 2.3 Gegenteil. Bei anderen Attributwerten oder gar dem DN sieht die Sache jedoch schon anders aus. Kleiner Praxistipp: Die oftmals erwähnte Phrase»Bearbeiten Sie die LDIF-Datei mit einem Editor Ihrer Wahl «können wir aus unseren Erfahrungen keineswegs empfehlen, sondern raten an dieser Stelle nochmals zur Verwendung des vi(m) bzw. eines Editors, mit dem Sie»überflüssige«(Steuer-) Zeichen erkennen und entfernen können. Mitterweile beherrscht sogar der Editor des Midnight Commanders (z.b. mcedit 4.6.2) per Default diese Einstellung. Bezüglich UTF-8 können wir im Kommandomodus des vi(m) (:) mit set encoding? den aktuell eingestellten Wert anzeigen lassen und diesen bei Bedarf mit set encoding=utf-8 umstellen. Eine sehr ausführliche Dokumentation hierzu findet sich unter Damit kommen wir nun zum eigentlich wichtigsten Teil, was das Handling der Daten auf unserem LDAP-Server angeht. Grundsätzlich stehen uns folgende ldap*-kommandozeilentools zur Verfügung: ldapsearch ldapadd ldapmodify ldapdelete ldappasswd ldapexop ldapcompare ldapwhoami ldapmodrdn Suchen/Exportieren von Objekten Hinzufügen von Objekten (entspricht ldapmodify a) Ändern vorhandener Objekte (auch DN-Modifizierung und extended Operations möglich) Löschen vorhandener Objekte Passwort für ein (User-)Objekt setzen Extended Operations (ManageDIT, ManageDSAIT, DDS- Objekte per relax auffrischen) Prüfe, ob der Datensatz existiert, Rückgabewert: Boolean meine aktuelle LDAP-Identität Modifizieren des»relativen dn«(rdn) Das Tool ldapadd ist dabei tatsächlich nur ein Softlink auf ldapmodify. Wird ldapadd aufgerufen, arbeitet tatsächlich ldapmodify intern mit der Option -a (add). Die extended Operations (ldapexop) können üblicherweise ebenfalls direkt per ldapmodify -e aufgerufen werden. Zu jedem der genannten Befehle (Ausnahme: ldapexop) existiert natürlich eine umfangreiche Manpage, aber darauf wollen wir uns nicht ausruhen. Übung macht schließlich den (LDAP-)Meister. 75

17 2 OpenLDAP installieren und betreiben Alle vorgenannten ldap*-kommandos liegen üblicherweise im Suchpfad. Wenn nicht, geben wir den absoluten Pfad zum Kommando an z.b. /usr/bin/ldapadd oder erweitern die PATH-Systemvariable Die ldap*-tools Hinter den Kulissen das LDAP-Funktionsmodell Zum Verständnis, wie eine typische LDAP-Sitzung abläuft, werfen wir vorab noch einen kurzen Blick auf das Funktionsmodell des LDAP-Protokolls, damit klar wird, was bei einer Client-Anfrage an den DIT, z.b. durch eines der vorgenannten Kommandozeilentools, so eigentlich passiert. Das LDAP-Protokoll ist sitzungsorientiert (wie z.b. auch SMTP). Das bedeutet: Bevor überhaupt Daten ausgetauscht werden können, muss eine so genannte Session (Sitzung) initialisiert werden. Das erfolgt in drei Schritten: Binding: Die Anmeldung des Clients am Server (mit oder ohne Authentifizierung, gegebenenfalls verschlüsselt); dann erfolgt eine Prüfung der vom LDAP-Client unterstützten Features, wie z.b. die Protokollversion. Message-Exchange: Der eigentliche Austausch von Nachrichten (Clientseite: Request, Serverseite: Response). Zulässige Messages sind hierbei: bind, unbind, search, add, modify, modrdn, delete, extend, compare, abandon. Unbind steht für eine normale Beendigung der Verbindung. Eine ausführliche Beschreibung des Sitzungsvorgangs mit etlichen Querverweisen findet sich unter bzw. man 3 ldap. Und nun zu den Kommandozeilen-Tools und zur Erstbefüllung unserer LDAP- Datenbank. ldapadd Vor unserer Erstbefüllung noch einmal schnell geprüft, ob die für die Objekte benötigten Schemas core, cosine, inetorgperson und nis per include in die slapd.conf eingebunden sind und, falls dem noch nicht so ist, ob der slapd anschließend neu gestartet wurde, um die Änderungen zu übernehmen. Zum Import der Daten per ldapadd muss unser LDAP-Server natürlich laufen (check per ps oder nmap). Wir setzen nun folgendes ldapadd-kommando (hier ohne Pfadangaben) ab, mit dem wir die LDIF-Datei in den DIT importieren: 76

18 Fingerübungen OpenLDAP-Tools auf der Konsole 2.3 #> ldapadd x W D cn=ldapadmin,dc=local,dc=site \ f struktur.ldif Eine kurze Erläuterung zu den Parametern: -x: einfache, unverschlüsselte Authentifizierung (simple bind), -W: anschließende Passworteingabe erforderlich, -D: den binddn (die Identität) angeben, mit der wir uns am LDAP-Server anmelden (»binden«) wollen, denn davon hängen auch direkt die Rechte ab, mit denen wir auf unseren DIT zugreifen dürfen. Erforderlich ist immer die Angabe des vollständigen Distinguished Name (DN); in diesem Fall verwenden wir natürlich den DN (rootdn) unseres ldapadmin (cn=ldapadmin,dc=local,dc=site), damit wir schreibend auf den DIT zugreifen dürfen. Der Parameter -f (file) gibt schließlich die zu verwendende LDIF-Datei an. Grundsätzlich gilt: Falls eine Komponente des DN (z.b. der cn des Objekts) Leerzeichen enthält, sollte der komplette DN in Anführungszeichen gesetzt werden. Kleiner Tipp: Einige der Kommandozeilen-Optionen lassen sich zusammenfassen, bezogen auf das letzte Beispiel z.b.»-xwd«. Wer sich das Tippen des DNs ersparen will, kann wie bereits erwähnt über die Datei.ldaprc in seinem jeweiligen Home-Ordner den BINDDN direkt mit angeben (siehe hierzu auch ldap.conf(5)). Der obige Befehl würde, bezogen auf unseren ldapadmin-dn, dann folgendermaßen lauten: #> ldapadd xw f struktur.ldif Nachdem wir den Befehl abgeschickt haben, folgt die Passwortabfrage für das rootdn-passwort: Enter LDAP Password: Wenn nach der Passworteingabe die Rückmeldung adding new entry "dc=local,dc=site" adding new entry "dn=ldapadmin,dc=local,dc=site" adding new entry "ou=verkauf,dc=local,dc=site" adding new entry "ou=marketing,dc=local,dc=site"... und so weiter und so fort. wie hier dargestellt aussieht, haben wir erfolgreich unsere erste kleine Verzeichnisstruktur befüllt. Falls Fehlermeldungen auftauchen, zurück zum Start, nicht über Los gehen und auf jeden Fall noch einmal alle vorgenannten Punkte überprüfen. Gerade für Einsteiger kann es oft hilfreich sein, sich die Struktur des Trees und der darin enthaltenen Objekte nach der Initialbefüllung zunächst einmal grafisch zu visualisieren, denn die Struktur eines Trees ist auf der Kommandozeile immer etwas abstrakt. Kleiner Tipp: Zu dieser frühen Phase sollten wir über ein grafisches Tool nur anonym auf den DIT zugreifen, denn mit den entsprechenden 77

19 2 OpenLDAP installieren und betreiben Rechten ausgestattet, ist ein ganzer Subtree mal eben mit einem Klick verschoben oder gelöscht. Grafisch stellt sich unser DIT (hier eine Ansicht im JXplorer; mehr zu diesem Tool in Abschnitt 4.7,»Auf den Schirm!«) im Moment etwa so dar: Abbildung 2.1 Grafische Darstellung unseres aktuellen DIT im JXplorer Die muntere, kleine Objekt-Runde unseres Bäumchens sollte uns nun genug Spielraum geben, um das ldapsearch-tool schon langsam auf Betriebstemperatur zu bringen. Los geht s ldapsearch, zum Ersten Als Erstes prüfen wir, ob wir die gerade eingefügten Daten in unserem DIT auch lesen können. Der Defaultwert "(objectclass=*)" liefert dabei alle im DIT befindlichen Objekte zurück: #> ldapsearch x "(objectclass=*)" Alternativ tut es auch ein einfaches ldapsearch -x. In jedem Fall sollte folgende Ausgabe erscheinen: # extended LDIF # # LDAPv3 # base <dc=local,dc=site> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # local.site dn: dc=local,dc=site 78

20 Fingerübungen OpenLDAP-Tools auf der Konsole 2.3 objectclass: dcobject objectclass: organization dc: local o: Brainstorm # ldapadmin, local.site dn: cn=ldapadmin,dc=local,dc=site objectclass: organizationalrole cn: ldapadmin #... und hier folgen alle anderen Objekte Falls z.b. folgender Fehler auftritt: result: 32 No such object lässt sich durch eine einfache Variation des ldapsearch-befehls leicht feststellen, ob die Einstellungen in der ldap.conf (Client-Datei) betreff BASE (-b) und URI/ Host (-h) fehlerhaft sind oder nicht gesetzt wurden. #> ldapsearch -x objectclass=* -h ldapmaster -b \ dc=local,dc=site An dieser Stelle können wir gegebenenfalls noch einmal prüfen, ob der in der URI eingetragene Hostname über die /etc/hosts aufgelöst werden kann. Eine»bereinigte«Version der ldapsearch-ausgabe ohne Kommentare kann durch den ergänzenden Parameter -LLL erzielt werden. #> ldapsearch -x LLL Die»saubere«Ausgabe sollte nun so aussehen: dn: dc=local,dc=site objectclass: dcobject objectclass: organization dc: local o: Brainstorm #... und hier folgen alle anderen Objekte Bereits hier wird deutlich, dass sich mit ldapsearch hervorragend Datensätze aus dem DIT in direkt verwertbarer (LDIF-)Form extrahieren lassen. Modifikationen an Objekten werden so auch fernab von grafischen Frontends zu einer leichten Übung. Das zahlt sich vor allem dann aus, wenn dem Admin z.b. gerade»nur«eine Remote- Konsolensitzung über SSH zur Verfügung steht. Der Datensatz wird gefiltert, d.h. nur mit den benötigten Attributen ausgelesen (wie das geht, sehen wir gleich), modifiziert und anschließend per ldapmodify wieder in den DIT eingelesen. Achtung: ldapmodify-operationen sind seit OpenLDAP Version 2.4 nur noch mit einem bestimmten LDIF-Syntax zulässig. Mehr zu diesem Thema im nächsten Abschnitt über ldapmodify. 79

21 2 OpenLDAP installieren und betreiben Als Suchmuster für die im obigen Beispiel verwendete Objektklasse (objectclass) lassen sich alle in unserem DIT existierenden Objektklassen nutzen, z.b. posixaccount, person, sambasamaccount usw., ebenso natürlich alle zugehörigen Attribute: #> ldapsearch -x -LLL objectclass=posixaccount mail listet alle vorhandenen Objekte vom Typ posixaccount (also alle Userobjekte) auf, und von diesen Objekten (außer dem DN) nur das gewünschte Attribut, also mail: dn: uid=hcallahan,ou=verkauf,dc=local,dc=site mail: dn: uid=eripley,ou=forschung,dc=local,dc=site mail: Praxistipp: Wenn wir einen umfangreichen DIT durchsuchen, kann die Anzahl der gefundenen Objekte je nach Suchkriterium leicht die Marke von 500 übersteigen. Das ist, wie wir bereits aus dem Kapitel Installation wissen, der Standardwert für die Obergrenze bei ldapsearch-querys. Wir erinnern uns: Dieser Wert kann über den Parameter sizelimit in der slapd.conf geändert werden. Beispiele: sizelimit <positiver integer wert> oder sizelimit unlimited ldapmodify Was ist faul im Staate Dänemark? Nichts, mein süßer Prinz, nur das LDIF-Format für Änderungen an Objekten hat sich im Gegensatz zu allen OpenLDAP-Vorgängerversionen seit Version 2.4 entscheidend geändert. War es bis zur Version 2.3 einschließlich möglich, einfach ein komplettes Objekt per ldapsearch auszulesen, nur das gewünschte Attribut zu ändern und den ganzen Datensatz (entsprechende ACLs vorausgesetzt) wieder einzulesen, tut sich bei so einem Versuch in Version 2.4 gar nichts mehr. Die einzige, aber durchaus aussagekräftige Rückmeldung, die wir bekommen, lautet: ldapmodify: modify operation type is missing at line 2, entry... und so weiter und so fort. Was ist passiert? Ein Blick in die manpage von ldapmodify sagt uns alles, was wir wissen müssen. Und das entspricht dem, was uns auch die Fehlermeldung mitgeteilt hat. ldapmodify erwartet explizit, was mit welchem Attribut gemacht werden soll. Aufwändig? Vielleicht. Gut für die Performance? In jedem Fall. Denn ist es wirklich sinnvoll, ein Objekt mit vielen Attributen, von denen einige vielleicht sogar eine beträchtliche Datenmenge besitzen können (z.b. Bilddaten), komplett neu einzulesen, auch wenn nur eines geändert wurde? Nicht in diesem Raum-Zeit-Kontinuum, vor allem angesichts der ständig 80

22 Fingerübungen OpenLDAP-Tools auf der Konsole 2.3 steigenden Datenmengen. Auch wenn OpenLDAP der weltweit schnellste DS ist unnötige Modifikationen bremsen auch ihn aus. Daher lag der Schritt nahe, Modifikationsoperationen lediglich auf die zu ändernden Attribute zu beschränken. Schauen wir uns an, wie das im Detail nun vor sich geht. Die direkteste Variante wäre ein interaktives ldapmodify auf der Kommandozeile ohne LDIF-Datei, versteht sich. Allerdings ist diese Methode nicht ganz einfach, vor allen Dingen, da bei einer Fehleingabe alles erneut am Prompt eingeben werden muss. Dass es dennoch geht, möchten wir wenigstens an einem kleinen Beispiel zeigen, denn wie in jedem Bereich gilt auch hier: Übung macht den Meister. Nach Eingabe unseres Authentifikations-DNs (cn=ldapadmin,dc= ) und des Passwortes erfolgt die Eingabe zeilenweise; jede Zeile wird per Enter beendet, womit man in die nächste Zeile wechselt. Als Erstes wird der vollständige DN angegeben, denn das System muss ja wissen, welches Objekt modifiziert werden soll. Anschließend folgen mit changetype die Art der Modifikation, gefolgt von dem zu ändernden Attribut, und schließlich dem zugehörigen Attributwert. Voilà! #> ldapmodify -xwd cn=ldapadmin,dc=local,dc=site Enter LDAP Password: dn: uid=ckent,ou=verkauf,dc=local,dc=site changetype: modify replace: description description: Superman, who else Nach Eingabe der letzten Zeile setzen wir noch ein CR (Carriage Return oder besser bekannt als»enter«) ab, dann beenden wir den interaktiven ldapmodify- Befehl mit [Ctrl] + [D] bzw. [Strg] + [D]. Nun sollte folgende Rückmeldung erscheinen: modifying entry "uid=ckent,ou=verkauf,dc=local,dc=site" und alles hat geklappt. War doch ganz einfach, oder? Okay, die Variante per LDIF-Datei ist zugegebenermaßen doch ein klein wenig komfortabler. Das LDIF (kent1.ldif) selbst sieht genauso aus wie unsere eben getätigte Eingabe auf der Kommandozeile, also: dn: uid=ckent,ou=verkauf,dc=local,dc=site changetype: modify replace: description description: Superman, who else Das Einlesen erfolgt in bekannter Weise: #> ldapmodify -xwd cn=ldapadmin,dc=local,dc=site f kent1.ldif 81

23 2 OpenLDAP installieren und betreiben Im nächsten Beispiel erstellen wir zur Übung folgende Datei (kent2.ldif) und lesen sie anschließend ebenfalls per ldapmodify in den DIT ein: dn: cn=ldapadmin,dc=local,dc=site changetype: modify add: title title: Admin Der letzte Eintrag (title) wurde in diesem Fall ergänzt (zum Objekt hinzu»addiert«). Das title-attribut (MAY) wird von der Objektklasse organizationalperson aus dem core.schema (von der die von unserem Userobjekt verwendete Objektklasse inetorgperson abgeleitet ist) zur Verfügung gestellt. Nun lesen wir den modifizierten Datensatz per ldapmodify wieder in den DIT ein: #>ldapmodify -xwd cn=ldapadmin,dc=local,dc=site -f kent2.ldif modifying entry "uid=ckent,ou=verkauf,dc=local,dc=site" Des Weiteren bietet uns ldapmodify dank der in RFC 4525»LDAP Modify-Increment Extension«spezifizierten Operation z.b. auch die Möglichkeit,»numerische«Werte inkrementell zu erhöhen. Hier eine LDIF, die die uidnumber unseres Kumpels Clark vom aktuellen Wert ausgehend um 1000 Zähler nach oben setzen würde, also auf den Wert dn: uid=ckent,ou=verkauf,dc=local,dc=site changetype: modify increment: uidnumber uidnumber: 1000 ldapdelete Zum Löschen vorhandener DIT-Einträge existiert in der Analogie das ldapdelete- Kommando (vergleiche z.b. auch useradd/userdel/usermod-kommandos). Im nächsten Beispiel wollen wir unseren Kollegen Clark Kent löschen. Nachdem wir seinen Datensatz zuvor mit unserem administrativen DN (cn=ldapadmin,dc= ) per ldapsearch komplett also mit allen Attributen inklusive Passwort gesichert haben, #> ldapsearch xwd cn=ldapadmin,dc=local,dc=site \ uid=ckent LLL > ckent.ldif legen wir los: #> ldapdelete xwd cn=ldapadmin,dc=local,dc=site \ uid=ckent,ou=verkauf,dc=local,dc=site 82

24 Fingerübungen OpenLDAP-Tools auf der Konsole 2.3 Es erfolgt keine Ausgabe, wenn alles ohne Fehler abgelaufen ist. Hinter der Identität, mit der wir den simple bind durchführen, wird der vollständige (!) DN des zu löschenden Objekts angegeben. Ein anschließendes ldapsearch bringt uns nun Gewissheit: Unser Superman ist vorerst futsch. Nun lesen wir ihn per ldapadd und der zuvor erstellten Datei ckent.ldif in der bekannten Vorgehensweise wieder ein. Noch ein kleiner Tipp vorab: Es gibt tatsächlich auch Objekte, die sich egal, ob wir nun LDAP-Admin sind oder nicht hartnäckiger als eine pandimensionale, arkturianische Grippe der Löschung per ldapdelete widersetzen. Aber auch denen kommen wir bei, keine Panik. Einen speziellen Vertreter dieser resistenten Gattung schauen wir uns im Abschnitt über Partitionierung an. Andererseits ist höchste Vorsicht geboten, und zwar vor dem niedlichen, kleinen Schalter r: Denn wenn wir ldapdelete mit -r (=rekursiv, wir ahnten es) auf einen Subtree anwenden, ist jener komplett futsch, und zwar mitsamt aller Subordinates, also allen untergeordneten Einträgen. Der folgende Befehl würde den kompletten Subtree ou=forschung unseres kleinen Bäumchens kappen, mitsamt Sub-Unit ou=xeno: #> ldapdelete xwd cn=ldapadmin,dc=local,dc=site \ ou=forschung,dc=local,dc=site -r Also noch mal: VORSICHT mit ldapdelete -r! ldapsearch, zum Zweiten OID s und operational Attributes Noch einmal zurück zu ldapsearch, dem (fast) wichtigsten LDAP-Kommandozeilentool. Über die explizite Angabe von Attributen oder deren OIDs können wir ebenfalls sehr gezielt im DIT suchen. Hierzu schauen wir uns einige Beispiele an: #> ldapsearch -x uid=ckent mail Diese Zeile liefert uns neben dem DN von Clark Kent nur das Attribut mail und dessen Attributwert zurück. #> ldapsearch -x uid=ckent Dieser Befehl liefert uns ebenfalls das Attribut mail (anhand seiner OID aus dem cosine.schema) zurück. Der Vollständigkeit halber: Die betagte *-OID entstammt dem Directory Pilot Project für X.500 Attribute, von denen die meisten Attribute ursprünglich in RFC 1274 spezifiziert wurden (aktueller Stand: RFC 4524) und dem cosine.schema entstammen. Mehr zu OIDs von Attributen und Objektklassen im Abschnitt 3.9,»Selbst ist der Admin das eigendefinierte Schema«. 83