Product SiteDocumentation Site

11.7. LDAP-Verzeichnis

OpenLDAP ist eine Umsetzung des LDAP-Protokolls; mit anderen Worten, es ist eine Spezialdatenbank zum Speichern von Verzeichnissen. Im gebräuchlichsten Anwendungsfall macht die Verwendung eines LDAP-Servers es möglich, die Verwaltung von Benutzerkonten und der dazugehörigen Berechtigungen zusammenzufassen. Außerdem lässt sich eine LDAP-Datenbank leicht kopieren, wodurch die Einrichtung mehrerer synchronisierter LDAP-Server möglich wird. Wenn das Netzwerk und die Benutzerzahl schnell anwachsen, kann so die Arbeitslast auf mehrere Server verteilt werden.
LDAP-Daten sind strukturiert und hierarchisch. Die Struktur wird durch „Schemata“ festgelegt, die die Art der Objekte, die die Datenbank speichern kann, zusammen mit einer Liste all ihrer möglichen Attribute beschreiben. Die Syntax, die zum Verweis auf ein bestimmtes Objekt der Datenbank verwendet wird, basiert auf diesen Strukturen, wodurch sich ihre Komplexität erklärt.

11.7.1. Installieren

Das Paket slapd enthält den OpenLDAP-Server. Das Paket ldap-utils umfasst Befehlszeilen-Werkzeuge für die Zusammenarbeit mit LDAP-Servern.
Die Installation von slapd läuft üblicherweise nicht interaktiv ab, es sei denn Sie haben debconf so konfiguriert, dass es Fragen mit niedriger Priorität anzeigt. Nichtsdestotrotz ist es debconf-fähig, und die LDAP-Datenbank kann deshalb mit einem einfachen Befehl dpkg-reconfigure slapd neu konfiguriert werden:
  • Konfigurierung des OpenLDAP-Servers auslassen? Natürlich nicht, wir wollen diesen Dienst konfigurieren.
  • DNS-Domain-Name: „falcot.com“.
  • Name der Organisation: „Falcot Corp.“.
  • Ein Verwaltungspasswort muss eingegeben werden.
  • Zu verwendendes Datenbank-Backend: „HDB“.
  • Möchten Sie, dass die Datenbank entfernt wird, wenn slapd gelöscht wird? Nein. Es wäre nicht sinnvoll, den Verlust der Datenbank im Falle eines Versehens zu riskieren.
  • Die alte Datenbank verschieben? Diese Frage wird nur gestellt, wenn die Konfigurierung vorgenommen wird, während eine Datenbank bereits existiert. Antworten Sie nur mit „ja“, wenn Sie tatsächlich wieder mit einer leeren Datenbank beginnen möchten, zum Beispiel, wenn Sie dpkg-reconfigure slapd unmittelbar nach der ersten Installierung ausführen.
  • Das LDAPv2-Protokoll erlauben? Nein, das macht keinen Sinn. Alle Programme, die wir verwenden werden, verstehen das LDAPv3-Protokoll.
Eine minimale Datenbank ist jetzt konfiguriert, wie die folgende Anfrage zeigt:
$ ldapsearch -x -b dc=falcot,dc=com
# extended LDIF
#
# LDAPv3
# base <dc=falcot,dc=com> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#

# falcot.com
dn: dc=falcot,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: Falcot Corp
dc: falcot

# admin, falcot.com
dn: cn=admin,dc=falcot,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2
Die Anfrage ergibt zwei Objekte: die Organisation selbst und den verwaltenden Benutzer.

11.7.2. Das Verzeichnis ausfüllen

Da eine leere Datenbank nicht sehr nützlich ist, werden wir alle bestehenden Verzeichnisse in sie einspeisen; hierzu gehören die Benutzer-, Gruppen-, Dienst- und Host-Datenbanken.
Das Paket migrationtools stellt einen Satz von Skripten bereit, die dazu dienen, Daten aus den Standard-Unix-Verzeichnissen (/etc/passwd, /etc/group, /etc/services, /etc/hosts und so weiter) zu extrahieren, diese Daten zu konvertieren und sie in die LDAP-Datenbank einzuspeisen.
Nachdem das Paket installiert ist, muss die Datei /etc/migrationtools/migrate_common.ph editiert werden; die Optionen IGNORE_UID_BELOW and IGNORE_GID_BELOW müssen aktiviert werden (es genügt, das Kommentarzeichen zu entfernen) und die Variablen DEFAULT_MAIL_DOMAIN/DEFAULT_BASE müssen aktualisiert werden.
Der tatsächliche Übertragungsvorgang wird mit dem Befehl migrate_all_online.sh folgendermaßen ausgeführt:
# cd /usr/share/migrationtools
# LDAPADD="/usr/bin/ldapadd -c" ETC_ALIASES=/dev/null ./migrate_all_online.sh
Das Skript migrate_all_online.sh stellt einige Fragen zur LDAP-Datenbank, auf die die Daten übertragen werden sollen. Tabelle 11.1 fasst die Antworten zusammen, die im Fallbeispiel Falcot gegeben wurden.

