22.9. LDAP – Ein Verzeichnisdienst

Innerhalb einer vernetzten Arbeitsumgebung ist es entscheidend, wichtige Informationen strukturiert und schnell abrufbar bereitzuhalten. Dieses Problem löst ein Verzeichnisdienst, der ähnlich den Gelben Seiten (engl. Yellow Pages) im normalen Alltagsleben die gesuchten Informationen in gut strukturierter, schnell durchsuch- und abrufbarer Form bereithält.

Im Idealfall existiert ein zentraler Server, der die Daten in einem Verzeichnis vorhält und über ein bestimmtes Protokoll an alle Clients im Netzwerk verteilt. Die Daten sollten derart strukturiert sein, dass ein möglichst breites Spektrum von Anwendungen darauf zugreifen kann. So muss nicht jedes Kalendertool oder jeder E-Mailclient seine eigenen Datenbanken vorhalten, sondern kann auf den zentralen Bestand zurückgreifen. Dies verringert den Verwaltungsaufwand für die betreffenden Informationen beträchtlich. Die Verwendung eines offenen und standardisierten Protokolls wie LDAP (engl. Lightweight Directory Access Protocol) stellt sicher, dass möglichst viele Clientapplikationen auf solche Informationen zugreifen können.

Ein Verzeichnis in diesem Kontext ist eine Art von Datenbank, die daraufhin optimiert ist, besonders gut und schnell les- und durchsuchbar zu sein:

Das Design eines Verzeichnisdienstes wie LDAP ist nicht dazu ausgelegt, komplexe Update- oder Abfragemechanismen zu unterstützen. Alle auf diesen Dienst zugreifende Anwendungen sollen möglichst leicht und schnell Zugriff haben.

Verzeichnisdienste gab und gibt es, nicht nur in der Unix-Welt, viele. Novells NDS, Microsofts ADS, Banyans Street Talk und den OSI-Standard X.500.

LDAP war ursprünglich als eine schlanke Variante des DAP (engl. Directory Access Protocol) geplant, das für den Zugriff auf X.500 entwickelt wurde. Der X.500-Standard regelt die hierarchische Organisation von Verzeichniseinträgen.

LDAP ist um einige Funktionen des DAP erleichtert und kann plattformübergreifend und vor allem ressourcenschonend eingesetzt werden, ohne dass man auf die in X.500 definierten Eintragshierarchien verzichten müsste. Durch die Verwendung von TCP/IP ist es wesentlich einfacher, Schnittstellen zwischen aufsetzender Applikation und LDAP-Dienst zu realisieren.

Mittlerweile hat sich LDAP weiterentwickelt und kommt immer häufiger als Stand-alone-Lösung ohne X.500-Unterstützung zum Einsatz. Mit LDAPv3 (der Protokollversion, die Sie mit dem installierten Paket openldap2 vorliegen haben) unterstützt LDAP so genannte Referrals, mit deren Hilfe sich verteilte Datenbanken realisieren lassen. Ebenfalls neu ist die Nutzung von SASL (engl. Simple Authentication and Security Layer) als Authentifizerungs- und Sicherungsschicht.

LDAP kann nicht nur zur Datenabfrage von X.500-Servern eingesetzt werden, wie ursprünglich geplant war. Es gibt mit slapd einen Open Source Server, mit dem Objektinformationen in einer lokalen Datenbank gespeichert werden können. Ergänzt wird er durch slurpd, der für die Replikation mehrerer LDAP-Server zuständig ist.

Das Paket openldap2 besteht im Wesentlichen aus zwei Programmen.

slapd

Ein Stand-alone-LDAPv3-Server, der Objektinformationen in einer BerkeleyDB-basierten Datenbank verwaltet.

slurpd

Dieses Programm ermöglicht es, Änderungen an den Daten des lokalen LDAP-Servers an andere im Netz installierte LDAP-Server zu replizieren.

Zusätzliche Tools zur Systempflege

slapcat, slapadd, slapindex

22.9.1. LDAP versus NIS

Traditionell verwendet der Unix-Systemadministrator zur Namensauflösung und Datenverteilung im Netzwerk den NIS-Dienst. Auf einem zentralen Server werden die Konfigurationsdaten aus den /etc-Dateien und Verzeichnissen group, hosts, mail, netgroup, networks, passwd, printcap, protocols, rpc und services über die Clients im Netz verteilt. Als bloße Textdateien sind diese Dateien ohne größeren Aufwand wartbar. Allerdings wird die Verwaltung größerer Datenmengen aufgrund mangelnder Strukturierung schwierig. NIS ist nur für Unix-Plattformen ausgelegt, was einen Einsatz als zentrale Datenverwaltung im heterogenen Netz unmöglich macht.

Das Einsatzgebiet des LDAP-Dienstes ist im Gegensatz zu NIS nicht auf reine Unix-Netze beschränkt. Ab Windows Server 2000 wird auch LDAP als Verzeichnisdienst unterstützt, ebenso Novell. Zudem ist LDAP nicht auf die oben genannten Aufgabengebiete beschränkt.

Das LDAP-Prinzip kann für beliebige Datenstrukturen verwendet werden, die zentral verwaltet werden sollen. Einige Anwendungsbeispiele wären zum Beispiel:

  • Einsatz anstelle eines NIS-Servers

  • Mailrouting (postfix, sendmail)

  • Adressbücher für Mailclients wie Mozilla, Evolution, Outlook, ...

  • Verwaltung von Zonenbeschreibungen für einen BIND9-Nameserver

Diese Aufzählung kann beliebig fortgesetzt werden, da LDAP im Gegensatz zu NIS erweiterbar ist. Die klar definierte hierarchische Struktur der Daten hilft bei der Verwaltung sehr großer Datenmengen, da sie besser durchsuchbar ist.

22.9.2. Aufbau eines LDAP-Verzeichnisbaums

Ein LDAP-Verzeichnis hat eine baumartige Struktur. Alle Einträge (Objekte genannt) im Verzeichnis haben eine definierte Position innerhalb dieser Hierarchie. Diese Hierarchie wird als Directory Information Tree oder kurz DIT bezeichnet. Der komplette Pfad zum gewünschten Eintrag, der ihn eindeutig identifiziert, wird Distinguished Name oder DN genannt. Die einzelnen Knoten auf dem Weg zu diesem Eintrag werden Relative Distinguished Name oder RDN genannt. Objekte können generell zwei verschiedenen Typen zugeordnet werden:

