Im Internet ist gar nichts. Außer Elektromagnetismus. – Frieder Nake

13 Weitere Internet-Serverdienste

Nachdem im vorigen Kapitel recht ausführlich die gängigsten Serverdienste für Webanwendungen vorgestellt wurden, geht es hier mit einigen anderen Servern weiter. Den Anfang machen die Namens- und Verzeichnisdienstserver, die am Beispiel von BIND beziehungsweise OpenLDAP vorgestellt werden. Danach folgt ein kurzer Überblick über FTP und (x)inted.

13.1 Namens- und Verzeichnisdienste 

Bereits in Kapitel 4, Netzwerkgrundlagen, wurde die Theorie des Domain Name Systems erläutert. Es sorgt dafür, dass die für Menschen bequemeren Internet-Hostnamen in die hinter den Kulissen verwendeten numerischen IP-Adressen umgewandelt werden. In diesem Abschnitt lernen Sie BIND als bekannteste Implementierung eines Nameservers kennen.

Noch einen Schritt weiter gehen Verzeichnisdienste: Sie enthalten hierarchisch organisierte Informationen über Benutzer, Computer und andere Netzwerkressourcen. Die meisten modernen Verzeichnisse genügen einem Standard namens LDAP, beispielsweise auch Microsoft Active Directory. Im zweiten Unterabschnitt wird der Open-Source-Verzeichnisserver OpenLDAP vorgestellt.

13.1.1 Der DNS-Server BIND 

Es gibt verschiedene Implementierungen von Server-Software, die den DNS-Dienst versieht. Die wichtigste von ihnen ist BIND (Berkeley Internet Naming Domain). Es handelt sich um Open-Source-Software des Internet Software Consortiums (ISC). Sie können BIND und entsprechende Informationen darüber von der Website www.isc.org/products/BIND und zahlreichen dort verzeichneten Mirror-Sites herunterladen. Die zurzeit aktuelle Version ist BIND 9.4.1.

Eine andere weitverbreitete Nameserver-Software ist der Microsoft DNS Server. Er ist in die Windows-Server-Betriebssysteme Windows 2000 Server, Windows Server 2003 und Windows Server 2008 integriert. Selbstverständlich erfüllt er nach außen dieselbe Funktion wie BIND, da er zum globalen DNS kompatibel ist.

BIND installieren

In aktuellen UNIX- oder Linux-Distributionen ist BIND normalerweise bereits enthalten. Sie können den Server also problemlos über den Paketmanager Ihres Systems installieren. Wenn Sie nicht genau wissen, wie das funktioniert, konsultieren Sie die Dokumentation Ihres Systems.

Falls BIND nicht mit Ihrem System geliefert wird oder wenn Sie die neueste Version installieren möchten, sollten Sie BIND im Sourcecode herunterladen und selbst kompilieren. Das funktioniert, wie bei autoconf/automake-Software üblich, nach dem folgenden bewährten Schema:

• Entpacken Sie das BIND-Archiv und wechseln Sie in das dadurch angelegte Verzeichnis:

# tar -zxvf /tmp/bind-9.4.1.tar.gz 
# cd bind-9.4.1

• Rufen Sie das Konfigurationsprogramm und anschließend make auf, um BIND mit den passenden Optionen für Ihr System zu kompilieren:

# ./configure 
# make

• Rufen Sie zum Schluss den Installationsbefehl auf:

# make install

Normalerweise sollten Sie anschließend dafür sorgen, dass der Nameserver – das Programm named – beim Booten automatisch gestartet wird. Eine entsprechende Anleitung finden Sie in Kapitel 7, Linux und UNIX.

BIND konfigurieren

Die Konfigurationsdaten von BIND bestehen aus zwei verschiedenen Dateien: Die Datei /etc/named.conf enthält die Konfigurationsinformationen über den Nameserver selbst, während sogenannte Zonendaten-Dateien die eigentlichen Namensdaten in Form von Resource Records enthalten. Beide Dateiarten sind einfache Textdateien, die Sie mit Ihrem bevorzugten Editor bearbeiten können.

Die erste wichtige Angabe in der Datei named.conf beschreibt das Arbeitsverzeichnis, in dem sich die Zonendaten-Dateien befinden. Da diese Anweisung global ist und keine bestimmte Zone betrifft, wird sie in einen options-Block gesetzt:

options { 
   directory "/var/named"; 
};

Anschließend folgen ein oder mehrere zone-Blöcke. Sie enthalten die Konfiguration der Zonen, für die der Nameserver zuständig sein soll.

Falls Ihr Nameserver beispielsweise primärer Master-Nameserver für die Zone lingoworld.de sein soll, sieht der entsprechende named.conf-Eintrag so aus:

zone "lingoworld.de" { 
   type master; 
   file "db.lingoworld.de"; 
};

Der Dateiname db.lingoworld.de ist nicht vorgeschrieben. Sie können jeden beliebigen Namen wählen, aber db.name-der-zone ist üblich. Natürlich müssen Sie die entsprechende Datei auch anlegen.