Tabelle 11.1. Antworten auf die vom Skript migrate_all_online.sh gestellten Fragen

Frage Antwort
X.500 Benennungskontext dc=falcot,dc=com
Hostname des LDAP-Servers localhost
Manager-DN cn=admin,dc=falcot,dc=com
Verbindungslegitimation das Verwaltungspasswort
Ein DUAConfigProfil anlegen nein

Wir haben bewusst die Übertragung der Datei /etc/aliases außerachtgelassen, da das von Debian bereitgestellte Standardschema nicht die Strukturen enthält, die dieses Skript zur Beschreibung der E-Mail-Aliasse verwendet. Falls wir diese Daten in das Verzeichnis integrieren möchten, müssen wir die Datei /etc/ldap/schema/misc.schema zum Standardschema hinzufügen.
Beachten Sie auch die Verwendung der Option -c des Befehls ldapadd; diese Option bestimmt, dass der Verarbeitungsablauf im Falle eines Fehlers nicht abgebrochen wird. Die Verwendung dieser Option ist notwendig, da die Konvertierung der Datei /etc/services häufig einige Fehler hervorruft, die ohne Gefahr ignoriert werden können.

11.7.3. Konten mit LDAP verwalten

Jetzt, da die LDAP-Datenbank einige nützliche Informationen enthält, ist es an der Zeit diese Daten zu nutzen. Dieser Abschnitt richtet sein Augenmerk darauf, wie ein Linux-System so zu konfigurieren ist, dass die verschiedenen Systemverzeichnisse die LDAP-Datenbank benutzen.

11.7.3.1. NSS konfigurieren

Das NSS-System (Name Service Switch, siehe Seitenleiste WEITERE SCHRITTE NSS und Systemdatenbanken) ist ein modulares System, das Informationen für Systemverzeichnisse festlegen oder einholen kann. Um LDAP als Datenquelle für NSS verwenden zu können, muss das Paket libnss-ldap installiert werden. Bei seiner Installierung werden einige Fragen gestellt; die Antworten sind in Tabelle 11.2 zusammengefasst.

Tabelle 11.2. Das Paket libnss-ldap konfigurieren

Frage Antwort
Uniform Resource Identifier des LDAP-Servers ldap://ldap.falcot.com
Kennzeichnender Name der Suchbasis dc=falcot,dc=com
Zu verwendende LDAP-Version 3
Benötigt die LDAP-Datenbank eine Anmeldung? nein
Spezielle LDAP-Privilegien für den Benutzer Root ja
Erlauben Sie nur dem Eigentümer Lese/Schreibzugriff auf die Konfigurationsdatei nein
LDAP-Administratorkonto cn=admin,dc=falcot,dc=com
Passwort des LDAP-Administratorkontos das Verwaltungspasswort

Die Datei /etc/nsswitch.conf muss nun angepasst werden, um NSS so zu konfigurieren, dass es das neu installierte ldap-Modul benutzt.

Beispiel 11.30. Die Datei /etc/nsswitch.conf

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: ldap compat
group: ldap compat
shadow: ldap compat

hosts: files dns ldap
networks: ldap files

protocols: ldap db files
services: ldap db files
ethers: ldap db files
rpc: ldap db files

netgroup: ldap files

Das ldap-Modul wird normalerweise vor den anderen aufgenommen und wird daher zuerst abgefragt. Eine beachtenswerte Ausnahme stellt der hosts-Dienst dar, da zunächst der DNS befragt werden muss (um ldap.falcot.com aufzulösen), bevor mit dem LDAP-Server Verbindung aufgenommen werden kann. Ohne diese Ausnahme würde eine Anfrage nach einem Hostnamen an den LDAP-Server gerichtet; dies würde eine Namensauflösung für den LDAP-Server auslösen, und so weiter in einer unendlichen Schleife.
Falls der LDAP-Server als maßgeblich angesehen werden soll (und die lokalen vom Modul files benutzten Dateien ignoriert werden sollen), können die Dienste mit der folgenden Syntax konfiguriert werden:
dienst: ldap [NOTFOUND=return] files.
Falls der gesuchte Eintrag in der LDAP-Datenbank nicht vorhanden ist, wird die Anfrage die Antwort „nicht vorhanden“ ergeben, selbst wenn er in einer der lokalen Dateien vorhanden ist; diese lokalen Dateien werden nur benutzt, wenn der LDAP-Service abgeschaltet ist.