Container

Diese Objekte können wieder andere Objekte enthalten. Solche Objektklassen sind Root (Wurzelelement des Verzeichnisbaums, das nicht real existiert), c (engl. country), ou (engl. OrganizationalUnit), und dc (engl. domainComponent). Vergleichbar ist dieses Modell auch mit Verzeichnissen (Ordnern) im Dateisystem.

Blatt

Diese Objekte sitzen am Ende eines Astes. Ihnen sind keine anderen Objekte untergeordnet. Beispiele sind Person, InetOrgPerson oder groupofNames.

An der Spitze der Verzeichnishierarchie liegt ein Wurzelelement Root. Diesem können in der nächsten Ebene entweder c (engl. country), dc (engl. domainComponent) oder o (engl. organization) untergeordnet werden.

Die Beziehungen innerhalb eines LDAP-Verzeichnisbaums werden am folgenden Beispiel (siehe Abbildung 22.21. “Aufbau eines LDAP-Verzeichnisses”) deutlich.

Abbildung 22.21. Aufbau eines LDAP-Verzeichnisses

Aufbau eines LDAP-Verzeichnisses

Die gesamte Abbildung umfasst einen fiktiven Directory Information Tree. Abgebildet sind die Einträge (engl. entries) auf drei Ebenen. Jeder Eintrag entspricht in der Abbildung einem Kästchen. Der vollständige gültige Distinguished Name für den fiktiven SuSE-Mitarbeiter Geeko Linux ist in diesem Fall cn=Geeko Linux,ou=doc,dc=suse,dc=de. Er setzt sich zusammen, indem der RDN cn=Geeko Linux zum DN des Vorgängereintrags ou=doc,dc=suse,dc=de hinzugefügt wird.

Die globale Festlegung, welche Typen von Objekten im DIT gespeichert werden sollen, geschieht über ein Schema. Der Typ eines Objekts wird durch die Objektklasse festgelegt. Die Objektklasse bestimmt, welche Attribute dem betreffenden Objekt zugeordnet werden müssen bzw. können. Ein Schema muss demnach Definitionen aller Objektklassen und Attribute enthalten, die im gewünschten Einsatzszenario verwendet werden. Es existieren einige allgemein gebräuchliche Schemata (siehe RFC 2252 und 2256). Allerdings können auch benutzerdefinierte Schemata geschaffen werden oder mehrere Schemata ergänzend zueinander verwendet werden, wenn es die Umgebung erfordert, in der der LDAP-Server betrieben werden soll.

Tabelle 22.10. “Häufig verwendete Objektklassen und Attribute” gibt einen kleinen Überblick über die im Beispiel verwendeten Objektklassen aus core.schema und inetorgperson.schema samt zwingend erforderlicher Attribute und den passender Attributwerte.

Tabelle 22.10. Häufig verwendete Objektklassen und Attribute

ObjektklasseBedeutungBeispieleintragerforderl. Attribute
dcObjectdomainComponent (Namensbestandteile der Domain) susedc
organizationalUnitorganizationalUnit (Organisationseinheit)docou
inetOrgPersoninetOrgPerson (Personenbezogene Daten für Intra-/Internet)Geeko Linuxsn und cn

In Beispiel 22.17. “Auszug aus schema.core (Zeilennummerierung aus Verständnisgründen)” sehen Sie einen Auszug aus einer Schema-Anweisung mit Erklärungen, der Ihnen beim Verstehen der Syntax neuer Schemata hilft.

Beispiel 22.17. Auszug aus schema.core (Zeilennummerierung aus Verständnisgründen)

... 
#1 attributetype (2.5.4.11 NAME ( 'ou' 'organizationalUnitName') 
#2     DESC 'RFC2256: organizational unit this object belongs to' 
#3     SUP name ) 
... 
#4 objectclass ( 2.5.6.5 NAME 'organizationalUnit' 
#5   DESC 'RFC2256: an organizational unit' 
#6      SUP top STRUCTURAL 
#7   MUST ou 
#8 MAY (userPassword $ searchGuide $ seeAlso $ businessCategory $
      x121Address $ registeredAddress $ destinationIndicator $
      preferredDeliveryMethod $ telexNumber $
      teletexTerminalIdentifier $ telephoneNumber $
      internationaliSDNNumber $ facsimileTelephoneNumber $ street $
      postOfficeBox $ postalCode $ postalAddress $
      physicalDeliveryOfficeName $ st $ l $ description) )
...

Als Beispiel dient der Attributtyp organizationalUnitName und die zugehörige Objektklasse organizationalUnit. In Zeile 1 wird der Name des Attributs, sein eindeutiger OID (Object Identifier) (numerisch) sowie das Kürzel des Attributs gelistet. In Zeile 2 wird mit DESC eine kurze Beschreibung des Attributs eingeleitet. Hier ist auch der zugehörige RFC genannt, auf den die Definition zurückgeht. SUP in Zeile 3 weist auf einen übergeordneten Attributtyp hin, zu dem dieses Attribut gehört.

Die Definition der Objektklasse organizationalUnit beginnt in Zeile 4 wie bei der Attributsdefinition mit einem OID und dem Namen der Objektklasse. In Zeile 5 lesen Sie eine Kurzbeschreibung der Objektklasse. Zeile 6 mit dem Eintrag SUP top besagt, dass diese Objektklasse keine Unterklasse einer anderen Objektklasse ist. Zeile 7, beginnend mit MUST, führt alle Attributtypen auf, die zwingend in einem Objekt vom Typ organizationalUnit verwendet werden müssen. In Zeile 8 sind nach MAY alle Attributtypen gelistet, die in Zusammenhang mit dieser Objektklasse verwendet werden können.

Eine sehr gute Einführung in den Umgang mit Schemata finden Sie in der Dokumentation zu OpenLDAP in Ihrem installierten System unter /usr/share/doc/packages/openldap2/admin-guide/index.html.

