14 Weitere Internet-Serverdienste

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

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

14.1 Namens- und Verzeichnisdienste

Bereits in Kapitel 4, »Netzwerkgrundlagen«, wurde die Theorie des Domain Name Systems (DNS) 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 Abschnitt wird der Open-Source-Verzeichnisserver OpenLDAP vorgestellt.

14.1.1 Der DNS-Server BIND

Es gibt verschiedene Implementierungen von Serversoftware, 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.8.5.

Bitte installieren Sie in jedem Fall eine aktuelle Version von BIND. Dieser Hinweis gilt aus Sicherheitsgründen für jede Software, aber im Fall von Nameservern ist es besonders wichtig, sich daran zu halten: Eine 2008 entdeckte Schwachstelle in der DNS-Konzeption – nämlich die zu leicht vorhersagbare Abfolge der Sequenznummern von Zonendaten – führte dazu, dass sich der Cache von DNS-Servern mit gefälschten Informationen befüllen ließ. Da sich praktisch sämtliche Internetfunktionalität auf DNS verlässt, ist dies sehr gefährlich. Beispielsweise könnten Webbenutzer auf perfekt gefälschte Websites umgeleitet werden, die dann Viren und Trojaner verbreiten.

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 mit dem globalen DNS kompatibel ist.

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.8.5-P1.tar.gz
# cd bind-9.8.5-P1
```
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«.

Die Konfigurationsdaten von BIND bestehen aus zwei verschiedenen Arten von 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 Domainnamen. Der Name dieser Zone hängt von der Größe des Subnets ab, in dem sie sich befindet: Es handelt sich um den umgekehrten Netzwerkteil der IP-Adresse mit dem reservierten Domainnamen 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 {
   8.8.8.8;
   81.173.194.77;
   194.8.194.60
};
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 Google und 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.)

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, Serverdienste 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

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

MNAME: Repräsentiert den Hostnamen 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: Legt fest, 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« und so weiter) 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.

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 Webserverbetreiber ist es oft nützlich, wenn der reine Domainname (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

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, muss dieser Record in der Zone stehen, in die der Alias 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 Serverressourcen beispielsweise auch von der Dateigröße der ausgelieferten Dokumente abhängt und nicht nur von der reinen Anzahl der Namensanfragen.

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 delegieren Sie übrigens auch untergeordnete Zonen: Für eine Subdomain geben Sie einfach einen anderen Nameserver an. 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 hinterlegt 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

Zu guter Letzt benötigen Sie noch MX-Records (Mail Exchange) für die Angabe von Mailzielen. 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.

14.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.

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.

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 Domainnamens 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.

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 verwenden Sie besser zusätzlich die erweiterte Objektklasse inetOrgPerson, da person selbst beispielsweise keinen Standardeintrag für eine E-Mail-Adresse enthält (inetOrgPerson allein funktioniert übrigens nicht, da stets mindestens eine sogenannte strukturelle Objektklasse verwendet werden muss; person ist eine solche).

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. Beachten Sie, dass auch diese Objektklassen im Gegensatz zu person nicht strukturell sind.

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

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

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- oder 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: die numerische ID der primären Gruppe dieses Benutzers
userPassword: Zunächst steht in geschweiften Klammern der verwendete Verschlüsselungsalgorithmus, dahinter das entsprechend verschlüsselte Passwort selbst (im nächsten Abschnitt 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.

Für Windows gibt es inzwischen einen binären Installer in der aktuellen Version 2.4; Sie können ihn unter http://www.userbooster.de/en/download/openldap-for-windows.aspx 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 Domainkomponenten 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 keine gute Wahl):

rootpw       {MD5}6GNuoBPmgvr2H1bOHLGrXA==

Da OpenLDAP selbst keine Verschlüsselungs-Tools bereitstellt,[Anm.: Neuere Versionen des mit OpenLDAP gelieferten Hilfsprogramms ldappasswd oder slappasswd verschlüsseln die Passwörter allerdings mit dem in der Konfigurationsdatei angegebenen Verschlüsselungsalgorithmus.] 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 seit 2.3 die Konfigurationsdateien im Verzeichnis /etc/openldap/slapd.d zur Laufzeit aus, erlauben also Konfigurationsänderungen ohne Neustart.

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: person
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.

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; sie 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 Passworteingabe-Aufforderung 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.

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.

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.

Abbildung 14.1 phpLDAPadmin im Einsatz

Mehr Komfort als diese Konsolenkommandos bieten grafische LDAP-Clients. Einer der empfehlenswertesten ist phpLDAPadmin, der unter http://phpldapadmin.sourceforge.net zum Download bereitsteht. Er wird – ähnlich wie das in Kapitel 12, »Datenbanken«, vorgestellte MySQL-Administrationstool phpMyAdmin – als PHP-Anwendung auf einem Webserver installiert. Sie brauchen das Paket nur in Ihr Webserververzeichnis 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 14.1 zeigt einen LDAP-Beispieleintrag in phpLDAPadmin.

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.

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). Vor allem 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 aufrufen 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.

Falls Sie den Zugang zu Webverzeichnissen 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 oder neuer 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 – steht für den Realm, das heißt den gemeinsamen Namen 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 angeben.
AuthLDAPBindPassword – das Passwort des berechtigten LDAP-Users
Require – gibt an, welche der im durchsuchten 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-spezifische 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 developers.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

Name
E-Mail
Ihr Kommentar