Drahtlose Netzwerke sind überall: Zu Hause, im Café und in der Firma. Im Gegensatz zu Kabelnetzen verliert der Admin bei WLANs allerdings schnell die ... (mehr)

Absicherung des Servers

Der Server ist nun einsatzbereit, allerdings noch vollkommen ungesichert, denn er nimmt unverschlüsselte Anfragen auf Port 389 entgegen. Wenn der Manager sich von einer Workstation mit dem Server verbindet, wird das Passwort im Klartext übertragen. Um den Server vor unberechtigtem Zugriff zu schützen und das Mitschneiden des Passworts im Netz zu verhindern, sollte schnellstmöglich die Verschlüsselung konfiguriert werden. Hierbei bieten sich grundsätzlich zwei Wege an. Das erste Lösungsszenario verwendet ein selbstsigniertes Zertifikat, das mit den mitgelieferten Skripten im OpenLDAP-Paket erzeugt wird. Die Clients vertrauen später dem Server-Zertifikat. Wer schon eine Zertifizierungsstelle betreibt, kann auch einen anderen Weg einschlagen, dazu gleich mehr.

Die einfache Option ist, die mitgelieferten Skripte zu verwenden, die Sie als Root-Benutzer ausführen müssen. Das erste Skript baut eine Zertifikatsdatenbank in dem Verzeichnis »/etc/openldap/certs« auf.

$ sudo /usr/libexec/openldap/create-certdb.sh
Creating certificate database in '/etc/openldap/certs'.

Das zweite Skript erzeugt das erforderliche Zertifikat und importiert es in den soeben erzeugten Zertifikats-Store.

$ sudo /usr/libexec/openldap/generate-server-cert.sh -d /etc/openldap/certs -hldap.acme-services.org

Der OpenLDAP-Server ist in der Standardkonfiguration so eingestellt, dass er dieses Zertifikat verwendet. Das Zertifikat wird mit dem Namen »OpenLDAP Server« in der Zertifikatsdatenbank gespeichert. Bei NSS-basierten Zertfikaten wird zwischen dem Common Name, der üblicherweise dem Hostnamen des Servers entspricht, und dem lesbaren Namen unterschieden. Beide Namen können voneinander abweichen. Daher wird in dem obigen Kommando der Hostname des Servers mit der Kommandzeilenoption »-h ldap.acme-services.org« angegeben. Hier tritt eine Besonderheit der LDAP-Konfiguration zu Tage: Wenn der OpenLDAP-Server sowohl mit der Methode »StartTLS« als auch mit dem traditionellen SSL angesprochen werden soll, muss der Common Name (»-h« ) dem Hostnamen des Servers entsprechen.

Nachdem dieser Teil der Konfiguration abgeschlossen ist, müssen Sie lediglich die Datei »/etc/sysconfig/ldap« um die Option »ldaps« erweitern. Die Zeile »SLAPD_LDAPS« , die in der Grundkonfiguration auf »no« steht, ändern Sie auf »yes« . Nach einem Neustart versteht es der OpenLDAP-Server, SSL-Verbindungen (SSL und StartTLS) entgegenzunehmen:

$ sudo service slapd restart

Nun können Sie mit »openssl« die Verbindung überprüfen. Jetzt vertraut »openssl« diesem Zertifikat noch nicht und weist es als self-signed aus. Es ist daher erforderlich, das Zertifikat aus der Zertifikatsdatenbank in das systemweite Zertifikatsverzeichnis zu exportieren und mit dem erforderlichen Zertifikats-Hash zu verlinken:

$ sudo certutil -L -d /etc/openldap/certs-n "OpenLDAP Server"-a > /etc/pki/tls/certs/ldap.acme-services.org.crt
$ sudo ln -sf /etc/pki/tls/certs/ldap.acme-services.org.crt $(openssl x509 -in ldap.acme-services.org.crt -noout -hash).0

Nach diesen beiden Schritten können Sie das Zertifikat des Server mit dem »openssl« -Kommando überprüfen. Es stellt für diesen Zweck den Befehl »s_client« zur Verfügung:

$ openssl s_client -connect ldap.acme-services.org:636

Die Ausgabe der Zertifikate erfolgt dabei auf der Konsole. Entscheidend ist hierbei die letzte Zeile, die nach korrekter Konfiguration »0 (ok)« lauten sollte. Das Kommando wartet nun auf Eingaben. Da es jedoch nur das Zertifikat testen sollte, können Sie es mit [Strg]+[C] abbrechen.

Der zweite Weg beschreibt die Verwendung eigener Zertifikate, die nicht in der Zertifikatsdatenbank des OpenLDAP liegen sollen. Oft ist es sogar durchaus sinnvoll, Zertifikate nicht dort zu speichern, beispielsweise wenn weitere Dienste diese Zertifikate nutzen sollen. CentOS speichert Zertifikate in dem Verzeichnis »/etc/pki/tls/certs« und die Keys in »/etc/pki/tls/private« . Es ist darauf zu achten, dass die Gruppe, die Zugriff auf private Keys hat, den OpenLDAP-Server einschließt. Der OpenLDAP-Server läuft als Benutzer »ldap« mit der Gruppe »ldap« . Es bietet sich daher an, den Besitzer »root« und die Gruppe »ldap« dem privaten Keyfile zuzuweisen. Die Rechte sollten auf 640 gesetzt sein.

Leider kennt der OpenLDAP-Server in der Standardkonfiguration diesen Key nicht, den man deshalb gesondert konfigurieren muss. Listing 2 zeigt eine Beispielkonfiguration. Mit dem Kommando »ldapmodify« fügen Sie diese Datei, ähnlich wie beim Einlesen der initialen Konfiguration, dem LDAP-Server hinzu. Anschließend ist wie beim ersten Weg die Variable »SLAPD_LDAPS« in der Datei »/etc/sysconfig/ldap« auf »yes« zu setzen und der Server erneut zu starten. Achten Sie darauf, dass der private Schlüssel nicht mit einem Passwort geschützt ist.

Listing 2

ssl.ldif

 

Damit der Server jetzt schon die neue SSL-Verbindungen nutzt, ist es hilfreich, die Konfigurationsdatei der LDAP-Clients »/etc/openldap/ldap.conf« anzupassen (siehe Listing 3). Bei der Anpassung der Konfigurationsdatei ist der Weg zur Einrichtung der SSL-Verschlüsselung zu beachten. Insbesondere den Parameter »TLS_CACERTDIR« müssen Sie gegebenenfalls auf die systemweite Zertifikatsdatenbank anpassen.

Listing 3

/etc/openldap/ldap.conf

 

Damit ist die Konfiguration des Servers abgeschlossen und die Einrichtung der Benutzerdatenbank kann beginnen.

Aufbau des Verzeichnisses

In diesem Abschnitt soll der Informationsbaum für die Benutzerdaten erstellt werden. Der Toplevel dieses Baums wurde bereits festgelegt und besteht aus den beiden Domain-Components (DC) »dc=acme-services« und »dc=org« . Alle neuen Strukturen werden unter diesem Punkt aufgehängt. Der Baum soll wie in Abbildung 1 aussehen.

Abbildung 1: Der komplette Informationsbaum des LDAP-Verzeichnisses.

Jetzt geht es darum, neue LDAP-Objekte zu generieren und ihnen die erforderlichen Attribute zuzuweisen. Objekte sind dabei eindeutig zu identifizierende Knotenpunkte, die als Attribut spezielle Objektklassen besitzen. Die Objektklassen können zum Beispiel »organizationalUnit« , »domain« , »inetOrgPerson« oder »posixAccount« sein.

Welche Objektklassen zur Verfügung stehen, hängt von den Schemata ab, die der LDAP-Server konfiguriert hat. In Abbildung 2 ist der Zusammenhang grafisch dargestellt.

Abbildung 2: Aufbau von LDAP-Schemata und Objektklassen.
comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019