22.9.3. Serverkonfiguration mit slapd.conf

Wenn das System installiert ist, ist /etc/openldap/slapd.conf als vollständige Konfigurationsdatei für den LDAP-Server vorhanden. Im Folgenden werden die einzelnen Einträge kurz beleuchtet und notwendige Anpassungen erklärt. Einträge mit führendem # sind inaktiv. Um solche Einträge zu aktivieren, entfernen Sie dieses Kommentarzeichen.

22.9.3.1. Globale Anweisungen in slapd.conf

Beispiel 22.18. slapd.conf: Include-Anweisung für Schemata

include /etc/openldap/schema/core.schema 
include /etc/openldap/schema/inetorgperson.schema

Mit dieser ersten Anweisung in slapd.conf wird das Schema spezifiziert, nach dem Ihr LDAP-Verzeichnis organisiert ist (siehe Beispiel 22.18. “slapd.conf: Include-Anweisung für Schemata”). Der Eintrag core.schema ist zwingend erforderlich. Sollten Sie weitere Schemata benötigen, fügen Sie sie hinter dieser Anweisung ein (als Beispiel wurde hier inetorgperson.schema hinzugefügt). Weitere verfügbare Schemata finden Sie im Verzeichnis /etc/openldap/schema/. Soll NIS durch einen analogen LDAP-Dienst ersetzt werden, binden Sie hier die Schemata cosine.schema und rfc2307bis.schema ein. Informationen zu dieser Problematik entnehmen Sie der mitgelieferten OpenLDAP-Dokumentation.

Beispiel 22.19. slapd.conf: pidfile und argsfile

pidfile /var/run/slapd/slapd.pid 
argsfile /var/run/slapd/slapd.args

Diese zwei Dateien enthalten die PID (engl. process id) und einige Argumente, mit denen der slapd Prozess gestartet wird. An dieser Stelle ist keine Änderung erforderlich.

Beispiel 22.20. slapd.conf: Zugangskontrolle

# Sample Access Control 
#       Allow read access of root DSE 
#	Allow self write access 
#       Allow authenticated users read access
#       Allow anonymous users to authenticate 
# access to dn="" by * read 
  access to * by self write 
              by users read 
              by anonymous auth 
# 
# if no access controls are present, the default is: 
#       Allow read by all 
# 
# rootdn can always write!

Beispiel 22.20. “slapd.conf: Zugangskontrolle” ist der Ausschnitt aus slapd.conf, der die Zugangskontrolle zum LDAP-Verzeichnis auf dem Server regelt. Die Einstellungen, die hier im globalen Abschnitt der slapd.conf gemacht werden, gelten, soweit nicht im datenbankspezifischen Abschnitt eigene Zugangsregeln aufgestellt werden, die sie überschreiben. So wie hier wiedergegeben, können alle Benutzer lesend auf das Verzeichnis zugreifen, aber nur der Administrator (rootdn) kann auf diesem Verzeichnis schreiben. Das Regeln der Zugriffsrechte unter LDAP ist ein sehr komplexer Prozess. Daher hier einige Grundregeln, die Ihnen helfen, diesen Vorgang nachzuvollziehen.

  • Jede Zugangsregel ist folgendermaßen aufgebaut:

    access to <what> by <who> <access> 
    
  • what steht für das Objekt oder Attribut, zu dem Sie Zugang gewähren. Sie können einzelne Verzeichnisäste explizit durch separate Regeln schützen oder aber mit Hilfe regulärer Ausdrücke ganze Regionen des Verzeichnisbaums mit einer Regel abarbeiten. slapd wird alle Regeln in der Reihenfolge evaluieren, in der diese in der Konfigurationsdatei eingeführt wurden. Demnach führen Sie allgemeinere Regeln immer hinter spezifischeren auf. Die erste Regel, die slapd als zutreffend bewertet, wird ausgewertet und alle folgenden Einträge ignoriert.

  • who legt fest, wer Zugriff auf die unter what festgelegten Bereiche erhalten soll. Auch hier können Sie durch die Verwendung passender regulärer Ausdrücke viel Aufwand sparen. Wiederum wird slapd nach dem ersten „Treffer“ mit der Auswertung von who abbrechen, d.h. spezifischere Regeln sollten wieder vor den allgemeineren aufgeführt werden. Folgende Einträge sind möglich (siehe Tabelle 22.11. “Zugangsberechtigte Benutzergruppen”):

    Tabelle 22.11. Zugangsberechtigte Benutzergruppen

    BezeichnerBedeutung
    *ausnahmslos alle Benutzer
    anonymousnicht authentifizierte („anonyme“) Benutzer
    usersauthentifizierte Benutzer
    selfBenutzer, die mit dem Zielobjekt verbunden sind
    dn.regex=<regex>Alle Benutzer, auf die dieser reguläre Ausdruck zutrifft
  • access spezifiziert die Art des Zugriffs. Es wird hier unterschieden zwischen den in Tabelle 22.12. “Zugriffsarten” aufgeführten Möglichkeiten:

    Tabelle 22.12. Zugriffsarten

    BezeichnerBedeutung
    noneZutritt verboten
    authzur Kontaktaufnahme mit dem Server
    comparezum vergleichenden Zugriff auf Objekte
    searchzur Anwendung von Suchfiltern
    readLeserecht
    writeSchreibrecht

    slapd vergleicht die vom Client angeforderte Berechtigung mit der in slapd.conf gewährten. Werden dort höhere oder gleiche Rechte gewährt als der Client anfordert, wird dem Client der Zugang erlaubt. Fordert der Client höhere Rechte als dort angegeben, erhält er keinen Zugang.

Beispiel 22.21. “slapd.conf: Beispiel für Zugangskontrolle” zeigt ein einfaches Beispiel für eine Zugangskontrolle, die Sie durch Einsatz regulärer Ausdrücke beliebig ausgestalten können.

Beispiel 22.21. slapd.conf: Beispiel für Zugangskontrolle

access to  dn.regex="ou=([^,]+),dc=suse,dc=de" 
   by dn.regex="cn=administrator,ou=$1,dc=suse,dc=de" write 
   by user read 
   by * none