Für jede Zone, für die Ihr Nameserver als primärer Master dient, benötigen Sie zusätzlich eine Reverse-Lookup-Zone. Dies ist eine Zone, die den umgekehrten Dienst leistet: die Umwandlung einer gegebenen IP-Adresse in einen Domain-Namen. Der Name dieser Zone hängt von der Größe des Subnets ab, in dem sie sich befindet: Es handelt sich um den umgekehrten Netzwerk-Teil der IP-Adresse mit dem reservierten Domain-Namen in–addr.arpa. Angenommen, lingoworld.de verwendet das Netz 196.23.17.0/24, dann wird die folgende Reverse-Lookup-Zone konfiguriert:

zone "17.23.196.in-addr-arpa" { 
   type master; 
   file "db.196.23.17"; 
};

Wenn Ihr Nameserver als Slave dienen soll, beispielsweise für die Zone othernet.de, sieht die entsprechende zone-Anweisung so aus:

zone "othernet.de" { 
   type slave; 
   masters { 138.19.47.3; }; 
   file "bak.othernet.de"; 
};

Unter masters wird eine Liste von Nameservern angegeben, von denen der Slave die Replikationsdaten erhält. Sie brauchen keine primären Master-Nameserver zu sein; der Begriff »masters« bezieht sich auf übergeordnete Nameserver aus der Perspektive des Slaves.

Schließlich benötigen Sie auf jeden Fall noch einen Eintrag für die Root-Hints-Datei. Diese spezielle Datei enthält Informationen über die Server, die den Stamm des DNS bilden und auf die Root-Nameserver der verschiedenen TLDs verweisen. Die entsprechende Datei (zum Beispiel named.root) ist entweder in Ihrer BIND-Distribution enthalten, oder Sie müssen sie per FTP unter der Adresse ftp.rs.internic.net/domain/named.root herunterladen. Der Eintrag in named.conf sieht so aus:

zone "." { 
   type hint; 
   file "named.root"; 
};

Die Konfiguration für einen Caching Only-Nameserver, der lediglich die Antworten externer Nameserver zwischenspeichert, lautet beispielsweise wie folgt:

forwarders { 
   194.8.194.70; 
   194.8.194.71; 
   194.8.194.83 
}; 
forward only;

Die Anweisung forward only verhindert, dass diese BIND-Installation selbst versucht, Namen aufzulösen. In den geschweiften Klammern stehen die Adressen der Nameserver, deren Daten der Caching Only-Server zwischenspeichern soll. Im vorliegenden Beispiel sind es diejenigen von NetCologne; verwenden Sie am besten die Nameserver Ihres eigenen Providers.

Bitte beachten Sie, dass die Syntax der Datei named.conf ganz exakt eingehalten werden muss. (Aus eigener Erfahrung weiß ich, dass Programmierer besonders gern das Semikolon hinter der schließenden geschweiften Klammer vergessen.)

Zonendaten

Falls Ihr Nameserver als primärer Master für eine Zone dient, müssen Sie nun die entsprechende Zonendaten-Datei anlegen. Sie enthält Resource Records für die einzelnen Hosts, Server-Dienste und andere Elemente der Zone. Die erste Zeile einer Zonendaten-Datei ist eine $TTL-Anweisung (Time To Live). Sie gibt an, wie lange andere Nameserver die aus dieser Datei enthaltenen Informationen maximal im Cache halten dürfen. Sie können den Wert entweder komplett in Sekunden angeben oder mit den folgenden Maßeinheiten arbeiten: w (Wochen), d (Tage), h (Stunden), m (Minuten) und s (Sekunden). Soll der Wert 28 Stunden betragen, gibt es beispielsweise die folgenden drei Möglichkeiten:

$TTL 100800 
$TTL 28h 
$TTL 1d4h

SOA-Record

Die nächste Information ist ein SOA-Record (Start of Authority). Er enthält die folgenden Konfigurationsinformationen über die Zone selbst:

• MNAME. Der Hostname des primären Master-Nameservers.

• RNAME. Die E-Mail-Adresse des Verantwortlichen; das @ wird durch einen Punkt ersetzt.

• Die Seriennummer der Zone. Sie sollte bei jeder Aktualisierung erhöht werden. Ein praktisches Format für manuell gepflegte Zonendaten ist JJJJMMDDVV (Letzteres ist eine zweistellige Versionsnummer, die bei 00 beginnt und wichtig ist, wenn mehrere Änderungen an einem Tag stattfinden).

• Der Refresh-Wert. Gibt das Intervall an, in dem die Slave-Nameserver anfragen sollen, ob die Zonendaten aktualisiert wurden.

• Der Retry-Wert. Bestimmt, wie lange ein Slave warten soll, bevor er nach einem Verbindungsfehler erneut nach Aktualisierungen fragt.

• Der Expire-Wert. Gibt an, wie lange die Slaves antworten sollen, wenn der primäre Master nicht erreichbar ist. Dieser Wert sollte recht hoch sein, weil er für Ausfallschutz sorgt.

