5.1 Liste der Konfigurationsdateien

• ldap.conf -- Client Konfiguration
• ldapfilter.conf -- Filterregeln
• ldapsearchprefs.conf -- Bevorzugte Suchkriterien
• ldaptemplates.conf -- Templates für Formulare
• slapd.conf -- Server Konfiguration
• slapd.at.conf -- Beschreibung der Attribute
• slapd.oc.conf -- Beschreibung der Objektklassen
• *.schema -- neue Beschreibung der Attribute und Objektklassen

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.

5.2 Konfigurieren der ldap.conf

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!).

Deshalb hat man sich überlegt, dass Firmen einfach ihren Internet-Domainnamen verwenden können, um ihre Namen zu bilden. Diese werden dc (Domain Component, Domainkomponente) genannt. selflinux.de besteht zum Beispiel aus den Komponenten selflinux und de, also dc=selflinux,dc=de (Ansonsten würde man c=DE,o=Bendler Projekte oder sowas verwenden, was jedoch eigentlich international vergeben werden müßte).

          
# /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
            
         

Was bewirkt die hier vorgestellte ldap.conf? Mit der Variable BASE wird der standardmäßig abgefragte Teilbaum festgelegt. Hier bedeutet das, alle Anfragen sind unterhalb von dc=selflinux,dc=de durchzuführen. Dies wird häufig "Suchbasis" (Searchbase) genannt. Die Variable HOST gibt den Server an, der standardmäßig abgefragt wird. Über die Variable PORT kann alternativ auch ein anderer Default Port eingestellt werden.

5.3 Konfiguration der slapd.conf

Die Datei 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:

              
# /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 Paketes
# 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

# Neuere Versionen verwenden nicht mehr Attribut und objectclass
# Dateien, sondern stattdessen Schemata:
# include /usr/local/etc/openldap/schema/core.schema
# include /usr/local/etc/openldap/schema/cosine.schema
# include /usr/local/etc/openldap/schema/inetorgperson.schema

#
# -- 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
          
         

Was bewirkt die hier vorgestellte slapd.conf?

Die include-Anweisungen bewirken ein Einbinden der angegebenen Dateien. In diesem Fall werden Objektklassen (oc) und deren Attribute (at) beziehungsweise die SChemata-Dateien eingelesen. Die "Netscape Roaming"-Dateien gehören nicht zum Standard-Umfang des LDAP-Tarballs.

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.

Ist der LDAP-Server nicht in der Lage, eine Anfrage zu beantworten, fragt er den unter referral angegebenden LDAP-Server.

Die Zeilen pidfile und argsfile sind für den laufenden Betrieb (pid=prozess id, args=argumente).

Mit dem Schlüsselwort database wird festgelegt, welches Datenbankformat bzw. welche Datenbank benutzt wird. Es sind auch Abfragen von anderen Datenbanken möglich. Im 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).

Die unter 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.

Mit Hilfe der index-Anweisung wird der Datenbank mitgeteilt, wie sie ihre Indizes anlegen soll.

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.

5.4 Attribute und Objektklassen

Wie man bereits in der Konfigurationsdatei slapd.conf sehen kann, werden mehrere Konfigurationsdateien eingebunden, unter anderem slapd.at.conf und slapd.oc.conf beziehungsweise die *.schema-Dateien bei neuren Versionen (mehr dazu im nächsten Abschnitt). Diese Dateien sollten nicht geändert werden. Möchte man eigene Definitionen einbinden sollte das über gesonderte Dateien geschehen, z.B. slapd.local.at.conf und 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.
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.

5.5 Schemata

Neuere Versionen verwenden Schemata, um Objektklassen und deren Attribute zu definieren. Ein Schemata-Element wird über einen OID, einen Object Identifier, eindeutig bestimmt. Das ist im Westentlichen eine Ziffernfolge, die man in etwa mit der Kapitel-Gliederung eines sehr großen Buches vergleichen kann: Es gibt 1.1 und 1.2, unterhalb von 1.1 dann 1.1.1 und 1.1.2. Es kann dann auch 1.1.2.1.19.241.243.4 geben und so weiter.