Diese Regel besagt, dass zu allen ou-Einträgen nur der jeweilige Administrator schreibenden Zugang hat. Die übrigen authentifizierten Benutzer sind leseberechtigt und der Rest der Welt erhält keinen Zugang.

[Tip]Aufstellen von Access Regeln

Falls es keine access to Regel oder keine by <who> Anweisung greift, ist der Zugriff verboten. Nur explizit angegebene Zugriffsrechte werden gewährt. Für den Fall, dass keine einzige Regel aufgestellt wird, gilt das Standardprinzip: Schreibrecht für den Administrator und Leserecht für die übrige Welt.

Detailinformationen und eine Beispielkonfiguration für LDAP-Zugriffsrechte finden Sie in der Online-Dokumentation des installierten openldap2-Pakets. Neben der Möglichkeit, Zugriffskontrollen über die zentrale Serverkonfigurationsdatei (slapd.conf) zu verwalten, gibt es den Weg über ACIs (engl. Access Control Information). Mittels ACIs können die Zugangsinformationen zu einzelnen Objekten im LDAP-Baum selbst abgespeichert werden. Da diese Art der Zugangskontrolle noch nicht sehr verbreitet ist und von den Entwicklern als experimentell eingestuft wird, verweisen wir an dieser Stelle auf die entsprechende Dokumentation auf den Seiten des OpenLDAP-Projekts: http://www.openldap.org/faq/data/cache/758.html.

22.9.3.2. Datenbankspezifische Anweisungen in slapd.conf

Beispiel 22.22. slapd.conf: Datenbankspezifische Anweisungen

database ldbm 
suffix "dc=suse,dc=de" 
rootdn "cn=admin,dc=suse,dc=de" 
# Cleartext passwords, especially for the rootdn, should 
# be avoided.  See slappasswd(8) and slapd.conf(5) for details. 
# Use of strong authentication encouraged. 
rootpw secret 
# The database directory MUST exist prior to running slapd AND 
# should only be accessible by the slapd/tools. Mode 700 recommended. 
directory /var/lib/ldap 
# Indices to maintain 
index   objectClass     eq

In der ersten Zeile dieses Abschnitts (siehe Beispiel 22.22. “slapd.conf: Datenbankspezifische Anweisungen”) wird der Datenbanktyp festgelegt, hier LDBM. Über suffix in der zweiten Zeile wird festgelegt, für welchen Teil des LDAP-Verzeichnisbaumes dieser Server verantwortlich sein soll. Das folgende rootdn legt fest, wer Administratorzugriff auf diesen Server besitzt. Der hier angegebene Benutzer muss keinen LDAP-Eintrag besitzen oder als „normaler“ Benutzer existieren. Mit der rootpw Anweisung wird das Administratorpasswort gesetzt. Sie können hier statt secret auch den mit slappasswd erzeugten Hash des Administratorpassworts eintragen. Die directory Anweisung gibt das Verzeichnis an, in dem die Datenbankverzeichnisse auf dem Server abgelegt sind. Die letzte Anweisung, index objectClass eq, bewirkt, dass ein Index über die Objektklassen gepflegt wird. Ergänzen Sie hier unter Umständen einige Attribute, nach denen Ihrer Erfahrung nach am häufigsten gesucht wird. Wenn nachgestellt für die Datenbank eigene Access Regeln definiert werden, werden diese statt der globalen Access Regeln angewendet.

22.9.3.3. Start und Stopp des Servers

Ist der LDAP-Server fertig konfiguriert und sind alle gewünschten Einträge im LDAP-Verzeichnis nach dem unten beschriebenen Muster (siehe Abschnitt 22.9.4. “Handhabung von Daten im LDAP-Verzeichnis”) erfolgt, starten Sie den LDAP-Server als Benutzer root durch Eingabe des folgenden Befehls:

rcldap start

Möchten Sie den Server manuell wieder stoppen, geben Sie entsprechend rcldap stop ein. Die Statusabfrage über den Laufzustand des LDAP-Servers nehmen Sie mit rcldap status vor. Um Start und Stopp des Servers beim Starten bzw. Herunterfahren des betreffenden Rechners zu automatisieren, nutzen Sie den YaST Runlevel-Editor (vergleiche Abschnitt 10.6. “Der YaST Runlevel-Editor”) oder Sie legen die entsprechenden Links der Start- und Stoppskripten mittels insserv auf der Kommandozeile selbst an (siehe Abschnitt 10.5.1. “Init-Skripten hinzufügen”).

22.9.4. Handhabung von Daten im LDAP-Verzeichnis

OpenLDAP gibt Ihnen als Administrator eine Reihe von Programmen an die Hand, mit denen Sie die Daten im LDAP-Verzeichnis verwalten können. Im Folgenden werden die vier wichtigsten von ihnen zum Hinzufügen, Löschen, Durchsuchen und Verändern des Datenbestandes kurz behandelt.

22.9.4.1. Daten in ein LDAP-Verzeichnis eintragen

Vorausgesetzt, die Konfiguration Ihres LDAP-Servers in /etc/openldap/slapd.conf ist korrekt und einsatzfähig, d.h. sie enthält die passenden Angaben für suffix, directory, rootdn, rootpw und index, können Sie nun mit der Aufnahme von Einträgen beginnen. OpenLDAP bietet hierfür den Befehl ldapadd. Aus praktischen Gründen sollten Sie Objekte nach Möglichkeit gebündelt zur Datenbank hinzufügen. Zu diesem Zweck kennt LDAP das so genannte LDIF-Format (engl. LDAP Data Interchange Format). Eine LDIF-Datei ist eine einfache Textdatei, die aus beliebig vielen Attribut-Wert-Paaren bestehen kann. Für die zur Verfügung stehenden Objektklassen und Attribute schauen Sie in den in slapd.conf angegebenen Schemadateien nach. Die LDIF-Datei zum Anlegen eines groben Gerüsts für das Beispiel aus Abbildung 22.21. “Aufbau eines LDAP-Verzeichnisses” sähe folgendermaßen aus (siehe Beispiel 22.23. “Beispiel für eine LDIF-Datei”):

Beispiel 22.23. Beispiel für eine LDIF-Datei