• Der Negative-Caching-Wert. Gibt an, wie lange die Slaves negative Antworten (»nicht gefunden« usw.) im Cache speichern dürfen. Der Wert sollte recht klein sein, da es sich um einen vorübergehenden Ausfall halten könnte.

Ein vollständiger SOA-Record für lingoworld.de sieht zum Beispiel so aus:

lingoworld.de.  IN  SOA  ns1.lingoworld.de.  ( 
                hostmaster.lingoworld.de. 
                2003112501 
                30m 
                10m 
                30d 
                30m )

Die (runden!) Klammern sind nur dann erforderlich, wenn Daten der Übersicht halber auf mehrere Zeilen verteilt werden.

A- und PTR-Records

Falls Sie einen Host zu einer Zonendaten-Datei hinzufügen möchten, benötigen Sie einen A-Record (Address). Für pc1.lingoworld.de mit der IP-Adresse 196.17.23.24 sieht ein solcher Eintrag so aus:

pc1.lingoworld.de.   IN   A   196.23.17.24

Außerdem benötigen Sie einen PTR-Record (Pointer) in der Zonendaten-Datei der Reverse-Lookup-Zone (in diesem Beispiel in db.196.17.23). Für pc1.lingoworld.de sieht dieser Eintrag so aus:

24.23.17.196.in-addr.arpa.  IN  PTR  pc1.lingoworld.de.

Auf diese Weise müssen Sie alle Rechner in Ihrer Domain, die öffentlich über Hostnamen verfügbar sein sollen, angeben – natürlich auch Ihre eigenen Nameserver, Webserver, Mailserver und so weiter.

Für Webserver-Betreiber ist es oft nützlich, wenn der reine Domain-Name (lingoworld.de) ebenso auf den Webserver verweist wie www.lingoworld.de. Viele Benutzer versuchen den Zugriff ohne das Präfix www, weil sie das von großen Sites wie google.com gewohnt sind. Zu diesem Zweck brauchen Sie nur einen zusätzlichen A-Record einzurichten, der auf die IP-Adresse des Webservers verweist. Beide Möglichkeiten zusammen sehen also so aus:

www.lingoworld.de.   IN   A   196.23.17.3 
lingoworld.de.       IN   A   196.23.17.3

CNAME-Records

Einen CNAME-Record (Canonical Name; ein Alias, der auf einen anderen Hostnamen verweist) dürfen Sie in diesem Zusammenhang nicht verwenden. Nützlich ist der CNAME-Record aber beispielsweise dann, wenn Ihr Webserver intern anders heißt als www:

www.lingoworld.de.   IN  CNAME  box.lingoworld.de

Falls sich das Ziel des Alias-Records (der Hostname auf der rechten Seite) in einer anderen Zone befindet als der Alias-Name, muss dieser Record in der Zone stehen, in die der Alias-Name gehört.

Sie können über die Zonendaten eine triviale Form von Load-Balancing (Lastverteilung auf mehrere physikalische Server) betreiben, indem Sie für jeden Server einen A-Record schreiben:

www.lingoworld.de.   IN   A   196.23.17.3 
www.lingoworld.de.   IN   A   196.23.17.4 
www.lingoworld.de.   IN   A   196.23.17.5

Die IP-Adressen der Webserver werden dann im sogenannten Round-Robin-Verfahren (»reihum«) ausgegeben. Professionelles Load-Balancing benötigt allerdings eine komplexere Konfiguration, die nicht nur DNS betrifft, da eine gerechte Verteilung von Server-Ressourcen beispielsweise auch von der Dateigröße der ausgelieferten Dokumente abhängt und nicht nur von der reinen Anzahl der Namensanfragen.

NS-Records

Ein weiterer wichtiger Typ von Resource Records sind die NS-Records (Nameserver). Sie geben sämtliche autoritativen (zuständigen) Nameserver für die Zone an. Wie bereits erwähnt, sollte mindestens einer dabei sein, der sich nicht innerhalb des eigenen Netzwerks befindet. Für die Domain lingoworld.de könnten die NS-Records also beispielsweise so aussehen:

lingoworld.de.   IN   NS   ns1.lingoworld.de. 
lingoworld.de.   IN   NS   ns2.lingoworld.de. 
lingoworld.de.   IN   NS   ns1.provider.de.

Mithilfe von NS-Records wird übrigens auch die Delegation untergeordneter Zonen durchgeführt: Für eine Subdomain wird einfach ein anderer Nameserver angegeben. Sofern dieser Nameserver sich innerhalb der Zone befindet, die in der aktuellen Zonendaten-Datei konfiguriert wird, muss zusätzlich ein A-Record für diesen Nameserver angegeben werden:

mail.lingoworld.de.    IN   NS   ns.mail.lingoworld.de. 
mail.lingoworld.de.    IN   NS   ns2.provider.de. 
ns.mail.lingoworld.de. IN   A    196.23.17.9

MX-Records

