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.
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.
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.
Listing 1: Mit openssl eine Zertifikatsanfrage erzeugen
# 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