Workshop: Open Source-Tipp

Im Gegensatz zu relationalen Datenbanken sind LDAP-Server hierarchisch aufgebaut und eignen sich daher gut, um unterschiedliche Daten zu verwalten. Das können Benutzer- und Gruppen-Konten sein, Adress- und Telefoninformationen für Angestellte einer Firma, Konfigurationsdaten eines Infrastruktur-Dienstes oder Ähnliches. Den Zugriff auf diese Daten schränken IT-Verantwortliche am LDAP-Server über authentifizierte Benutzer ein. Je nachdem, welcher Benutzer sich anmeldet, gibt der Server mehr oder weniger Informationen preis. Zur Authentifizierung eines Benutzers wird dabei oftmals ein sogenanntes "simple bind" verwendet, das heißt, der Benutzer meldet sich mit Benutzernamen und Passwort am Server an. Funktioniert dies, so erhält der Benutzer Zugriff auf alle Daten, die für dieses Konto zugänglich sind.

Sichere Authentifizierung

Da statische Passwörter keine besonders sichere Variante zur Anmeldung an einem Server darstellen, lässt sich ein LDAP-Server auch für die SASL (Simple Authentication and Security Layer)-basierte Variante konfigurieren. Diese unterstützt eine Vielzahl von unterschiedlichen Authentifizierungs-Mechanismen, unter anderem auch GSSAPI für Kerberos sowie EXTERNAL in Kombination mit TLS (Transport Layer Security). Bei Letzterem muss ein Benutzer über ein X.509-Zertifikat verfügen, mit dem er sich dann gegenüber dem Server ausweist.

Anders als reine Passwörter stellen Zertifikate eine wesentlich sichere Variante zur Anmeldung an einem Service dar und lassen sich auch leicht zentral verwalten. So ist es beispielsweise möglich, ein kompromittiertes Zertifikat einfach über eine CRL (Certificate Revocation List) zu sperren und somit von der Anmeldung auszuschließen.

Zertifikate vorbereiten

In diesem Beispiel gehen wir davon aus, dass bereits ein OpenLDAP-Server mit Unterstützung für TLS vorhanden ist. Aktuelle Versionen von OpenLDAP (ab v2.3) verwenden eine dynamische Runtime-Konfigurations-Engine. Diese speichert sämtliche Konfigurationseinstellungen im LDAP-Container "cn=config" innerhalb der LDAP-Datenbank. Der Einfachheit halber verwenden wir an dieser Stelle die alte, aber immer noch unterstützte Konfigurationsdatei »slapd.conf« . Auf einem Fedora-System befindet diese sich im Verzeichnis »/etc/openldap« . Die Datei enthält entsprechende Einträge, wo der Server sein eigenes Zertifikat und den dazugehörigen privaten Schlüssel vorfindet:

# grep TLSCertificate

TLSCertificateFile /etc/openldap/server.crt

TLSCertificateKeyFile /etc/openldap/server.key

Desweiteren benötigt der Server die Information, an welcher Stelle die CA-Zertifikate liegen, mit denen der Server die Signaturen von Zertifikaten verifiziert:

# grep TLSCACertificate /etc/openldap/slapd.conf

TLSCACertificateFile /etc/openldap/nc-certs/ca.crt

An dieser Stelle sei erwähnt, dass OpenLDAP unterschiedliche Crypto-Bibliotheken und somit Zertifikatsformate unterstützt. In diesem Beispiel kommen OpenSSL-basierte Zertifikate zum Einsatz. Der Server unterstützt ebenfalls Zertifikate innerhalb einer NSS (Network Security Services)-Datenbank. Nutzen Sie diese Art von Zertifikaten, müssen die beiden Anweisungen »TLSCertificateFile« und »TLSCACertificateFile« das Label angeben, mit dem die Zertifikate innerhalb der NSS-Datenbank abgelegt wurden. Die Anweisung »TLSCertificateKeyFile« verweist auf eine Datei mit dem Passwort für das verwendete Zertifikat.

Ob der Zugriff mittels TLS auf den Server funktioniert, können Sie leicht mit einem einfachen »ldapsearch -x -ZZ« überprüfen. Die Option "-ZZ" teilt dem Server mit, dass die Verbindung auf dem Standard-LDAP-Port 389 verschlüsselt durchgeführt werden soll und "-x" sorgt dafür, dass ein simple bind durchgeführt wird – in diesem Fall anonym. Hierzu sollte der Client über eine Kopie des CA-Zertifikats verfügen, um die Signatur des Server-Zertifikats verifizieren zu können. Kopieren Sie das Zertifikat des Servers auf dem Client dafür in das Verzeichnis »/etc/openldap/cacerts/« . Wo das Zertifikat gefunden werden kann, teilen Sie den OpenLDAP Client-Tools über die folgende Anweisung in der Datei »/etc/openldap/ldap.conf« mit:

TLS_CACERT /etc/openldap/nc-certs/ca.crt

Sollte die Datei bereits existieren, so hängen Sie das neue CA-Zertifikat einfach hinten an die Datei. Damit der Server auch Benutzer auf Basis eines X.509-Zertifikats authentifizieren kann, ist zweierlei notwendig: Zum einen muss natürlich der Benutzer über ein entsprechendes Zertifikat verfügen und zum anderen muss der Server dieses auch anfordern und auf einen bestimmten LDAP-Benutzer mappen.

# openssl genrsa -out tscherf.key 1024
Generating RSA private key, 1024 bit long modulus
..++++++
..++++++
e is 65537 (0x10001)
# openssl req -new -key tscherf.key -out tscherf.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:DE
State or Province Name (full name) [Berkshire]:NRW
Locality Name (eg, city) [Newbury]:Dinslaken
Organization Name (eg, company) [My Company Ltd]:RedHat
Organizational Unit Name (eg, section) []:GSS
Common Name (eg, your name or your server's hostname) []:Thorsten Scherf
Email Address []:tscherf@redhat.com