Zu guter Letzt benötigen Sie noch MX-Records (Mail Exchange) für die Angabe von Mail-Zielen. Schließlich sollen Benutzer E-Mails an Adressen wie user@lingoworld.de schicken können statt an user@mail.lingoworld.de. MX-Records enthalten eine Prioritätsangabe, die festlegt, welcher Mailserver bevorzugt werden soll. Ein Server mit einem höheren Wert wird nur dann gewählt, wenn derjenige mit dem nächstkleineren offline oder aus anderen Gründen nicht verfügbar ist:

lingoworld.de.   IN   MX    0 mail.lingoworld.de. 
lingoworld.de.   IN   MX   10 snailmail.lingoworld.de. 
lingoworld.de.   IN   MX   20 mail.provider.de.

Es gibt noch zahlreiche andere Typen von Resource Records. Beispielsweise wurde hier nicht auf die recht komplexe DNS-Konfiguration für IPv6 eingegangen. Wenn Sie selbst für die Verwaltung Ihrer DNS-Zonen verantwortlich sind und öffentliche Nameserver betreiben müssen, kommen Sie nicht umhin, sich entsprechende Literatur zu beschaffen.

13.1.2 Der Verzeichnisdienst OpenLDAP 

Immer größer werdende Netzwerke und IT-Infrastrukturen erfordern neue Verwaltungsmöglichkeiten. Verzeichnisdienste bieten eine solche allgemeine Lösung für die Verwaltung von Rechnern und Ressourcen sowie für die zentralisierte Benutzerkontenpflege. Der Verzeichnisdienst stellt eine spezielle Art von Datenbank bereit, in der sämtliche Teilnetze, Computer, Benutzer und Gruppen der Organisation gespeichert werden.

Verzeichnisdienste

Es gibt unzählige konkrete Verzeichnisdienste. Ein Klassiker ist NIS von Sun; inzwischen besitzt er einen Nachfolger namens NIS+. Die meisten anderen modernen Verzeichnisdienste basieren auf dem Lightweight Directory Access Protocol (LDAP). Es wurde zunächst als abgespeckte, leichter implementierbare und vor allem TCP-fähige Methode für den Zugriff auf Verzeichnisse der alten Spezifikation X.500 entworfen. LDAP setzte sich so flächendeckend durch, dass schließlich Verzeichnisse entwickelt wurden, die kein vollständiges X.500 mehr implementierten, sondern nur noch die für LDAP nötigen Features.

Wichtige Beispiele für LDAP-basierte Server sind Novell Directory Services (NDS) beziehungsweise eDirectory, Microsoft Active Directory und OpenLDAP. Die Open-Source-Implementierung OpenLDAP wird im Folgenden beschrieben.

LDAP-Grundwissen

In LDAP-Verzeichnissen werden die Daten hierarchisch gespeichert und bilden eine Baumstruktur, den LDAP Directory Information Tree (DIT). Für Dateneingabe, -ausgabe und -austausch kommt das textbasierte LDAP Interchange Format (LDIF) zum Einsatz. Jeder LDAP-Eintrag im LDIF-Format besitzt die Struktur Name=Wert. Die meisten dieser Knoten besitzen Unterobjekte sowie Attribute im Format Attributname: Wert.

LDAP-Schema

Sowohl die Objekt- als auch die Attributnamen sind standardisiert im sogenannten LDAP-Schema festgelegt. Jeder Schema-Eintrag besitzt einen Namen und eine eindeutige Nummer, zudem bestimmt das Schema die Verschachtelungsstruktur. Das Schema der LDAP-Spezifikation lässt sich bei Bedarf um eigene Objekt- und Attributklassen erweitern.

Als Wurzel des LDAP-Baums werden dc-Einträge verwendet (Domain Component). Sie bilden die verschiedenen, normalerweise durch Punkte getrennten Elemente eines Domain-Namens ab. Der Wurzeleintrag für die Domain lingoworld.de wäre demzufolge dc=lingoworld,dc=de. Der Gesamt-Domainname bildet in diesem Fall den sogenannten Distinguished Name (DN) des LDAP-Knotens.

Organisationseinheiten

Unter der Wurzel wird der LDAP-Baum in eine oder mehrere Stufen von Organisationseinheiten (ou als Abkürzung für organizational units) unterteilt. Zu den bekanntesten gehören ou=people für Benutzer (oder allgemein Personen) sowie ou=devices für Computer und andere Geräte.

Die Organisationseinheit ou=people könnte in einer Firma beispielsweise in die untergeordneten Organisationseinheiten ou=sales, ou=marketing und ou=accounting unterteilt werden, um die verschiedenen Abteilungen abzubilden.

Um Benutzer-Datensätze zu kennzeichnen, wird ein cn-Knoten verwendet (Common Name). Sein Inhalt besteht in der Regel aus dem Vor- und Nachnamen der betreffenden Person, kann aber bei Bedarf auch um weitere Unterscheidungsmerkmale ergänzt werden. Der gesamte DN eines Users in der Abteilung Entwicklung unter der Organisationseinheit people im Netzwerk lingoworld.de könnte beispielsweise wie folgt lauten:

cn=Sascha Kersken,ou=developers,ou=people, 
dc=lingoworld,dc=de