Über OIDs kann man - vereinfacht gesprochen - allen möglichen Dingen eine eindeutige Nummer geben. Das sind nicht nur Objektklassen, sondern auch Datentypen und Syntaxregeln. Die Syntax eines DNs ist zum Beispiel im OID 1.3.6.1.4.1.1466.115.121.1.12 definiert, ein "directoryString" (das ist eine Zeichenkette im UTF-8 Zeichensatz) ist definiert als 1.3.6.1.4.1.1466.115.121.1.15.

In einem Schema definiert man sich zunächst Attributtypen. Dazu gibt es die Direktive attributeType. Ein Beispiel für die Verwendung:

          
        attributeType ( 2.5.4.41 NAME 'name'
                DESC 'name(s) associated with the object'
                EQUALITY caseIgnoreMatch
                SUBSTR caseIgnoreSubstringsMatch
                SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

        attributeType ( 2.5.4.3 NAME ( 'cn' 'commonName' )
                DESC 'common name(s) assciated with the object'
                SUP name )
      
     

So ist "name" und "cn" oder "commonName" definiert, die uns bereits begegnet sind. Sie haben den OID 2.5.4.41 bzw. 2.5.4.3.

Es gibt also "name". Der muß im Format "Zeichenkette im UTF-8 Zeichensatz" sein (SYNTAX) und bei Vergleichen ist die Groß-/Kleinschreibung egal (EQUALITY caseIgnoreMatch). So kann man sich eigene Attribute sehr flexibel definieren.

Der OID muß eindeutig sein - es muß also zu jeder Nummer genau ein Attribut oder eine Objektklasse zugeornet sein. Alles, was mit 1.1 beginnt, kann man privat verwenden, das ist sozusagen reserviert, da es offiziell nicht verwendet wird.

Man kann zum Beispiel (für sich selbst) festlegen: 1.1.2 für LDAP OIDs (weil die Netzwerker 1.1.1 schon für ihre SNMP OIDs verwenden). Darunter dann 1.1.2.1 als Prefix für Attribute und 1.1.2.2 für Objektklassen.

Die erste neue, eigene Klasse bekäme damit dann 1.1.2.2.1. Definiert man mehrere Klassen, muß man natürlich verschiedene OIDs verwenden, der nächste könnte 1.1.2.2.2 sein.

Meistens möchte man eigene Objektklassen definieren, wenn man spezialle Anforderungen hat. So möchte man vielleicht keine "gewöhnliche" inetOrgPerson-Klasse verwenden, sondern zusätzliche Attribute erlauben. Eigene Definitionen schreibt man natürlich am Besten in eine eigene Datei, die man zusätzlich mit "include" einbindet (so muß man bei Software-Updates nur ein include hinzufügen).

Als Beispiel fügen wir optional (MAY) das Attribut "myPhoto" zu einer Ableitung (SUP) der Klasse inetOrgPerson hinzu:

          
        objectclass ( 1.1.2.2.1 NAME 'myPerson'
                DESC 'my person'
                SUP inetOrgPerson
                MUST ( myUniqueName $ givenName )
                MAY myPhoto )
      
     

Damit man nicht immer die langen Nummern schreiben muß, kann man sich Macros definieren:

          
        objectIdentifier myOID  		1.1
        objectIdentifier mySNMP 		myOID:1
        objectIdentifier myLDAP 		myOID:2
        objectIdentifier myAttributeType        myLDAP:1
        objectIdentifier myObjectClass  	myLDAP:2

        objectclass ( myObjectClass:1 NAME 'myPerson'
                DESC 'my person'
                SUP inetOrgPerson
                MUST ( myUniqueName $ givenName )
                MAY myPhoto )
        
     

Danach käme dann myObjectClass:2, was sicherlich viel klarer ist als 1.1.2.2.2. 1.1.1 taucht als "mySNMP" in dem Beispiel auch wieder auf, so sieht man gleich, warum 1.1.1 hier nicht verwendet wird - es "gehört" ja im Beispiel den Netzwerkern für SNMP.