11.7.3.2. PAM konfigurieren

Dieser Abschnitt beschreibt die Konfiguration von PAM (siehe Seitenleiste HINTER DEN KULISSEN /etc/environment und /etc/default/locale), die es Anwendungen ermöglicht, die gegenüber der LDAP-Datenbank erforderlichen Authentifizierungen vorzunehmen.
Das LDAP-Modul für PAM wird von dem Paket libpam-ldap bereitgestellt. Beim Installieren dieses Pakets werden einige Fragen gestellt, die denen bei libnss-ldap ähnlich sind; einige Konfigurationsparameter (wie zum Beispiel die URI des LDAP-Servers) werden sogar mit dem Paket libnss-ldap gemeinsam benutzt. Die Antworten sind in Tabelle 11.3 zusammengefasst.

Tabelle 11.3. Konfigurierung von libpam-ldap

Frage Antwort
Dem LDAP-Administrationskonto erlauben, sich wie lokales Root zu verhalten? Ja. Dies ermöglicht es, den normalen passwd-Befehl zur Änderung von Passwörtern zu verwenden, die in der LDAP-Datenbank gespeichert sind.
Erfordert die LDAP-Datenbank eine Anmeldung? nein
LDAP-Administratorkonto cn=admin,dc=falcot,dc=com
Passwort des LDAP-Administratorkontos das Verwaltungspasswort der LDAP-Datenbank
Lokaler Verschlüsselungsalgorithmus für Passwörter crypt

Durch das Installieren von libpam-ldap wird die standardmäßige PAM-Konfiguration, die in den Dateien /etc/pam.d/common-auth, /etc/pam.d/common-password und /etc/pam.d/common-account festgelegt ist, automatisch angepasst. Dieser Vorgang verwendet das spezielle Hilfsprogramm pam-auth-update (vom Paket libpam-runtime bereitgestellt). Dieses Programm kann auch vom Administrator eingesetzt werden, falls er PAM-Module aktivieren oder deaktivieren möchte.

11.7.3.3. LDAP-Datenaustausch absichern

Standardmäßig überträgt das LDAP-Protokoll im Klartext über das Netzwerk; dies gilt auch für die (verschlüsselten) Passwörter. Da die verschlüsselten Passwörter aus dem Netzwerk entnommen werden können, können sie anfällig für Wörterbuchangriffe sein. Dies kann durch den Einsatz einer zusätzlichen Verschlüsselungsschicht verhindert werden; die Aktivierung dieser Schicht ist das Thema dieses Abschnitts.
11.7.3.3.1. Den Server konfigurieren
Der erste Schritt besteht darin, für den LDAP-Server ein Schlüsselpaar (bestehend aus einem öffentlichen und einem privaten Schlüssel) zu erzeugen. Die Administratoren bei Falcot erzeugen diesen wiederum unter Verwendung von easy-rsa (siehe Abschnitt 10.2.1.1, „Public-Key-Infrastrultur: easy-rsa). Beim Aufruf von ./build-server-key ldap.falcot.com werden einige banale Fragen gestellt (Ort, Name der Organisation und so weiter). Als Antwort auf die Frage nach dem "common name" muss der vollständig qualifizierte Hostname des LDAP-Servers angegeben werden; in unserem Fall ldap.falcot.com.
Dieser Befehl erstellt ein Zertifikat in der Datei keys/ldap.falcot.com.crt; der dazugehörige private Schlüssel wird in der Datei keys/ldap.falcot.com.key abgespeichert.
Jetzt müssen diese Schlüssel an ihrem Standard-Platz installiert werden, und wir müssen dafür Sorge tragen, dass die private Datei vom LDAP-Sever gelesen werden kann, der unter der Userkennung openldap läuft:
# adduser openldap ssl-cert
Adding user `openldap' to group `ssl-cert' ...
Adding user openldap to group ssl-cert
Done.
# mv keys/ldap.falcot.com.key /etc/ssl/private/ldap.falcot.com.key
# chown root:ssl-cert /etc/ssl/private/ldap.falcot.com.key
# chmod 0640 /etc/ssl/private/ldap.falcot.com.key
# mv newcert.pem /etc/ssl/certs/ldap.falcot.com.pem
Der Hintergrundprozess slapd muss ebenfalls dazu gebracht werden, diese Schlüssel für die Verschlüsselung zu verwenden. Die Konfiguration des LDAP-Servers wird dynamisch verwaltet: die Konfiguration kann mit normalen LDAP-Operationen innerhalb der Objekt-Hierarchie cn=config aktualisiert werden und der Server aktualisiert /etc/ldap/slapd.d in Echtzeit um die Konfiguration durchgängig zu halten. Ldapmodify ist also das geeignete Werkzeug um die Konfiguration zu aktualisieren:

