Nachdem Sie den LDAP-Server installiert und die ersten Objekte eingespielt haben, ist es jetzt sinnvoll, dass Sie sich um die Verschlüsselung der Kommunikation zum LDAP-Server kümmern. Wenn Sie mit dem Kommando ldapsearch (oder einem der anderen ldap-Kommandos) auf den LDAP-Server zugreifen, ist die Kommunikation immer unverschlüsselt. Das heißt auch, dass Passwörter unverschlüsselt übertragen werden. Es gibt jetzt zwei Möglichkeiten, die Kommunikation zum LDAP-Server zu verschlüsseln. Bei der ersten wird das LDAPS-Protokoll verwendet; dafür wird ein extra Port auf dem LDAP-Server mit der Portnummer 636 freigeschaltet.
Die andere Methode ist starttls, hierbei wird TLS zusammen mit dem Protokoll LDAP verwendet. Dabei wird kein zusätzlicher Port benötigt, die Kommunikation findet weiterhin über den Port 389 statt. Eine unverschlüsselte Kommunikation wäre aber auch noch möglich, da das Protokoll LDAP das auch mit eingerichtetem startls erlaubt. Wenn Sie auf TLS über Port 389 setzen wollen, kann es sinnvoll sein, sämtliche Versuche eines Clients, unverschlüsselt zu kommunizieren, über ACLs zu unterbinden. Verwendenden Sie ausschließlich LDAPS, kann eine Verbindung nur verschlüsselt aufgebaut werden.
Bevor Sie sich jetzt für einen der beiden Wege entscheiden, prüfen Sie, ob Sie eventuell Anwendungen nutzen, die nur eine der beiden Methoden unterstützt.
Wenn Sie testen wollen, welche Protokolle von Ihrem LDAP-Server unterstützt werden, sehen Sie das am einfachsten, wenn Sie sich den Prozess des LDAP-Servers anzeigen lassen. In Listing 4.1 sehen Sie die entsprechende Ausgabe auf einem Debian-System:
Listing 4.1 Auflisten des slapd-Prozesses
root@provider01:~# ps ax | grep slapd 380 ? Ssl 0:00 /opt/symas/lib/slapd -d 0 -h ldap:/// \\ ldapi:/// ldaps:/// -u openldap -g openldap \ -F /opt/symas/etc/openldap/slapd.d
Wie Sie hier sehen, wird hier sowohl das Protokoll LDAP als auch das Protokoll LDAPS und der lokale Socket LDAPI für die Verbindung zum LDAP-Server angezeigt. Der Grund, dass hier schon beide Protokolle angezeigt werden, ist der, dass wir bei der Grundkonfiguration beide Protokolle angegeben haben. Wollen Sie die Einstellung ändern, können Sie die Änderung in der Datei /etc/default/symas-openldap durchführen. Passen Sie dafür die Variable SLAPD_URLS entsprechend an. Starten Sie anschließend den LDAP-Server neu, und eine neuerliche Auflistung des Prozesses zeigt Ihnen die geänderte Liste der verwendeten Protokolle.
Weil die Verschlüsselung einfach nachvollziehbar und einfach zu testen sein soll, werden wir hier nur auf self-signed certificates eingehen. Auf den verschieden Distributionen ist das Erstellen der Zertifikate immer etwas anders, aber im Großen und Ganzen gleichen sich die Vorgänge. Nachdem Sie die Zertifikate erstellt haben, ist der Vorgang für die Einbindung der Zertifikate in die OpenLDAP-Konfiguration wieder identisch.
| 4.1 | Erstellen der Zertifikate am Beispiel von Debian |
Im ersten Schritt erzeugen Sie die Zertifikate für den LDAP-Server. Dazu wird das Skript CA.pl verwendet, das sich im Verzeichnis /usr/lib/ssl/misc befindet. Damit Sie das Skript auch von jedem Verzeichnis ohne Angabe des Pfads aufrufen können, legen Sie sich einen Link nach /usr/sbin.
Wenn Sie Redhat-basierte Distributionen nutzen, finden Sie das Skript unter /etc/tls/misc/CA.
Bevor Sie allerdings die ersten Zertifikate anlegen können, passen Sie die Konfigurationsdatei /etc/ssl/openssl.cnf für ssl an. Unter Redhat finden Sie die Datei im Verzeichnis /etc/pki/tls. Wenn Sie später abgelaufene Zertifikate verlängern wollen, entfernen Sie auf jeden Fall die Raute vor der Zeile # unique_subject = no. Um sich das Leben etwas leichter zumachen, können Sie in der Datei Default-Werte für einige Parameter eintragen. Sehen Sie dazu das Listing 4.2:
Listing 4.2 Anpassung an der Datei openssl.cnf
[ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = DE countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = SH localityName = Locality Name (eg, city) localityName_default = Firma 0.organizationName = Organization Name (eg, company) 0.organizationName_default = an-st
So brauchen Sie bei der Erstellung der Zertifikate diese Parameter nicht immer wieder eingeben. Jetzt kann es losgehen: Im ersten Schritt erstellen Sie sich eine eigene Certification Authority (CA) , mit der Sie anschließend die eigenen Zertifikate signieren können. Achten Sie bei Debian darauf, dass die Zertifikate, die Sie mit dem Skript CA.pl erstellen, immer im aktuellen Verzeichnis erzeugt werden. Bei Redhat finden Sie die Zertifikate immer im Verzeichnis /etc/pki.
Hinweis: Wir werden hier im Buch ein Verzeichnis /etc/ssl/zertifikate anlegen und alle Zertifikate dort ablegen.
Jetzt können Sie die demoCA erzeugen, mit der später alle Zertifikate signiert werden sollen. Die einzelnen Schritte sehen Sie in Listing 4.3:
Listing 4.3 Anlegen der demoCA
root@provider01:/etc/ssl/zertifikate# CA.pl -newca CA certificate filename (or enter to create) Making CA certificate ... ==== openssl req -new -keyout ./demoCA/private/cakey.pem -out ./demoCA/careq.pem Generating a RSA private key ..............+++++ ..................................................................+++++ writing new private key to ’./demoCA/private/cakey.pem’ Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- 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) [DE]: State or Province Name (full name) [SH]: Locality Name (eg, city) [Firma]: Organization Name (eg, company) [an-st]: Organizational Unit Name (eg, section) []:CA Common Name (e.g. server FQDN or YOUR name) []:CA Email Address []: Please enter the following ’extra’ attributes to be sent with your certificate request A challenge password []: An optional company name []: ==> 0 ==== ==== openssl ca -create_serial -out ./demoCA/cacert.pem -days 1095 -batch \ -keyfile ./demoCA/private/cakey.pem -selfsign -extensions \ v3_ca -infiles ./demoCA/careq.pem Using configuration from /usr/lib/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 08:a3:55:d6:7b:56:4b:15:05:8f:db:97:aa:48:e6:a2:df:75:8a:33 Validity Not Before: Jan 29 15:19:45 2023 GMT Not After : Jan 28 15:19:45 2026 GMT Subject: countryName = DE stateOrProvinceName = SH organizationName = an-st organizationalUnitName = CA commonName = CA X509v3 extensions: X509v3 Subject Key Identifier: E9:4D:1C:A4:6A:2B:C9:44:5A:72:52:18:7A:BA:21:78:4F:36:4F:BA X509v3 Authority Key Identifier: keyid:E9:4D:1C:A4:6A:2B:C9:44:5A:72:52:18:7A:BA:21:78:4F:36\ :4F:BA X509v3 Basic Constraints: critical CA:TRUE Certificate is to be certified until Jan 28 15:19:45 2026 GMT (1095 days) Write out database with 1 new entries Data Base Updated ==> 0 ==== CA certificate is in ./demoCA/cacert.pem
Alle benötigten Dateien für die CA befinden sich im Verzeichnis demoCA.
Wichtig: Sichern Sie das Verzeichnis und das vergebene Passwort an einer sicheren Stelle. Sollten Sie die demoCA verlieren oder das Passwort vergessen, müssen Sie eine neue demoCA erstellen und eventuell alle bis zu dem Zeitpunkt erstellten Zertifikate erneuern.
Mit der demoCA können Sie jetzt alle weiteren Zertifikate signieren. Jetzt erstellen Sie den Request für das LDAP-Server-Zertifikat. Dafür verwenden Sie wieder das Kommando CA.pl.
Wichtig: Bei der Frage nach dem Common Name ist es wichtig, dass Sie auf jeden Fall den FQDN des LDAP-Servers angeben. Ein Client wird bei einer Anfrage immer den FQDN prüfen, und nur, wenn der FQDN mit dem angefragten Servernamen übereinstimmt, wird das Zertifikat als gültig akzeptiert. Wenn Sie anstelle des Servernamens im FQDN einen * setzen, z.B *.example.net, erstellen Sie Wildcard-Zertifikate, die dann für alle Server gültig sind. Das sollten Sie aber ausschließlich in Testumgebungen nutzen, in Produktivumgebungen sollten Sie immer für jeden Server ein eigenes Zertifikat erzeugen.
In Listing 4.4 sehen Sie die Erstellung des Requests:
Listing 4.4 Erzeugung des Requests für den LDAP-Server
root@provider01:/etc/ssl/zertifikate# CA.pl -newreq Use of uninitialized value $1 in concatenation (.) or string at \ /usr/local/sbin/CA.pl line 133. ==== openssl req -new -keyout newkey.pem -out newreq.pem -days 365 Ignoring -days; not generating a certificate Generating a RSA private key ....+++++ .........+++++ writing new private key to ’newkey.pem’ Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- 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) [DE]: State or Province Name (full name) [SH]: Locality Name (eg, city) [Firma]: Organization Name (eg, company) [an-st]: Organizational Unit Name (eg, section) []:ldap Common Name (e.g. server FQDN or YOUR name) []:provider01.example.net Email Address []: Please enter the following ’extra’ attributes to be sent with your certificate request A challenge password []: An optional company name []: ==> 0 ==== Request is in newreq.pem, private key is in newkey.pem
Das hier vergebene Passwort benötigen Sie nur noch einmal, denn nachdem der Request durch die CA signiert wurde, muss das Passwort entfernt werden. Würden Sie das Passwort im Zertifikatsschlüssel belassen, wäre es notwendig, dass Sie bei jedem Neustart des Dienstes das Passwort eingeben. Es nutzt auch nichts, einfach kein Passwort anzugeben und nur RETURN zu drücken, dann wäre RETURN das Passwort.
In Listing 4.5 sehen Sie den nächsten Schritt, das Signieren des Zertifikats:
Listing 4.5 Signieren des Zertifikats
root@provider01:/etc/ssl/zertifikate# CA.pl -sign ==== openssl ca -policy policy_anything -out newcert.pem -infiles newreq.pem Using configuration from /usr/lib/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 08:a3:55:d6:7b:56:4b:15:05:8f:db:97:aa:48:e6:a2:df:75:8a:34 Validity Not Before: Jan 29 15:28:12 2023 GMT Not After : Jan 29 15:28:12 2024 GMT Subject: countryName = DE stateOrProvinceName = SH localityName = Firma organizationName = an-st organizationalUnitName = ldap commonName = provider01.example.net X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 24:B6:23:1B:3E:38:1C:04:C4:B5:61:CB:54:3B:57:B9:22:21:F1:A2 X509v3 Authority Key Identifier: keyid:E9:4D:1C:A4:6A:2B:C9:44:5A:72:52:18:7A:BA:21:78:4F:36\ :4F:BA Certificate is to be certified until Jan 29 15:28:12 2024 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated ==> 0 ==== Signed certificate is in newcert.pem
Prüfen Sie noch einmal alle Werte des Zertifikats, nachdem Sie es signiert haben, vor allen Dingen den commonName des LDAP-Servers. Nach dem Signieren des Zertifikats entfernen Sie das Passwort aus dem Schlüssel und verwenden Sie dazu das Kommando aus Listing 4.6:
Listing 4.6 Entfernen des Passworts aus dem Schlüssel
root@provider01:/etc/ssl/zertifikate# openssl rsa -in newkey.pem \ -out provider01-key.pem Enter pass phrase for newkey.pem: writing RSA key
An der Stelle benötigen Sie jetzt das Passwort, das Sie bei der Erstellung des Requests angegeben haben. Damit Sie das Zertifikat für den Server auch Ihrem LDAP-Server zuordnen können, benennen Sie die Datei newcert.pem um, sodass sie vom Namen zum LDAP-Key passt. Das Umbenennen ist auch wichtig, denn wenn Sie ein neues Zertifikat für einen anderen Server erstellen, heißt die Datei wieder newcert.pem und würde damit Ihr LDAP-Zertifikat überschreiben.
Wichtig: Prüfen Sie die Rechte an allen Zertifikatsdateien. Wichtig ist, dass die Gruppe openldap das Leserecht an allen Dateien besitzt.
An dieser Stelle wollen wir schon etwas in die Zukunft schauen: Wir wollen später eine Multiprovider-Umgebung einrichten und auch die Konfiguration 1:1 auf alle Provider replizieren. Dann ist es wichtig, dass die Zertifikatsnamen und die Pfade zu den Zertifikaten identisch sind. Aus diesem Grund kopieren Sie jetzt das gerade erstellte Zertifikat, den dazugehörigen Schlüssel und das root-Zertifikat der CA in das Verzeichnis /opt/symas/etc/openldap. Beim Kopieren geben Sie den Dateien gleich neue Namen. In Listing 4.7 sehen Sie alle Kopiervorgänge:
Listing 4.7 Kopieren aller Zertifikatsdateien
root@provider01:/etc/ssl/zertifikate# cp provider01-cert.pem \ /opt/symas/etc/openldap/example-net-cert.pem root@provider01:/etc/ssl/zertifikate# cp provider01-key.pem \ /opt/symas/etc/openldap/example-net-key.pem root@provider01:/etc/ssl/zertifikate# cp demoCA/cacert.pem \ /opt/symas/etc/openldap/ root@provider01:/etc/ssl/zertifikate# chgrp openldap \ /opt/symas/etc/openldap/*.pem root@provider01:/etc/ssl/zertifikate# chmod g+r \ /opt/symas/etc/openldap/*.pem
Einbinden der TLS-Zertifikate
Um die Zertifikate in den Server einbinden zu können, benötigen Sie eine LDIF-Datei. In Listing 4.8 sehen Sie den Inhalt der Datei. Die TLS-Einstellungen werden immer im globalen Teil der Konfiguration abgelegt, da die Zertifikate immer für den Server gelten und nicht für die konfigurierten Datenbanken. Aus diesem Grund brauchen Sie hier auch nicht auf eine Nummer der Datenbank zu achten:
Listing 4.8 LDIF-Datei für die TLS-Konfiguration
dn: cn=config changetype: modify add: olcTLSCertificateFile olcTLSCertificateFile: /opt/symas/etc/openldap/example-net-cert.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /opt/symas/etc/openldap/example-net-key.pem - add: olcTLSCACertificateFile olcTLSCACertificateFile: /opt/symas/etc/openldap/cacert.pem
Anschließend spielen Sie die Änderung so wie in Listing 4.9 in Ihre Konfiguration ein:
Listing 4.9 TLS in die dynamische Konfiguration eintragen
root@ldapserver:~# ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f tls-conf.ldif modifying entry "cn=config"
Sollten Sie beim Versuch, die Änderungen in der Konfiguration einzutragen, die Fehlermeldung aus Listing 4.10 bekommen, prüfen Sie die Zugriffsrechte auf alle Zertifikatsdateien. Prüfen Sie auch, ob die Gruppe, unter der Ihr LDAP-Server läuft, Zugriff auf die Datei cacert.pem besitzt. Prüfen Sie ebenfalls die Pfade.
Listing 4.10 Fehler bei falschen Berechtigungen
modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80)
Um auch die ldap-Kommandos nur noch verschlüsselt auf den LDAP-Server zugreifen zu lassen, ändern Sie jetzt noch die Datei /opt/symas/etc/openldap/ldap.conf so wie in Listing 4.11:
Listing 4.11 Erweiterung der Datei ldap.conf
BASE dc=example,dc=net URI ldaps://provider01.example.net TLS_REQCERT demand TLS_CACERT /opt/symas/etc/openldap/cacert.pem
Wir werden, im Gegensatz zur ersten Auflage des Buches, ausschließlich mit LDAPS als Protokoll arbeiten und nicht mit starttls. Den Grund dafür beschreiben wir am Ende dieses Kapitels.
Testen Sie die TLS-Verschlüsselung mit dem Kommando ldapsearch. Haben Sie LD-APS als Protokoll aktiviert, benötigen Sie keinen weiteren Parameter für das Kommando ldapsearch, denn aufgrund der Einträge in der ldap.conf wird automatisch ldaps genutzt. Nur wenn Sie LDAP zusammen mit starttls nutzen wollen, benötigen Sie den Parameter -Z. Bei dem Parameter -Z beachten Sie Folgendes: Verwenden Sie nur ein -Z, wird ldapsearch den LDAP-Server anfragen, ob TLS möglich ist. Wenn ja, dann wird TLS verwendet und die Verbindung verschlüsselt. Kann der LDAP-Server kein TLS, wird die Verbindung unverschlüsselt aufgebaut. Nur wenn Sie -ZZ nutzen, können Sie sicher sein, dass die Verbindung auch verschlüsselt stattfindet. Denn dann verlangt ldapsearch TLS.
Hinweis: Wenn Sie in der Datei ldap.conf das Protokoll LDAPS bei der URI eingetragen haben und Sie dann die Parameter -ZZ angeben, erhalten Sie eine Fehlermeldung, die darauf hinweist, dass TLS bereits aktiv ist.
Wenn Sie überprüfen wollen, ob eine Verbindung auch wirklich verschlüsselt aufgebaut und durchgeführt wird, starten Sie auf einer anderen Konsole das Kommando journalctl -f -u symas-openldap-server.service, starten dann auf der ersten Konsole ein ldapsearch. Im Log sehen Sie dann die Einträge aus Listing 4.12:
Listing 4.12 Logging eines TLS-Zugriffs
root@provider01:~# journalctl -f -u symas-openldap-server.service ...ACCEPT from IP=192.168.56.61:37750 (IP=0.0.0.0:636) ...TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 \ tls_cipher=TLS_AES_256_GCM_SHA384 ...BIND dn="" method=128 ...RESULT tag=97 err=0 qtime=0.000025 etime=0.000436 text= ...SRCH base="dc=example,dc=net" scope=2 deref=0 filter="(objectClass=*)" ...SEARCH RESULT tag=101 err=0 qtime=0.000027 etime=0.001070 \ nentries=27 text= ...conn=1002 op=2 UNBIND ...conn=1002 fd=15 closed
Sie sehen hier, dass direkt nach dem Verbindungsaufbau sofort TLS gestartet wird und erst dann die eigentliche Anmeldung folgt. Noch eines ist hier zu erkennen: Beim BIND dn steht lediglich ””. Das zeigt, dass es sich um eine anonyme Verbindung handelt. Wenn Sie beim Verbindungsaufbau eine DN angeben, würde an dieser Stelle der DN angezeigt. Der Eintrag nentries=27 zeigt, dass 27 Objekte gefunden wurden. Bei einem anonymen Zugriff sollte hier immer eine 0 stehen, denn anonym sollte Ihr LDAP-Server niemals Antworten geben. Aber dazu kommen wir noch, wenn wir uns um die ACLs kümmern.
| 4.2 | TLS vs. LDAPS |
Aber warum gibt es denn zwei verschiedene Methoden, um eine sichere Verbindung zum LDAP-Server herzustellen? Wie Sie in diesem Kapitel gesehen haben, ist das Ergebnis identisch, egal ob Sie LDAP über TLS verschlüsseln oder gleich LDAPS als Protokoll verwenden. Wo liegen die Unterschiede? Wenn Sie LDAPS einsetzen, benötigen Sie einen zusätzlichen Port (636) auf Ihrem Server. Da es sich bei dem Protokoll um ein eigenständiges Protokoll der OSI-Schichten 5–7 handelt, muss jeder Client, der auf den LDAP-Server zugreifen will, das Protokoll unterstützen. Bei TLS handelt es sich, wie es das „T“ in der Abkürzung schon sagt, um ein Protokoll des Transport-Layers, und es ist somit für die Anwendung transparent.
Auf der Mailingliste zu openldap wurde eine Zeit lang darüber diskutiert, welcher Weg der Verschlüsselung der sicherere ist. Dabei ist LDAPS ganz klar als Gewinner hervorgegangen (obwohl in einem FAQ auf der openldap-Webseite vor Jahren starttls empfohlen wurde). Bei startls besteht die geringe Möglichkeit, dass ein Man-in-the-middle einen Angriff starten und die Verschlüsselung dadurch übergehen oder aufbrechen kann. Weiterhin wird bei dem Verbindungsaufbau über LDAPS nicht mehr das alte SSL-Protokoll genutzt, sondern genau wie bei starttls TLS in der Version 1.3.
Egal welchen Weg Sie gehen: Hauptsache, Sie verschlüsseln die Verbindungen zu Ihrem LDAP-Server und erlauben keine unverschlüsselten Verbindungen
Selbstverständlich können Sie beide Wege nutzen, wenn Sie zum Beispiel alles über LDAPS absichern wollen, aber Sie nutzen eine Software, die nur starttls unterstützt. Unterstützen alle Ihre Anwendungen LDAPS, können Sie das Protokoll LDAP auf Ihrem LDAP-Server auch ganz deaktivieren. Dazu entfernen Sie das Protokoll aus der Startoption in der Datei /etc/default/symas-openldap.