# Die Organisation SUSE 
dn: dc=suse,dc=de 
objectClass: dcObject
objectClass: organization 
o: SUSE AG dc: suse 

# Die Organisationseinheit Entwicklung (devel) 
dn: ou=devel,dc=suse,dc=de
objectClass: organizationalUnit 
ou: devel 

# Die Organisationseinheit Dokumentation (doc) 
dn: ou=doc,dc=suse,dc=de 
objectClass: organizationalUnit 
ou: doc 

# Die Organisationseinheit Interne EDV (it) 
dn: ou=it,dc=suse,dc=de 
objectClass: organizationalUnit 
ou: it 
[Important]Kodierung der LDIF-Dateien

LDAP arbeitet mit UTF-8 (Unicode), Umlaute müssen demnach bei der Eingabe korrekt kodiert werden. UTF-8 ist seit SUSE LINUX 9.1 als Standard eingestellt und wird von allen gängigen Editoren unterstützt. Sollten Sie Ihre Umgebung auf ein anderes Encoding umgestellt haben (vgl. Abschnitt 9.4. “Sprach- und landesspezifische Anpassungen”), müssen Sie entweder auf die Eingabe von Umlauten überhaupt verzichten oder iconv zum Umkodieren der Eingaben nach UTF-8 verwenden.

Speichern Sie die Datei unter <datei>.ldif ab und übergeben Sie sie mit folgendem Befehl an den Server:

ldapadd -x -D <dn des Administrators> -W -f <datei>.ldif 

Die erste Option -x gibt an, dass in diesem Fall auf Authentifizierung über SASL verzichtet wird. -D kennzeichnet den Benutzer, der diese Operation vornimmt; hier geben Sie den gültigen DN des Administrators an, wie sie in slapd.conf konfiguriert wurde. Im konkreten Beispiel wäre dies cn=admin,dc=suse,dc=de. Mit -W umgehen Sie die Eingabe des Passworts auf der Kommandozeile (Klartext) und aktivieren eine separate Passwortabfrage. Das betreffende Passwort wurde vorher in slapd.conf unter rootpw eingerichtet. -f übergibt die Datei. In Beispiel 22.24. “ldapadd von beispiel.ldif” sehen Sie Aufruf von ldapadd im Detail.

Beispiel 22.24. ldapadd von beispiel.ldif

ldapadd -x -D cn=admin,dc=suse,dc=de -W -f beispiel.ldif 
Enter LDAP password: 
adding new entry "dc=suse,dc=de" 
adding new entry "ou=devel,dc=suse,dc=de" 
adding new entry "ou=doc,dc=suse,dc=de"
adding new entry "ou=it,dc=suse,dc=de"

Die Benutzerdaten der einzelnen Mitarbeiter können Sie in separaten LDIF-Dateien angeben. Mit dem folgenden Beispiel tux.ldif (siehe Beispiel 22.25. “LDIF-Datei für Tux”) wird der Mitarbeiter Tux dem neuen LDAP-Verzeichnis hinzugefügt:

Beispiel 22.25. LDIF-Datei für Tux

# Der Mitarbeiter Tux 
dn: cn=Tux Linux,ou=devel,dc=suse,dc=de
objectClass: inetOrgPerson 
cn: Tux Linux 
givenName: Tux 
sn: Linux
mail: tux@suse.de 
uid: tux 
telephoneNumber: +49 1234 567-8

Eine LDIF-Datei kann beliebig viele Objekte enthalten. Sie können ganze Verzeichnisbäume am Stück an den Server übergeben oder auch nur Teile davon wie zum Beispiel einzelne Objekte. Wenn Sie Ihre Daten relativ häufig ändern müssen, empfiehlt sich eine feine Stückelung in einzelne Objekte, da Ihnen dann das mühsame Suchen nach dem zu ändernden Objekt in einer großen Datei erspart bleibt.

22.9.4.2. Daten im LDAP-Verzeichnis ändern

Stehen in Ihrem Datensatz Änderungen an, verwenden Sie das Tool ldapmodify. Am einfachsten ändern Sie zuerst die betreffende LDIF-Datei und übergeben anschließend die geänderte Datei wieder an den LDAP-Server. Um zum Beispiel die Telefonnummer des Mitarbeiters Tux von +49 1234 567-8 auf +49 1234 567-10 zu ändern, editieren Sie die LDIF-Datei wie in Beispiel 22.26. “Geänderte LDIF Datei tux.ldif” gezeigt.

Beispiel 22.26. Geänderte LDIF Datei tux.ldif

# Der Mitarbeiter Tux 
dn: cn=Tux Linux,ou=devel,dc=suse,dc=de
changetype: modify 
replace: telephoneNumber 
telephoneNumber: +49 1234 567-10

Die geänderte Datei importieren Sie mit dem folgenden Befehl in das LDAP-Verzeichnis:

ldapmodify -x -D cn=admin,dc=suse,dc=de -W -f tux.ldif

Alternativ können Sie ldapmodify auch direkt die zu ändernden Attribute auf der Kommandozeile angeben. Hierbei gehen Sie wie folgt vor:

  1. Rufen Sie ldapmodify auf und geben Sie Ihr Passwort ein:

    ldapmodify -x -D cn=admin,dc=suse,dc=de -W 
    Enter LDAP password: 
     
  2. Geben Sie Ihre Änderungen nach der folgenden Syntax in genau dieser Reihenfolge an:

    dn: cn=Tux Linux,ou=devel,dc=suse,dc=de 
    changetype: modify
    replace: telephoneNumber 
    telephoneNumber: +49 1234 567-10 
    

Detaillierte Informationen zu ldapmodify und zur Syntax lesen Sie in der Manualpage von ldapmodify nach.

22.9.4.3. Daten aus einem LDAP-Verzeichnis suchen oder auslesen

OpenLDAP bietet mit ldapsearch ein Kommandozeilenwerkzeug zum Durchsuchen und Auslesen von Daten im LDAP-Verzeichnis. Ein einfaches Suchkommando hätte folgende Syntax:

ldapsearch -x -b dc=suse,dc=de "(objectClass=*)"