Beispiel 11.31. slapd für eine Verschlüsselung konfigurieren

# cat >ssl.ldif <<END
dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap.falcot.com.key
-
END
# ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

Der letzte Schritt zur Aktivierung der Verschlüsselung besteht darin, die Variable SLAPD_SERVICES in der Datei /etc/default/slapd zu ändern. Wir gehen dabei auf Nummer Sicher und deaktivieren nicht abgesichertes LDAP vollständig.

Beispiel 11.32. Die Datei /etc/default/slapd

# Default location of the slapd.conf file or slapd.d cn=config directory. If
# empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to
# /etc/ldap/slapd.conf).
SLAPD_CONF=

# System account to run the slapd server under. If empty the server
# will run as root.
SLAPD_USER="openldap"

# System group to run the slapd server under. If empty the server will
# run in the primary group of its user.
SLAPD_GROUP="openldap"

# Path to the pid file of the slapd server. If not set the init.d script
# will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.conf by
# default)
SLAPD_PIDFILE=

# slapd normally serves ldap only on all TCP-ports 389. slapd can also
# service requests on TCP-port 636 (ldaps) and requests via unix
# sockets.
# Example usage:
# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
SLAPD_SERVICES="ldaps:/// ldapi:///"

# If SLAPD_NO_START is set, the init script will not start or restart
# slapd (but stop will still work).  Uncomment this if you are
# starting slapd via some other means or if you don't want slapd normally
# started at boot.
#SLAPD_NO_START=1

# If SLAPD_SENTINEL_FILE is set to path to a file and that file exists,
# the init script will not start or restart slapd (but stop will still
# work).  Use this for temporarily disabling startup of slapd (when doing
# maintenance, for example, or through a configuration management system)
# when you don't want to edit a configuration file.
SLAPD_SENTINEL_FILE=/etc/ldap/noslapd

# For Kerberos authentication (via SASL), slapd by default uses the system
# keytab file (/etc/krb5.keytab).  To use a different keytab file,
# uncomment this line and change the path.
#export KRB5_KTNAME=/etc/krb5.keytab

# Additional options to pass to slapd
SLAPD_OPTIONS=""

11.7.3.3.2. Den Client konfigurieren
Auf der Client-Seite muss die Konfiguration der Module libpam-ldap und libnss-ldap angepasst werden um einen ldaps:// URI zu nutzen zu können.
LDAP-Clients müssen auch in der Lage sein, den Server zu authentifizieren. In einer X.500 Public-Key-Infrastruktur werden öffentliche Zertifikate mit dem Schlüssel einer Zertifikatsausgabestelle (CA, certificate authority) signiert. Mit easy-rsa haben die Administratoren von Falcot ihre eigene Zertifikatsstelle erzeugt und jetzt müssen sie das System so konfigurieren, dass es den Unterschriften der Zertifikatsstelle von Falcot vertraut. Das tut man, indem man das CA-Zertifikat in /usr/local/share/ca-certificates einträgt und dann update-ca-certificates startet.
# cp keys/ca.crt /usr/local/share/ca-certificates/falcot.crt
# update-ca-certificates
Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
Adding debian:falcot.pem
done.
done.
Nicht zuletzt kann der voreingestellte URI und die Basis-DN, die von diversen Kommandozeilen-Tools verwendet werden, können in /etc/ldap/ldap.conf geändert werden. Das erspart einiges an Tipparbeit.

Beispiel 11.33. Die Datei /etc/ldap/ldap.conf

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE   dc=falcot,dc=com
URI    ldaps://ldap.falcot.com

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

# TLS certificates (needed for GnuTLS)
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

Dieses Kapitel hat nur einen Bruchteil der verfügbaren Serversoftware dargestellt; jedoch wurden die meisten der üblichen Netzwerkdienste beschrieben. Jetzt ist es Zeit für ein noch technischeres Kapitel: wir werden tiefer in die Einzelheiten einiger Konzepte eindringen, sowie Masseneinsätze und Virtualisierungen beschreiben.