Personendaten gehören zur Objektklasse person und können aus zahlreichen Attributen bestehen. Für moderne Netzwerke verwendet man besser die erweiterte Objektklasse inetOrgPerson, da person selbst beispielsweise keinen Standardeintrag für eine E-Mail-Adresse enthält.

Objektklassen für Benutzerkonten

Zur Verwaltung von Log-in-Daten gibt es je nach Betriebssystem unterschiedliche Objektklassen. Für alle Unix-Systeme kann beispielsweise posixAccount verwendet werden. Diese Objektklasse bildet alle Felder eines /etc/passwd-Eintrags ab; analog gibt es die Klasse shadowAccount für /etc/shadow-Passwortdaten. Wenn Sie auch Windows-Log-ins verwalten möchten, bietet sich dafür sambaAccount an.

Wenn netzwerkweite User-Log-ins die wichtigste Aufgabe eines LDAP-Servers sind, bietet sich die Verwendung von uid statt cn im DN an. Beispiel:

uid=sascha,ou=developers,ou=people,dc=lingoworld,dc=de

Beachten Sie, dass jeder Knoten mehreren Objektklassen angehören kann. Dazu muss er allerdings die Pflichtattribute all dieser Klassen enthalten (die sich teilweise überschneiden, insbesondere bei voneinander abgeleiteten Objektklassen).

Ein Beispieleintrag

Hier ein komplettes Beispiel für einen User-Eintrag, der den drei Objektklassen person, inetOrgPerson und posixAccount angehört:

dn: uid=sascha,ou=developers,ou=people, 
    dc=lingoworld,dc=de 
objectClass: person 
objectClass: inetOrgPerson 
objectClass: posixAccount 
cn: Sascha Kersken 
sn: Kersken 
givenName: Sascha 
l: Köln 
o: Lingoworld IT Services 
telephoneNumber: 0221–7654321 
facsimileTelephoneNumber: 0221–7654322 
mail: sk@lingoworld.de 
uid: sascha 
uidNumber: 1001 
gidNumber: 100 
userPassword: {MD5}WY1MIARhuBUiozKFZcJffA== 
homeDirectory: /home/sascha 
loginShell: /bin/bash

Attribute im Detail

Hier die Bedeutung der einzelnen Attribute:

• dn (distinguished name): Der komplette Pfad des Eintrags im LDAP-Verzeichnisbaum

• objectClass: Die Kategorie des Eintrags, die festlegt, welche Felder vorgeschrieben beziehungsweise zulässig sind; der Beispieleintrag gehört wie erwähnt zu drei verschiedenen Klassen.

• cn (common name): Der eindeutige Eigenname des Knotens; bei Personen werden meist Vor- und Nachname verwendet.

• sn (surname): Nachname

• givenName: Vorname

• l (location): Wohnort

• o (organization): Firmen- beziehungsweise Institutionsname

• telephoneNumber: Telefonnummer der Person

• facsimileTelephoneNumber: Faxnummer der Person

• mail: E-Mail-Adresse

• uid: User-ID für die Benutzeranmeldung

• uidNumber: Die numerische User-ID

• gidNumber: Numerische ID der primären Gruppe dieses Benutzers

• userPassword: Zunächst steht in geschweiften Klammern der verwenderte Verschlüsselungsalgorithmus, dahinter das entsprechend verschlüsselte Passwort selbst (weiter unten wird ein kleines Skript vorgestellt, mit dem Sie Ihr Passwort selbst verschlüsseln können).

• homeDirectory: Das Home-Verzeichnis des Users

• loginShell: Die Shell, die dem Benutzer nach der Anmeldung zur Verfügung steht.

Jeder Knoten kann beliebig viele untergeordnete Knoten enthalten. Der DN wird dazu um den cn des übergeordneten Objekts ergänzt. Wenn Sie den inetOrgPerson-Eintrag beispielsweise lieber als Unterknoten des User-Accounts speichern möchten, dann lautet dessen DN wie folgt:

dn: cn=Sascha Kersken,uid=sascha,ou=people, 
dc=lingoworld,dc=de

openLDAP verwenden

Die meisten Linux- und UNIX-Versionen enthalten den OpenLDAP-Server bereits ab Werk. Falls nicht, müssen Sie ihn von http://www.openldap.org herunterladen und selbst kompilieren.

OpenLDAP für Windows

Für Windows gibt es inzwischen einen binären Installer, allerdings nur in der Vorgängerversion 2.2; zudem ist er als experimentell gekennzeichnet. Sie können ihn unter http://download.bergmans.us/openldap/ herunterladen. Wenn Sie den Installer mit Standardeinstellungen ausführen, wird OpenLDAP automatisch als Dienst installiert. Sie sollten das Installationsverzeichnis anschließend zu Ihrem PATH hinzufügen, damit Sie von überall Zugriff auf die LDAP-Kommandozeilentools haben.

Der OpenLDAP-Serverdienst trägt den Namen slapd. Seine Hauptkonfigurationsdatei befindet sich unter /etc/openldap/slapd.conf.