Die Option -b legt die Suchbasis, d.h. den Baumbereich, in dem gesucht werden soll, fest. In diesem Fall ist dies dc=suse,dc=de. Möchten Sie eine verfeinerte Suche auf bestimmten Unterbereichen des LDAP-Verzeichnisses ausführen (z.B. nur über die Abteilung devel), geben Sie diesen Bereich mittels -b an. ldapsearch -x legt die Verwendung einfacher Authentifizierung fest. Mit (objectClass=*) legen Sie fest, dass Sie alle in Ihrem Verzeichnis enthaltenen Objekte auslesen wollen. Verwenden Sie dieses Kommando nach dem Aufbau eines neuen Verzeichnisbaumes, um zu überprüfen, ob alle Ihre Einträge korrekt übernommen wurden und der Server in der gewünschten Form antwortet. Weitere Informationen zum Gebrauch von ldapsearch finden Sie in entsprechenden Manualpage (man ldapsearch).

22.9.4.4. Daten aus einem LDAP-Verzeichnis löschen

Löschen Sie nicht mehr erwünschte Einträge mittels ldapdelete. Die Syntax ähnelt der der oben beschriebenen Kommandos. Um beispielsweise den Eintrag von Tux Linux im Ganzen zu löschen, geben Sie folgendes Kommando ein:

ldapdelete -x -D cn=admin,dc=suse,dc=de -W cn=Tux \
Linux,ou=devel,dc=suse,dc=de
 

22.9.5. Der YaST LDAP-Client

YaST unterstützt LDAP-gestützte Benutzerverwaltung. Um diese Unterstützung zu aktivieren, wenn dies nicht schon während der Installation erfolgt ist, rufen Sie das Modul Netzwerkdienste->LDAP-Client auf. YaST installiert und konfiguriert die unten beschriebenen LDAP-Anpassungen für PAM und NSS automatisch.

22.9.5.1. Genereller Ablauf

Um die Funktion des YaST LDAP-Client-Moduls zu verstehen, sollten Sie über die Abläufe im Hintergrund auf Ihrem Clientrechner grob Bescheid wissen. Zunächst werden, sobald Sie bei der Installation die Verwendung von LDAP zur Netzwerkauthentifizierung aktivieren oder das YaST-Modul aufrufen, die Pakete pam_ldap und nss_ldap installiert und die beiden entsprechenden Konfigurationsdateien angepasst. Mit pam_ldap wird das PAM-Modul benutzt, das für die Vermittlung zwischen Loginprozessen und LDAP-Verzeichnis als Quelle der Authentifizierungsdaten zuständig ist. Das zuständige Softwaremodul pam_ldap.so wird installiert und die PAM-Konfiguration angepasst (siehe Beispiel 22.27. “pam_unix2.conf angepasst für LDAP”).

Beispiel 22.27. pam_unix2.conf angepasst für LDAP

auth:       use_ldap nullok 
account:    use_ldap 
password:   use_ldap nullok 
session:    none 

Wollen Sie zusätzliche Dienste manuell für den Gebrauch von LDAP konfigurieren, muss das PAM-LDAP-Modul in die dem Dienst entsprechende PAM-Konfigurationsdatei unter /etc/pam.d eingefügt werden. Bereits für einzelne Dienste angepasste Konfigurationsdateien finden Sie unter /usr/share/doc/packages/pam_ldap/pam.d. Kopieren Sie die entsprechenden Dateien nach /etc/pam.d.