Damit ein Zugriff auf den LDAP-Server überhaupt möglich ist, müssen Sie die beiden Einträge suffix (die Wurzel des LDAP-Baums) und rootdn (DN des Verwaltungs-Users) editieren. Im Allgemeinen ist es üblich, dass der rootdn den Common Name Manager trägt; darauf folgen dieselben Domain-Komponenten wie beim suffix. Beispiel:

suffix       "dc=lingoworld,dc=de" 
rootdn       "cn=Manager,dc=lingoworld,dc=de"

Zudem benötigt der rootdn ein Passwort. Standardmäßig lautet die betreffende Zeile:

rootpw       secret

Sie sollten das Passwort secret mindestens ändern; für den Produktiveinsatz empfiehlt sich zudem die Verwendung eines verschlüsselten Passworts. Dazu wird der Name des Verschlüsselungsalgorithmus in geschweiften Klammern angegeben, dahinter das Base64-codierte Passwort in der entsprechenden Verschlüsselung. Hier ein Beispiel für das MD5-verschlüsselte Passwort "geheim" (in der Praxis natürlich auch keine gute Wahl):

rootpw       {MD5}6GNuoBPmgvr2H1bOHLGrXA==

Ein Passwort-Verschlüsselungs-Skript

Da OpenLDAP selbst keine Verschlüsselungs-Tools bereitstellt, können Sie beispielsweise das folgende kleine Ruby-Skript verwenden, das den auf der Kommandozeile angegebenen String MD5-verschlüsselt und dann Base64-codiert:

require "digest/md5" 
require "base64" 
if ARGV[0] 
  passwd = ARGV[0] 
  digest = Digest::MD5.digest(passwd) 
  b64 = Base64.encode64(digest) 
  puts "MD5 encrypted password in base64:", b64 
else 
  STDERR.puts "Usage: ruby encrypt.rb <password>" 
end

Speichern Sie dieses Skript unter dem Namen encrypt.rb und rufen Sie es beispielsweise wie folgt auf, um das Passwort hallo zu codieren:

> ruby encrypt.rb hallo 
MD5 encrypted password in base64: 
WY1MIARhuBUiozKFZcJffA==

Nach einer solchen Konfigurationsänderung müssen Sie den OpenLDAP-Server mit der zu Ihrem Betriebssystem passenden Methode neu starten. Alternativ werten OpenLDAP-Versionen ab 2.3 die Konfigurationsdateien im Verzeichnis /etc/openldap/slapd.d zur Laufzeit aus, erlauben also Konfigurationsänderungen ohne Neustart.

LDIF-Dateien einlesen

Sobald der Server läuft, können Sie Einträge erzeugen und ihn anderweitig nutzen. Die einfachste Methode besteht darin, die gewünschten Einträge im LDIF-Format in Textdateien zu schreiben und dann mithilfe der OpenLDAP-Kommandozeilentools einzulesen. Das folgende Beispiel legt die LDAP-Wurzel für lingoworld.de, die Organisationseinheiten people und developers sowie den Beispiel-User-Account sascha an:

dn: dc=lingoworld,dc=de 
dc: lingoworld 
objectClass: dcObject 
objectClass: organizationalUnit 
ou: lingoworld.de 
 
dn: ou=people,dc=lingoworld,dc=de 
ou: people 
objectClass: organizationalUnit 
 
dn: ou=developers,ou=people,dc=lingoworld,dc=de 
ou: developers 
objectClass: organizationalUnit 
 
dn: uid=sascha,ou=developers,ou=people,dc=lingoworld,dc=de 
objectClass: posixAccount 
uid: sascha 
cn: Sascha Kersken 
uidNumber: 1001 
gidNumber: 100 
gecos: Sascha Kersken 
userPassword: {MD5}GzIxZVzrt6H3g+3fJ9JUyg== 
homeDirectory: /home/sascha
loginShell: /bin/bash

Das noch nicht besprochene Attribut gecos steht für das gleichnamige /etc/passwd-Feld mit dem ausführlichen Beschreibungstext.

ldapadd

Angenommen, die Datei heißt data.ldif. Dann können Sie Folgendes eingeben, um sie zu Ihrem LDAP-Verzeichnis hinzuzufügen:

# ldapadd -x -f data.ldif \ 
-D "cn=manager,dc=lingoworld,dc=de" -W

Die Option -x bedeutet, dass Klartext-Authentifizierung verwendet werden soll und kann weggelassen werden, wenn Sie das rootdn-Passwort empfehlungsgemäß verschlüsselt haben. -f Dateiname gibt die Datei an, aus der ldapadd lesen soll. -D gibt den rootdn an und -W fordert die Passworteingabeaufforderung in der nächsten Zeile an.

Weitere interessante LDAP-Kommandozeilentools sind ldapmodify, das einen existierenden Eintrag ändert (ldapadd ist eigentlich nur ein ldapmodify-Aufruf mit der Option –a), sowie ldapsearch, das im LDAP-Verzeichnis nach Einträgen sucht.

ldapsearch

Geben Sie beispielsweise Folgendes ein, um alle Einträge Ihres Verzeichnisses zu lesen (hier aus Platzgründen mit der Beispielausgabe vor Hinzufügen des User-Eintrags):

# ldapsearch -x -D "cn=Manager,dc=lingoworld,dc=de" \ 
-b "dc=lingoworld,dc=de" "(objectclass=*)" 
Enter LDAP Password: # extended LDIF 
# 
# LDAPv3 
# base <dc=lingoworld,dc=de> with scope sub 
# filter: (objectClass=*) 
# requesting: ALL 
# 
 
# lingoworld.de 
dn: dc=lingoworld,dc=de 
dc: lingoworld 
objectClass: dcObject 
objectClass: organizationalUnit 
ou: lingoworld.de 
 
# people, lingoworld.de 
dn: ou=people,dc=lingoworld,dc=de 
ou: people 
objectClass: organizationalUnit 
 
# developers, people, lingoworld.de 
dn: ou=developers,ou=people,dc=lingoworld,dc=de 
ou: developers 
objectClass: organizationalUnit 
 
# search result 
search: 2 
result: 0 Success 
 
# numResponses: 4
# numEntries: 3

Die Optionen -x und -D wurden bereits erläutert. Die Option -b gibt den DN der Basis an, unter der gesucht werden soll. "(objectclass=*)" ist ein LDAP-Filter. Da jeder LDAP-Eintrag ein objectClass-Attribut besitzen muss, trifft dieser Filter auf jeden Knoten des Verzeichnisses zu.

LDAP-Filter

In LDAP-Filtern steht jedes Suchkriterium in Klammern. Das Sternchen (*) kann als Platzhalter für ganze Werte oder Teile von ihnen eingesetzt werden. Neben der Vergleichsoperation = können beispielsweise auch <= für kleiner oder gleich beziehungsweise >= für größer oder gleich zum Einsatz kommen.

Wenn Sie mehrere Kriterien verknüpfen möchten, funktioniert dies wie folgt: (|(Kriterium 1)(Kriterium 2)) kombiniert die beiden Kriterien per logischem Oder; es genügt also, wenn eines von ihnen zutrifft. (&(Kriterium 1)(Kriterium 2)) ist dagegen das logische Und, das heißt, beide Kriterien müssen erfüllt sein.

phpLDAPadmin

Mehr Komfort als diese Konsolen-Kommandos bieten grafische LDAP-Clients. Einer der empfehlenswerstesten ist phpLDAPadmin, der unter http://phpldapadmin.sourceforge.net zum Download bereitsteht. Er wird – ähnlich wie das im vorigen Kapitel vorgestellte MySQL-Administrations-Tool phpMyAdmin – als PHP-Anwendung auf einem Webserver installiert. Sie brauchen das Paket nur in Ihr Webserver-Verzeichnis zu kopieren, die Konfigurationsdatei conf/config.php anzupassen (zum Beispiel die URL Ihres LDAP-Servers eintragen) und die betreffende URL im Browser zu öffnen. Abbildung 13.1 zeigt einen LDAP-Beispieleintrag in phpLDAPadmin.

Abbildung 13.1    phpLDAPadmin im Einsatz

Einsatzbeispiele

LDAP-Verzeichnisse können für unzählige Verwaltungs- und Informationsaufgaben eingesetzt werden. An dieser Stelle lernen Sie zwei von ihnen im Schnellüberblick kennen: den LDAP-basierten System-Login unter Linux sowie die LDAP-basierte Authentifizierung gegenüber einem Apache-Webserver.

LDAP- Benutzer- anmeldung

Die Systemanmeldung über LDAP funktioniert unter Linux über die PAM-Schnittstelle (Pluggable Authentication Modules). Als Erstes muss die Datei /etc/nsswitch.conf editiert werden. Sie bestimmt, aus welchen Quellen überhaupt Anmeldedaten gelesen werden. Wichtig sind die folgenden drei Einträge:

passwd: files ldap 
shadow: files ldap 
group:  files ldap

Diese Zeilen bestimmen die Herkunft der /etc/passwd-, /etc/shadow- und /etc/group-Daten. files sind die jeweiligen lokalen Originaldateien. Dieser Wert sollte niemals entfernt werden, da Sie sonst ausgesperrt sind, sobald der LDAP-Server ausfällt (insbesondere natürlich, wenn dieser auf localhost läuft). Insbesondere das Verwalterkonto root muss stets lokal definiert bleiben.

Anschließend müssen Sie dafür sorgen, dass die Konfigurationsdatei /etc/pam.d/login Zeilen wie diese enthält:

auth     sufficient  /lib/security/pam_ldap.so 
account  sufficient  /lib/security/pam_ldap.so 
password sufficient /lib/security/pam_ldap.so use_authtok

auth besagt, dass die Anmeldung anhand des LDAP-Verzeichnisses überprüft werden soll; account liest auch die Benutzerkonteneinstellungen daraus. Die password-Zeile sorgt dafür, dass das eingegebene Passwort zum Vergleich an den LDAP-Server weitergereicht wird. Mit sufficient wird jeweils festgelegt, dass die LDAP-Überprüfung allein genügt und dass der Zugang nicht mehr von anderen Voraussetzungen abhängt.