Über nss_ldap passen Sie die Namensauflösung der glibc über den nsswitch-Mechanismus an die Verwendung von LDAP an. Mit Installation dieses Paketes wird unter /etc eine neue, angepasste Datei nsswitch.conf abgelegt. Mehr zur Funktion von nsswitch.conf finden Sie unter Abschnitt 22.3.1. “Konfigurationsdateien”. Für die Benutzerverwaltung bzw. -authentifizierung mittels LDAP müssen in Ihrer nsswitch.conf folgende Zeilen vorhanden sein (vgl. Beispiel 22.28. “Anpassungen in nsswitch.conf”:

Beispiel 22.28. Anpassungen in nsswitch.conf

passwd: compat
group: compat

passwd_compat: ldap
group_compat: ldap

Diese Zeilen weisen die Resolver-Bibliothek der glibc an, als Quelle für die Authentifizierungsdaten und Benutzerdaten zuerst die lokal auf dem System die entsprechenden Dateien unter /etc auszuwerten und zusätzlich auf den LDAP-Server zuzugreifen. Testen Sie diesen Mechanismus, indem Sie mittels des Kommandos getent passwd beispielsweise den Inhalt der Benutzerdatenbank auslesen. Sie sollten im Resultat sowohl lokale Benutzer auf Ihrem System als auch alle auf dem LDAP-Server hinterlegten Benutzer in einer Übersicht erhalten.

Soll verhindert werden, dass sich normale, per LDAP verwaltete Benutzer auf dem Server mit ssh oder login einloggen können, müssen /etc/passwd und /etc/group um eine Zeile ergänzt werden. /etc/passwd um +::::::/sbin/nologin und /etc/group um +::: .

22.9.5.2. Konfiguration des LDAP-Clients

Nachdem nss_ldap und pam_ldap sowie /etc/passwd und /etc/group von YaST korrekt angepasst wurden, können Sie nun in der ersten YaST-Maske mit den eigentlichen Konfigurationsarbeiten beginnen.

Abbildung 22.22. YaST: Konfiguration des LDAP-Clients

YaST: Konfiguration des LDAP-Clients

Im ersten Dialog (siehe Abbildung 22.22. “YaST: Konfiguration des LDAP-Clients”) aktivieren Sie per Radiobutton die Verwendung von LDAP zur Benutzerauthentifizierung und tragen unter LDAP Base DN die Suchbasis auf dem Server ein, unterhalb der alle Daten auf dem LDAP-Server liegen. Im zweiten Eingabefeld Adressen von LDAP-Servern tragen Sie die Adresse ein, unter der der LDAP-Server zu erreichen ist. Unterstützt Ihr Server TLS/SSL, aktivieren Sie die Checkbox LDAP TLS/SSL, um verschlüsselte Kommunikation zwischen Client und Server zu ermöglichen. Wollen Sie entfernte Verzeichnisse in Ihr Dateisystem einhängen, aktivieren Sie die Checkbox Automounter starten. Möchten Sie als Administrator Daten aktiv auf dem Server verändern, klicken Sie auf Erweiterte Konfiguration.

Abbildung 22.23. YaST: Erweiterte Konfiguration

YaST: Erweiterte Konfiguration

Der folgende Dialog ist zweigeteilt: Im oberen Bereich nehmen Sie allgemeine Einstellungen zu Benutzern und Gruppen vor, die das Verhalten des YaST Benutzer-Moduls bestimmen. Im unteren Bereich tragen Sie die Zugangsdaten zum LDAP-Server ein. Die Einstellungen zu Benutzern und Gruppen beschränken sich auf die folgenden Einträge:

Dateiserver

Ist dieses System ein Dateiserver und verwaltet /home Verzeichnisse der Benutzer? Das Aktivieren der Checkbox gibt dem YaST Benutzer-Modul Hinweise, wie mit den Benutzerverzeichnissen auf diesem System umzugehen ist.

LDAP-Benutzern das Anmelden erlauben

Aktivieren Sie diese Checkbox, um den über LDAP verwalteten Benutzern ein Einloggen auf dem System zu ermöglichen.

Attribut für Gruppenmitglied

Bestimmen Sie den zu verwendenden Typ von LDAP-Gruppen. Zur Auswahl stehen: member (Standardeinstellung) und uniquemember.

[Important]Einsatz des YaST-Clients

Der YaST LDAP-Client wird eingesetzt, um die YaST-Module zur Benutzer- und Gruppenverwaltung anzupassen und bei Bedarf zu erweitern. Außerdem haben Sie die Möglichkeit, Schablonen mit Standardwerten für die einzelnen Attribute zu definieren, um eigentliche Erfassung der Daten zu vereinfachen. Die hier erstellten Vorgaben werden selbst als LDAP-Objekte im LDAP-Verzeichnis abgelegt. Die Erfassung der Benutzerdaten erfolgt weiterhin über die normalen YaST-Modulmasken. Die erfassten Informationen werden als Objekte im LDAP-Verzeichnis abgelegt.

Um Konfigurationen auf dem LDAP-Server zu ändern, tragen Sie in diesem Dialog die benötigten Zugangsdaten ein (siehe Abbildung 22.23. “YaST: Erweiterte Konfiguration”). Dies sind Konfigurations-Base DN, unterhalb der alle Konfigurationsobjekte abgelegt sind, und Administrator-DN. Um Einträge auf dem LDAP-Server zu bearbeiten, klicken Sie auf Einstellungen für die Benutzerverwaltung konfigurieren. Es erscheint ein Popupfenster, in dem Sie Ihr LDAP-Passwort eingeben, um sich am Server zu authentifizieren. Anhand der ACLs oder ACIs auf dem Server wird Ihnen Zugang zu den Konfigurationsmodulen auf dem Server gewährt.

Im Dialog zur Modulkonfiguration haben Sie die Möglichkeit, bestehende Konfigurationsmodule auszuwählen und abzuändern, neue Module anzulegen oder Vorlagen (engl. Templates) für solche Module zu erstellen und zu bearbeiten (siehe Abbildung 22.24. “YaST: Modulkonfiguration”). Zum Ändern eines Wertes innerhalb eines Konfigurationsmoduls oder zum Umbenennen eines Moduls wählen Sie über die Combobox oberhalb der Inhaltsansicht des aktuellen Moduls den Modultyp aus. In der Inhaltsansicht erscheint nun eine tabellarische Auflistung aller in diesem Modul erlaubten Attribute und zugeordneten Werte. Hier finden sich neben allen gesetzten Attributen auch alle anderen Attribute, die per benutztem Schema erlaubt sind, aber derzeit nicht verwendet werden.

Abbildung 22.24. YaST: Modulkonfiguration

YaST: Modulkonfiguration

Möchten Sie ein Modul kopieren, ändern Sie lediglich cn. Um einzelne Attributwerte zu ändern, selektieren Sie diese in der Inhaltsübersicht und klicken auf Bearbeiten. Ein Dialogfenster öffnet sich, in dem Sie die alle zum Attribut gehörigen Einstellungen ändern können. Übernehmen Sie Ihre Änderungen mit OK.

Möchten Sie die bereits bestehenden Module um ein neues Modul ergänzen, klicken Sie auf den Neu Button oberhalb der Inhaltsübersicht. Nachfolgend geben Sie im sich öffnenden Dialog die Objektklasse des neuen Moduls (hier entweder suseuserconfiguration oder susegroupconfiguration) und den Namen des neuen Moduls ein. Verlassen Sie diesen Dialog mit OK, wird das neue Modul in die Auswahlliste der vorhandenen Module aufgenommen und kann über die Combobox an- und abgewählt werden. Wollen Sie das aktuell selektierte Modul löschen, klicken Sie auf den Löschen Button.

Die YaST-Module zur Gruppen- und Benutzerverwaltung binden Vorlagen mit sinnvollen Standardwerten ein, wenn Sie diese zuvor mittels des YaST LDAP-Clients definiert haben. Um ein Template entsprechend Ihren Vorstellungen zu editieren, wählen Sie Vorlage konfigurieren. Entweder werden bereits vorhandene, änderbare Templates angezeigt, oder ein leerer Eintrag.

Wählen Sie eines aus, und konfigurieren Sie in der folgenden Maske Konfiguration der Objektvorlage die Eigenschaften dieses Templates. Diese Maske gliedert sich in zwei tabellarische Übersichtsfenster. Im oberen Fenster sind alle allgemeinen Templateattribute aufgelistet. Legen Sie deren Werte fest, wie es zu Ihrem Einsatzszenario passt oder lassen Sie manche leer. „Leere“ Attribute werden auf dem LDAP-Server gelöscht.

Die zweite Übersicht (Standardwerte für neue Objekte) listet alle Attribute des zugehörigen LDAP-Objekts (hier: Gruppen- oder Benutzerkonfiguration), für die Sie einen Standardwert definieren. Sie können weitere Attribute und deren Standardwerte hinzufügen, bestehende Attribut-Wertpaare editieren und ganze Attribute löschen. Ebenso wie ein Modul lässt sich ein Template durch Änderung des cn Eintrags einfach kopieren, um ein neues Template anzulegen. Verbinden Sie das Template mit dem zugehörigen Modul, indem Sie den Attributwert von susedefaulttemplate des Moduls wie bereits oben beschrieben auf den DN des angepassten Templates setzen.

Abbildung 22.25. YaST: Konfiguration eines Objekt-Templates

YaST: Konfiguration eines Objekt-Templates
[Tip]Standardwerte aus Attributen erzeugen

Sie können Standardwerte für ein Attribut aus anderen Attributen erzeugen, indem Sie statt eines absoluten Wertes eine Variablen-Schreibweise nutzen. Beispielsweise wird cn=%sn %givenName beim Anlegen eines Benutzers automatisch aus den Attributwerten von sn und givenName erzeugt.

Sind alle Module und Templates korrekt konfiguriert und einsatzbereit, erfassen Sie mit YaST wie gewohnt neue Gruppen und Benutzer.

22.9.5.3. Benutzer und Gruppen – Konfiguration mit YaST

Nachdem Module und Templates für das Netzwerk einmal konfiguriert worden sind, weicht die eigentliche Erfassung der Benutzer- und Gruppendaten nur geringfügig von der Vorgehensweise ohne LDAP-Verwendung ab. Die folgende Kurzanleitung bezieht sich auf die Verwaltung von Benutzern, das Vorgehen für die Verwaltung von Gruppen ist analog.

Abbildung 22.26. YaST: Benutzerverwaltung

YaST: Benutzerverwaltung

Die YaST-Benutzerverwaltung erreichen Sie über Sicherheit & Benutzer+Benutzer bearbeiten und anlegen. Wollen Sie einen neuen Benutzer hinzufügen, klicken Sie auf den Button Hinzufügen. Sie gelangen in eine Eingabemaske zur Erfassung der wichtigsten Benutzerdaten wie Name, Login und Passwort. Nach Ausfüllen dieser Maske geht es über den Button Details in eine Maske zur verfeinerten Konfiguration der Gruppenzugehörigkeit, Login-Shell und des Homeverzeichnisses. Die Voreinstellungen der Eingabefelder haben Sie nach dem unter Abschnitt 22.9.5.2. “Konfiguration des LDAP-Clients” beschriebenen Verfahren eingerichtet. Bei aktivierter LDAP-Verwendung gelangen Sie aus dieser Maske in eine weitere Maske zur Erfassung LDAP-spezifischer Attribute (siehe Abbildung 22.27. “YaST: Zusätzliche LDAP-Einstellungen”) . Selektieren Sie nach und nach alle Attribute, deren Wert Sie verändern möchten und klicken Sie auf Bearbeiten, um das entsprechende Eingabefenster zu öffnen. Verlassen Sie danach diese Maske über Weiter und kehren Sie zur Startmaske der Benutzerverwaltung zurück.

Abbildung 22.27. YaST: Zusätzliche LDAP-Einstellungen

YaST: Zusätzliche LDAP-Einstellungen

Aus der Startmaske der Benutzerverwaltung (siehe Abbildung 22.26. “YaST: Benutzerverwaltung”) heraus haben Sie über den Button LDAP-Optionen die Möglichkeit, LDAP-Suchfilter auf die Menge der verfügbaren Benutzer anzuwenden oder über LDAP Benutzer- und Gruppenkonfiguration in die Modulkonfiguration für LDAP-Benutzer und -gruppen zu gelangen.

22.9.6. Weitere Informationen

Komplexere Themen wie die SASL-Konfiguration oder das Aufsetzen eines replizierenden LDAP-Servers, der sich die Arbeit mit mehreren „slaves“ teilt, wurden in diesem Kapitel bewusst ausgeklammert. Detaillierte Informationen zu beiden Themen finden Sie im OpenLDAP 2.2 Administrator's Guide (Links siehe unten).

Auf den Webseiten des OpenLDAP-Projekts stehen ausführliche Dokumentationen für Anfänger und fortgeschrittene LDAP-Benutzer bereit:

OpenLDAP Faq-O-Matic

Eine sehr ergiebige Frage- und Antwortsammlung rund um Installation, Konfiguration und Benutzung von OpenLDAP: http://www.openldap.org/faq/data/cache/1.html

Quick Start Guide

Eine knappe Schritt-für-Schritt-Anleitung zum ersten eigenen LDAP-Server: http://www.openldap.org/doc/admin22/quickstart.html oder im installierten System unter /usr/share/doc/packages/openldap2/admin-guide/quickstart.html.

OpenLDAP 2.2 Administrator's Guide

Eine ausführliche Einführung in alle wichtigen Bereiche der LDAP-Konfiguration inkl. Access Controls und Verschlüsselung: http://www.openldap.org/doc/admin22/ oder im installierten System unter /usr/share/doc/packages/openldap2/admin-guide/index.html

Weiterhin beschäftigen sich folgende Redbooks von IBM mit dem Thema LDAP:

Understanding LDAP

Eine sehr ausführliche, allgemeine Einführung in die Grundprinzipien von LDAP: http://www.redbooks.ibm.com/redbooks/pdfs/sg244986.pdf

LDAP Implementation Cookbook

Zielgruppe sind speziell Administratoren von IBM SecureWay Directory. Jedoch sind auch wichtige allgemeine Informationen zum Thema LDAP enthalten: http://www.redbooks.ibm.com/redbooks/pdfs/sg245110.pdf

Gedruckte, englischsprachige Literatur zu LDAP:

  • Howes, Smith & Good: Understanding and Deploying LDAP Directory Services. Addison-Wesley, 2. Aufl., 2003. - (ISBN 0-672-32316-8)

  • Hodges: LDAP System Administration. O'Reilly & Associates, 2003. - (ISBN 1-56592-491-6)

Ultimative Nachschlagewerke zum Thema LDAP sind die entsprechenden RFCs (engl. Request for comments) 2251 bis 2256.


SUSE LINUX 9.2