Viele Betriebssysteme enthalten eingebaute Hilfsmittel, mit denen Sie die LDAP-basierte Authentifizierung leichter einstellen können. Unter openSUSE können Sie beispielsweise das Konfigurationsprogramm YaST starten, Sicherheit und Benutzer • Benutzer anlegen und bearbeiten wählen und darin den Punkt Optionen für Experten • Authentifizierung und Benutzerquellen auswählen. Dort finden Sie den Punkt LDAP, den Sie anklicken können, um alles bequem einzustellen.

LDAP-Web-Authentifizierung

Falls Sie den Zugang zu Web-Verzeichnissen Ihres Apache-Servers über LDAP kontrollieren möchten, müssen Sie in der Datei httpd.conf zunächst überprüfen, ob die beiden zugehörigen Module geladen werden:

LoadModules ldap_module modules/mod_ldap.so 
LoadModules authnz_ldap_module modules/mod_authnz_ldap.so

Anschließend können Sie in Apache 2.2 eine Konfiguration nach dem folgenden Schema verwenden, um den Schutz eines Verzeichnisses mithilfe eines LDAP-Servers zu überprüfen:

<Directory /usr/local/apache2/htdocs/ldap-schutz> 
    AuthType basic 
    AuthBasicProvider ldap 
    AuthName "LDAP-geschütztes Verzeichnis" 
    AuthLDAPUrl \ 
        "ldap://localhost/dc=lingoworld,dc=de?uid?sub 
    AuthLDAPBindDN "cn=Manager,dc=lingoworld,dc=de" 
    AuthLDAPBindPassword geheim 
    Require valid-user 
</Directory>

Starten Sie Apache neu, nachdem Sie eine solche Konfiguration erzeugt haben. Beim nächsten Zugriff auf das betreffende Verzeichnis zeigt der Browser einen Log-in-Dialog an. Hier müssen Sie eine gültige uid und das zugehörige Passwort eingeben.

Im Einzelnen bedeuten die verwendeten Konfigurationsdirektiven Folgendes (hier nur ganz kurz, da einige von ihnen bereits im vorigen Kapitel erläutert wurden):

• AuthType basic – Datenübertragung vom Browser zum Server im Klartext; mod_authnz_ldap arbeitet leider noch nicht mit mod_auth_digest zusammen

• AuthBasicProvider ldap – als Provider-Modul zur Überprüfung der Anmeldedaten wird mod_authnz_ldap ausgewählt

• AuthName – der Realm, das heißt der gemeinsame Name des Authentifizierungsbereichs

• AuthLDAPUrl – die URL des LDAP-Servers. Sie besitzt folgenden Aufbau:

ldap[s]://Host[:Port] [Host ...]/Basis-DN?Attribut?Tiefe

• • Die einzelnen Komponenten bedeuten Folgendes:

Protokoll, ldap:// (Klartext) oder ldaps:// (SSL-verschlüsselt, falls konfiguriert)

Hostname des LDAP-Servers; wenn er nicht auf Port 389 (ldap) beziehungsweise 636 (ldaps) läuft, müssen Sie hinter einem Doppelpunkt auch die Portnummer angeben. Optional können Sie zur Ausfallsicherung mehrere Hosts durch Leerzeichen trennen.

Basis-DN – der DN des LDAP-Knotens unter dem gesucht werden soll

Zu vergleichendes Attribut; meist uid (Standard) oder cn

Suchtiefe; one für den Basis-DN selbst oder sub für diesen und alle seine Unterbereiche

• • Weitere Optionen sind möglich. Eine ausführliche Liste finden Sie beispielsweise in der Beschreibung der Direktive AuthLDAPUrl auf der Website zu meinem Buch Apache 2 unter der Adresse http://buecher.lingoworld.de/apache2/showdir.php?id=478.

• AuthLDAPBindDN – Wenn Ihr LDAP-Server nicht für anonyme Lesezugriffe konfiguriert ist, müssen Sie mithilfe dieser Direktive den DN eines zugriffsberechtigten Benutzers anegeben.

• AuthLDAPBindPassword – das Passwort des berechtigten LDAP-Users

• Require – gibt an, welche der im durchdurchten Teil des LDAP-Verzeichnisses vorgefundenen User sich anmelden dürfen. Neben den allgemeinen Apache-Vorgaben user Username, group Gruppenname und valid-user (alle User aus dem angegebenen Bereich) gibt es einige LDAP-spezische Werte:

ldap-dn – der DN eines bestimmten Users, zum Beispiel ldap-dn "uid=sascha, ou=developers, ou=people, dc=lingoworld, dc=de"

ldap-attribute – ein Attribut mit einem Vergleichswert, etwa ldap-attribute cell=* für alle User, für die ein Mobiltelefon eingetragen ist

ldap-filter – ein LDAP-Filter; beispielsweise akzeptiert ldap-filter "(&(ou=developers)(sn=Schmitz))" nur User namens Schmitz aus der Abteilung deveopers.

Ihr Kommentar