Ubuntu 12.04 „Precise Pangolin“
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
OpenLDAP
stellt das Anwendungsprotokoll LDAP als freie Software für Linux zur Verfügung. Mit diesem Dienst ist es beispielsweise möglich, eine zentrale Benutzerverwaltung aufzubauen. Zudem kann OpenLDAP als Adressbuch eingesetzt werden. Der LDAP-Verzeichnisdienst ist eine hierarchische Datenbank, in der strukturierte Objekte abgelegt werden. Jedes Objekt wird mit einer Menge von Attributen ausgestattet, die in einer Objektklasse festgelegt sind. Ein Objekt kann dazu mehreren Objektklassen angehören, um unterschiedliche Eigenschaften auszudrücken.
Vor einer Installationen und/oder Updates wird die Lektüre des Abschnitts Tipps und Tricks empfohlen!
LDAP ist ein recht komplexes Thema. Es ist empfehlenswert, vor der Nutzung weitere Literatur zu Rate zu ziehen, um ein besseres Verständnis für die Funktionsweise und die Möglichkeiten zu bekommen. Bevor man OpenLDAP auf einem produktiven System installiert, wird empfohlen, zuerst auf einem Testsystem zu installieren und sich ein bisschen einzuarbeiten, da es teilweise in der Bedienung nicht besonders intuitiv ist.
Die Befehle in diesem Artikel müssen im Allgemeinen als root
ausgeführt werden. Es bietet sich deshalb an, mit
sudo -i
in eine root-Shell zu wechseln.
Folgende Pakete sind für Open LDAP [1] zu installieren. Beide befinden sich in den offiziellen Paketquellen.
slapd
ldap-utils
mit apturl
Paketliste zum Kopieren:
sudo apt-get install slapd ldap-utils
sudo aptitude install slapd ldap-utils
Als nächstes werden einige, der von Ubuntu im LDIF-Format mitgelieferte Schemata, eingefügt. Die Schemata
core
cosine
inetorgperson
und
nis
sind bereits im Backend vorhanden. Es können u. a. noch folgende weitere Schemata hinzugefügt werden.
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/misc.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/openldap.ldif
Es sind zwar beinahe alle Schemata schon als fertige .ldif-Dateien vorhanden, allerdings gibt es mit den Schemata ldapns
und samba
kleine Probleme.
Sollte OpenLDAP nicht zusammen mit Samba betrieben werden, ist das Schema samba.schema
nicht nötig. In diesem Fall sind im folgenden alle Zeilen, welche samba als Wortlaut enthalten, wegzulassen.
Weitere Schemata (wie z. B. samba.schema
), die nicht im LDIF-Format vorliegen, müssen zunächst konvertiert werden.
Im Verzeichnis /etc/ldap/schema ist die Datei schema_convert.conf mit den einzufügenden Schemata zu erstellen. Das folgende Beispiel fügt die gängigsten Schemata hinzu.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | include /etc/ldap/schema/core.schema include /etc/ldap/schema/collective.schema include /etc/ldap/schema/corba.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/java.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/ldapns.schema include /etc/ldap/schema/pmi.schema include /etc/ldap/schema/samba.schema |
Wer weiß, welche Schemata auf welchen aufbauen, kann die Liste verkürzen und sich so etwas Arbeit sparen. Es ist aber auch unbedenklich, die ganze Liste so zu installieren.
Auch die schon in die cn=config
-Datenbank eingefügten Schemata müssen in schema_convert.conf aufgeführt werden, da die anderen Schemata teilweise auf sie aufbauen!
Das Schema samba.schema
wird wie folgt installiert[1].
samba-doc
mit apturl
Paketliste zum Kopieren:
sudo apt-get install samba-doc
sudo aptitude install samba-doc
gunzip /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz cp -v /usr/share/doc/samba-doc/examples/LDAP/samba.schema /etc/ldap/schema
Als nächstes ist ein temporäres Verzeichnis für die .ldif-Dateien zu erstellen.
mkdir /tmp/ldif_output
Die Schemata sind ins LDIF-Format mit Hilfe von slapcat zu konvertieren und ins Verzeichnis /etc/ldap/schema zu kopieren.
Die Zahlen zu den Schemata können durchaus variieren. Falls Fehlermeldungen auftreten, sind diese Schemata einzeln (mit den richtigen Nummern) zu kopieren!
cd /etc/ldap/schema slapcat -f schema_convert.conf -F /tmp/ldif_output -n0 cd /tmp/ldif_output/cn\=config/cn\=schema/ cp cn={11}ppolicy.ldif cn={12}ldapns.ldif cn={13}samba.ldif cn={2}corba.ldif cn={4}duaconf.ldif cn={5}dyngroup.ldif cn={7}java.ldif /etc/ldap/schema
Das lästige cn={x}
in den neuen .ldif-Dateien kann durch Umbenennen aus dem Dateinamen entfernt werden.
Nun können die neuen .ldif-Dateien in einem Editor geöffnet werden und die Attribute dn
(in der 1. Zeile) und cn
(in der 3. Zeile) angepasst werden. Dies wird am Beispiel des Samba-Schemas verdeutlicht.
1 2 3 | dn: cn=samba,cn=schema,cn=config ... cn: samba |
Vor dem Schließen der jeweiligen Datei kommt noch der nächste Punkt.
Die Zeichenfolgen hinter den :
kann variieren.
1 2 3 4 5 6 7 | structuralObjectClass: olcSchemaConfig entryUUID: bc124984-712d-102e-9274-5bec14760b98 creatorsName: cn=config createTimestamp: 20091129122324Z entryCSN: 20091129122324.626040Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20091129122324Z |
Abschließend werden die Schemata dem config-Backend hinzugefügt (Vorsicht: Hier wurden die cn={x}
schon entfernt).
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ppolicy.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ldapns.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/samba.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/corba.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/duaconf.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/dyngroup.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/java.ldif
Bis vor einiger Zeit wurde das LDAP-Backend noch über die Datei /etc/ldap/slapd.conf konfiguriert. Inzwischen gibt es für die Konfiguration eine eigene, kleine Datenbank. Es ist möglich, eine Konfiguration in einer slapd.conf in die cn=config
-Datenbank zu importieren. Empfohlen wird der hier gezeigte Weg.
In der nachfolgenden Konfiguration werden mehrere Platzhalter für Zeichenfolgen verwendet, die auf die eigenen Bedürfnisse anzupassen sind.
Platzhalter | |
Platzhalter | Beschreibung |
dc=meinedomain,dc=local | Das ist der Suffix der LDAP-Datenbank. Meist wird dafür die eigene Domain gewählt. Würde dieses LDAP für ubuntuusers.de aufgesetzt, wäre es zum Beispiel dc=ubuntuusers,dc=de oder auch dc=wiki,dc=ubuntuusers,dc=de . |
1234 | Platzhalter für das Passwort. |
{SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1 | Platzhalter für den Hash, der noch erzeugt werden muss. |
Zunächst ist ein Passwort für die LDAP-Superuser festzulegen. Für diesen Wiki-Artikel werden beispielhaft zwei Superuser im LDAP-Backend angelegt.
cn=admin,cn=config
(Root für die cn=config
-Datenbank, d. h. für das Konfigurationsverzeichnis des LDAP-Servers)
cn=admin,dc=meinedomain,dc=local
(Root für das eigentliche LDAP-Verzeichnis der Domäne meinedomain.local
)
Dafür muss zuerst ein Passwort-Hash generiert werden.
slappasswd
New password: Re-enter new password: {SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1
Dieser Hash wird später noch öfters benötigt.
Die cn=config
-Datenbank wird weitgehend schon bei der Installation aufgesetzt. Es sind dennoch einige Anpassungen ratsam. Dafür wird eine Datei db.ldif erstellt und Folgendes eingefügt.
Es müssen zwei mal die Domain und zwei mal der Hash ersetzt werden!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 | ########################################################### # DEFAULT DATABASE MODIFICATION ########################################################### # Modify directory database dn: olcDatabase={1}hdb,cn=config changeType: modify delete: olcSuffix dn: olcDatabase={1}hdb,cn=config changeType: modify add: olcSuffix olcSuffix: dc=meinedomain,dc=local dn: olcDatabase={1}hdb,cn=config changeType: modify delete: olcRootDN dn: olcDatabase={1}hdb,cn=config changeType: modify add: olcRootDN olcRootDN: cn=admin,dc=meinedomain,dc=local dn: olcDatabase={1}hdb,cn=config changeType: modify delete: olcRootPW dn: olcDatabase={1}hdb,cn=config changeType: modify add: olcRootPW olcRootPW: {SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1 dn: olcDatabase={1}hdb,cn=config changeType: modify delete: olcDbIndex dn: olcDatabase={1}hdb,cn=config changeType: modify add: olcDbIndex olcDbIndex: uid pres,eq dn: olcDatabase={1}hdb,cn=config changeType: modify add: olcDbIndex olcDbIndex: cn,sn,mail pres,eq,approx,sub dn: olcDatabase={1}hdb,cn=config changeType: modify add: olcDbIndex olcDbIndex: objectClass eq ########################################################### # REMOTE CONFIGURATION DEFAULTS ########################################################### # Some defaults need to be added in order to allow remote # access by DN cn=admin,cn=config to the LDAP config # database. Otherwise only local root will # administrative access. dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootDN olcRootDN: cn=admin,cn=config dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootPW olcRootPW: {SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1 |
Diese Konfiguration wird mit folgendem Befehl in slapd eingelesen.
ldapadd -Y EXTERNAL -H ldapi:/// -f db.ldif
Dadurch wird der Administrator für das Konfigurations-Backend erstellt. Benötigt wird dieser immer dann, wenn die Konfiguration geändert werden soll.
Jetzt fehlen noch die Einträge für den LDAP DIT (= "Directory Information Tree", das eigentliche Verzeichnis des LDAP-Servers). Dazu ist eine weitere Datei namens base.ldif zu erstellen und Folgendes einzufügen.
Auch hier müssen zwei Domains und ein Hash angepasst werden. Zusätzlich sind o: meinedomain.local
und dc: meinedomain
anzupassen!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | # Tree root dn: dc=meinedomain,dc=local objectClass: dcObject objectClass: organization o: meinedomain.local dc: meinedomain description: Tree root # LDAP admin dn: cn=admin,dc=meinedomain,dc=local objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin userPassword: {SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1 description: LDAP administrator |
Dadurch wird ein Superuser cn=admin,dc=meinedomain,dc=local
mit dem Passwort 1234
erstellt, der von nun an alle Rechte am LDAP-Verzeichnis für meinedomain.local
hat und über dessen Account nachfolgend das eigentliche LDAP-Verzeichnis initialisiert und befüllt wird.
Die Datei base.ldif wird über den Superuser-Account cn=admin,dc=meinedomain,dc=local
eingelesen (wenn nach einem Passwort gefragt wird, das zuvor definierte Passwort 1234
eingeben).
ldapadd -x -D cn=admin,dc=meinedomain,dc=local -W -f base.ldif
Mit den folgenden Befehlen, die direkt auf dem Rechner mit dem OpenLDAP-Server ausgeführt werden müssen, kann die LDAP-Konfiguration testweise ausgelesen werden.
ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase={1}hdb ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W
Zum Auslesen der eigentlichen Verzeichnisdaten dient folgender Befehl (diesmal als anonymer Benutzer ohne Passworteingabe - daher wird beim Eintrag unter cn=admin,dc=meinedomain,dc=local
das Passwort-Attribut nicht angezeigt):
ldapsearch -xLLL -b dc=meinedomain,dc=local
Die von OpenLDAP bereitgestellten LDAP-Client-Tools wie ldapsearch und ldapmodify versuchen standardmäßig, die Benutzer am LDAP-Verzeichnis-Server über Simple Authentication and Security Layer (SASL) mit DIGEST-MD5-Mechanismus zu authentifizieren. Daneben gibt es noch eine einfache Authentifizierung (mittels Option -x
), die in den vorangegangenen Installations- und Konfigurationskapiteln zur Anwendung kam. Mit ein paar zusätzlichen Schritten kann aber jedem Benutzer der Zugriff auf das LDAP-Verzeichnis mittels SASL-Authentifizierung ermöglicht werden. Dazu müssen die Linux-Benutzeraccounts wie vorangehend beschrieben in das LDAP-Verzeichnis migriert werden. Darüber hinaus müssen einige Attribute im cn=config
-Backend korrekt gesetzt sein.
Die Authentifizierung per SASL ist optional.
Für die Konfiguration mittels cn=config
-Backend muss eine Datei sasl-digestmd5.ldif im Verzeichnis /etc/ldap mit nachfolgendem Inhalt erstellt werden. (Hier müssen wieder einige dc
angepasst werden!)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 | ########################################################### # DEFAULTS MODIFICATION for SASL DIGEST-MD5 ########################################################### # Some of the defaults need to be modified in order to allow # SASL supported access to the LDAP config. # The LDAP administrator will need to tell the slapd server # how to map an authentication request DN to a user's # authentication DN. This is done by adding one or more # olcAuthzRegexp attributes to the cn=config backend. # This attribute takes two arguments: # # olcAuthzRegexp <search pattern> <replacement pattern> # # Please note, that more than one attribute can be specified. # The LDAP server will serve them sequentially. dn: cn=config changetype: modify add: olcAuthzRegexp olcAuthzRegexp: uid=root,cn=[^,]*,cn=auth cn=admin,dc=meinedomain,dc=local dn: cn=config changetype: modify add: olcAuthzRegexp olcAuthzRegexp: uid=([^,]*),cn=[^,]*,cn=auth uid=$1,ou=Users,dc=meinedomain,dc=local # set the correct authentication policy dn: cn=config changetype: modify add: olcAuthzPolicy olcAuthzPolicy: to # User passwords have to stored as cleartext within the # LDAP directory dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcPasswordHash olcPasswordHash: {CLEARTEXT} |
Diese muss dann anschließend in das LDAP-Backend eingefügt werden.
ldapadd -x -D cn=admin,cn=config -W -f /etc/ldap/sasl-digestmd5.ldif
Der Neustart von slapd erfolgt mittels
service slapd restart
Nun müssen noch die Passwörter in Klartext im LDAP-Verzeichnis hinterlegt werden. Dazu muss das Passwort neu gesetzt werden. Dies kann jeder Benutzer (z.B. user1
) selber durchführen
ldappasswd -x -D uid=user1,ou=Users,dc=meinedomain,dc=local -W -s MeinPasswort uid=user1,ou=Users,dc=meinedomain,dc=local
oder der LDAP-Administrator (durch Neuvergabe)
ldappasswd -x -D cn=admin,dc=meinedomain,dc=local -W -s NeuesPasswort uid=user1,ou=Users,dc=meinedomain,dc=local
Nach Eingabe von
user1@MeinComputer:~$ ldapsearch -b dc=meinedomain,dc=local
und dem Passwort sollte jeder Benutzer die im LDAP-Verzeichnis hinterlegten Benutzer und Gruppen mit den dazugehörigen Attributen angezeigt bekommen.
SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: user1 SASL SSF: 128 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=meinedomain,dc=local> with scope subtree # filter: (objectclass=*) # requesting: ALL # # meinedomain.local dn: dc=meinedomain,dc=local objectClass: dcObject objectClass: organization o: meinedomain.local dc: meinedomain description: Tree root # admin, meinedomain.local dn: cn=admin,dc=meinedomain,dc=local objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator ...
Zum Abschluss muss auch noch das Passwort des LDAP-Verzeichnis-Administrators (cn=admin,dc=meinedomain,dc=local
) in Klartext in dem LDAP-Verzeichnis hinterlegt werden. Ganz zu Beginn der Installation des OpenLDAP-Servers wurde ja nur ein Passwort-Hash eingetragen. Der von den LDAP-Client-Tools standardmäßig für die Benutzerauthentifizierung verwendete SASL-DIGEST-MD5-Mechanismus erfordert aber zwingend die Ablage der Passwörter in Klartext im LDAP-Verzeichnis. LDAP-Abfragen durch den Ubuntu-Superuser root wie z.B.
sudo ldapsearch -b ou=Users,dc=meinedomain,dc=local -LLL uid=user1
SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: root SASL SSF: 128 SASL data security layer installed
werden aus Sicherheitsgründen mittels der oben definierten Authentication-Replace-Anweisung authz-regexp uid=admin,cn=[^,]*,cn=auth cn=admin,dc=meinedomain,dc=local
über den LDAP-Admin authentifiziert. Unter Please enter your password:
ist deshalb das Passwort 1234
des LDAP-Admin einzugeben. So kann root
, ohne selbst im LDAP-Verzeichnis abgelegt zu sein, auf dasselbe zugreifen. Die Hinterlegung des Passwortes in Klartext erfolgt über
ldappasswd -x -D cn=admin,dc=meinedomain,dc=local -W -S cn=admin,dc=meinedomain,dc=local
Nach der sicheren Authentifizierung geht es nun an den verschlüsselten Transport der Informationen zwischen LDAP-Server und Client. Dafür wird das Verschlüsselungsprotokoll Transport Layer Security (TLS), auch bekannt unter der früheren Bezeichnung Secure Sockets Layer (SSL), herangezogen. Der in Ubuntu zur Verfügung gestellte OpenLDAP-Server (slapd) und die OpenLDAP-Clients verwenden GnuTLS als TLS-Bibliothek. Das löst zwar Lizenzprobleme, bringt aber einige Komplikationen mit sich, die das Einrichten von Transport Layer Security in OpenLDAP schnell zu einem Alptraum werden lassen können. Es ist deshalb ratsam, durch striktes Befolgen der Anleitung zunächst einen funktionierenden TLS-Layer einzurichten. Anschließend kann dieser dann den eigenen Bedürfnissen entsprechend weiter angepasst werden. Wie SASL ist auch die Verschlüsselung mittels TLS zwingend erforderlich, um einen LDAP v3 kompatiblen LDAP-Verzeichnisdienst zu betreiben.
slapd verzeiht Fehler bei der Konfiguration von TLS nicht. Gewöhnlich lässt sich der Dämon dann erst einmal nicht mehr starten und somit auch nicht mehr konfigurieren. Stattdessen beglückt der Dämon den frustrierten Nutzer auch bei höchster Debug-Stufe mit einer (!) einzigen nichtssagenden Fehlermeldung: TLS init def ctx failed: -1
.
Deshalb ist es ratsam, wie unter Backup der Konfiguration und Datenbank beschrieben, die letzte funktionierende Konfiguration zu sichern!
Wird dieser Rat nicht befolgt, bleibt im Falle eines Fehlers nur noch der Ausweg, durch Eingabe von dpkg-reconfigure slapd
das cn=config
-Backend in den Ausgangszustand zurückzusetzen. Alle bis hier erfolgten Konfigurationsschritte an dem Backend müssen dann wieder neu ausgeführt werden. Es wird daher nochmals dringend empfohlen, die für die Konfiguration verwendeten .ldif-Dateien im Verzeichnis /etc/ldap/ abzulegen. Nur so lässt sich OpenLDAP zügig reparieren. Sollten zwischenzeitlich schon Daten in das eigentliche LDAP-Verzeichnis eingetragen worden sein, ist das kein Problem. Solange ruhig und gezielt die Konfiguration des Backends wiederhergestellt wird, bleiben alle (!) Verzeichnisdaten erhalten!
OpenLDAP benötigt X.509-Zertifikate zur Verschlüsselung der Daten. Es wird zwischen Server- und Client-Zertifikaten unterschieden. LDAP v3-konforme Server müssen auf gültige Zertifikate zurückgreifen können. Für LDAP-Clients ist die Verwendung von eigenen Zertifikaten optional und wird deshalb hier nicht weiter beschrieben. Um das Server-Zertifikat zu generieren, gibt es drei Möglichkeiten:
Selbstsigniertes Zertifikat
Bezug von einer Zertifizierungsstelle (Certification Authority)
Einrichtung und Verwendung einer eigenen Zertifizierungsstelle
Hier ist es sinnvoll, die eher noch nicht so ausgereifte, dafür aber schnell und einfach zu verwendende GnuTLS-Bibliothek einzusetzen, gegen die ja auch OpenLDAP kompiliert wurde.
gnutls-bin (bis Ubuntu 10.04 universe)
mit apturl
Paketliste zum Kopieren:
sudo apt-get install gnutls-bin
sudo aptitude install gnutls-bin
Für TLS werden zwei Zertifikate und ein privater Schlüssel benötigt. Die Erstellung erfolgt am besten in einem eigenen Arbeitsverzeichnis, das hinterher ggf. auch wieder gelöscht werden kann.
mkdir /var/ssl cd /var/ssl
Für die Erstellung des Zertifikats wird eine Konfigurationsdatei (/var/ssl/ca.cfg) benötigt.
1 2 3 | cn = meinedomain ca cert_signing_key |
Mit Hilfe der Konfigurationsdaten wird das CA-Zertifikat erstellt.
sh -c "certtool --generate-privkey > cakey.pem"
certtool --generate-self-signed --load-privkey cakey.pem --template ca.cfg --outfile cacert.pem
sh -c "certtool --generate-privkey > ldap_slapd_key.pem"
Auch für das Server-Zertifikat wird eine Konfigurationsdatei (/var/ssl/slapd.cfg) benötigt.
1 2 3 4 5 | organization = meinedomain cn = ldap.meinedomain.local tls_www_server encryption_key signing_key |
Der common name im Zertifikat muss dabei auf den eindeutigen, vollständigen Namen (FQDN) des LDAP-Servers verweisen, da sonst LDAP-Clients ggf. das Zertifikat nur nach Rückfrage beim Benutzer akzeptieren. Der Befehl
certtool --generate-certificate --load-privkey ldap_slapd_key.pem --load-ca-certificate cacert.pem --load-ca-privkey cakey.pem --template slapd.cfg --outfile ldap_slapd_cert.pem
erstellt das Server-Zertifikat.
Grundsätzlich sollten die für TLS benötigten Zertifikate an jedem beliebigen Ort ablegbar sein. Wenn allerdings AppArmor aktiviert ist (wie es in Ubuntu Standard ist) müssen die Zertifikate für OpenLDAP mit GnuTLS an passender Stelle abgelegt werden. Mögliche Verzeichnisse sind u.a. /etc/ssl/certs/, /usr/local/share/ca-certificates/ (letzteres mit Unterverzeichnissen) und /etc/ssl/private/ für den privaten Schlüssel.
Im Verzeichnis /var/ssl/ befinden sich nun alle benötigten Dateien.
Stammzertifikat cacert.pem
Server-Zertifikat ldap_slapd_cert.pem
privater Schlüssel für Server-Zertifikat ldap_slapd_key.pem
Diese werden nun ins zentrale Verzeichnis /etc/ssl/certs installiert.
install -D -o openldap -g openldap -m 600 /var/ssl/ldap_slapd_key.pem /etc/ssl/private/ldap_slapd_key.pem install -D -o openldap -g openldap -m 600 /var/ssl/ldap_slapd_cert.pem /etc/ssl/certs/ldap_slapd_cert.pem install -D -o openldap -g openldap -m 600 /var/ssl/cacert.pem /etc/ssl/certs/ldap_slapd_cacert.pem
Jetzt muss noch dem LDAP-Serverdämon slpad
mitgeteilt werden, dass er TLS verwenden soll. Dazu wird die Datei /etc/ldap/tls.ldif mit folgendem Inhalt angelegt.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | ########################################################### # CONFIGURATION for Support of TLS ########################################################### # Add TLS supported access to user passwords for LDAP clients # to the LDAP config. dn: cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/ldap_slapd_cacert.pem dn: cn=config changetype: modify add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap_slapd_key.pem #dn: cn=config #changetype: modify #delete: olcTLSCertificateFile dn: cn=config changetype: modify add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap_slapd_cert.pem |
Diese muss dann ins LDAP-Backend eingefügt werden.
ldapadd -x -D cn=admin,cn=config -W -f /etc/ldap/tls.ldif
Von einer Konfiguration des Parameters TLSCipherSuite
, wie in manchen Anleitungen vorgeschlagen, sollte abgesehen werden. GnuTLS sucht sich ohnehin die sicherste Verschlüsselung aus. Wird hingegen ein falscher Wert für die TLSCipherSuite
eingegeben, startet slapd
nicht mehr und muss neu konfiguriert werden.
OpenLDAP unterstützt zwei Verfahren zum Aufbau einer sicheren Kommunikation zwischen LDAP-Server und Client über TLS/SSL.
StartTLS ist eine LDAP-Operation zwischen LDAP-Server und Client, die eine normale LDAP-Verbindung um TLS/SSL-Verschlüsselung erweitert. TLS/SSL wird nach erfolgreichem Abschluss dieser LDAP-Operation initialisiert. Es wird kein zusätzlicher Kommunikationsport benötigt. LDAP-Clients wie der System Security Services Daemon (SSSD) sind so intelligent gebaut, dass sie TLS/SSL nur vorübergehend für die Verschlüsselung der Übertragung sensitiver Daten, wie z.B. Passwörter, einrichten und danch wieder auf die normale LDAP-Verbindung zurückfallen.
LDAPS oder ldaps://
verweisen auf LDAP Secured, d.h. LDAP über TLS/SSL. Für die Kommunikation zwischen LDAP-Server und Client wird dauerhaft eine TLS/SSL-Schicht oberhalb von TCP eingerichtet. Das LDAP-Protokoll verwendet normalerweise Port 389 für die Kommunikation. LDAPS benötigt hingegen einen eigenen Kommunikationsport (üblicherweise 636).
Das Ändern der Variable SLAPD_SERVICES
in /etc/default/slapd ist angeblich nicht mehr notwendig.
Zunächst muss der Debconf-Wrapper für OpenSSL installiert werden, damit die richtigen Benutzer und Gruppen erstellt werden.
ssl-cert
mit apturl
Paketliste zum Kopieren:
sudo apt-get install ssl-cert
sudo aptitude install ssl-cert
Mit folgenden Schritten werden dann die Zertifikate den richtigen Nutzern und Gruppen zugewiesen.
sudo adduser openldap ssl-cert sudo chgrp ssl-cert /etc/ssl/private/ldap_slapd_key.pem sudo chmod g+r /etc/ssl/certs/ldap_slapd_cert.pem sudo chmod o-r /etc/ssl/certs/ldap_slapd_cert.pem
Damit ist die Einrichtung von TLS/SSL abgeschlossen.
Nach einem Neustart des LDAP-Servers sichert das StartTLS-Verfahren die sichere Kommunikation zwischen LDAP-Server und Client.
service slapd restart
Sollte der slapd-Deamon nicht starten, liegt das u.U. daran, dass die Zertifikate nicht den richtigen Nutzern und Gruppen zugeordnet wurden. In diesem Fall kann die neuerliche Durchführung des Schrittes Zertifikatzugriff Abhilfe schaffen.
Zum Testen dienen am einfachsten die sowieso schon installierten OpenLDAP-Clients. Dazu muss deren Konfigurationsdatei /etc/ldap/ldap.conf überprüft und ggf. anpasst werden. Folgende Einträge sind dazu zwingend erforderlich.
1 2 3 4 | uri ldap://ldap.meinedomain.local/ ldap_version 3 ssl start_tls tls_cacert /etc/ssl/certs/ca_certificates.crt |
Dabei ist der FQDN des LDAP-Servers entsprechend anzupassen. Für den Fall, dass der LDAP-Server nur ein selbstsigniertes Zertifikat verwendet, muss der Eintrag tls_cacert
angepasst und noch folgender Parameter in /etc/ldap/ldap.conf eingefügt werden.
1 2 | tls_cacert /etc/ssl/certs/ldap_slapd_cacert.pem TLS_REQCERT allow |
GnuTLS und damit die OpenLDAP-Clients vertrauen nur Server-Zertifikaten, die von Stammzertifizierungstellen mit entsprechendem Stammzertifikat signiert sind. Wurde das Server-Zertifikat von einer nachgeordneten CA signiert, muss die unter Option tls_cacert
genannte Datei alle Zertifikate der Signaturkette bis zur Stammzertifizierungsstelle enthalten. Selbstsignierten Zertifikaten wird grundsätzlich nicht vertraut. Sie und alle anderen nicht vertrauenswürdigen Server-Zertifikate werden aber dennoch verwendet, wenn die TLS_REQUEST-Option den Wert allow
oder never
hat.
Nun kann der Test der TLS/SSL-Verschlüsselung beginnen.
ldapsearch -xLLL -Z -W -D cn=admin,cn=config -b cn=config cn=config
Die Option -Z
fordert die StartTLS-Operation beim OpenLDAP-Client an. Wenn die Ausführung des Befehls erfolgreich ist, d.h. die TLS-Einstellungen des LDAP-Servers angezeigt werden, kann die Initialisierung von TLS/SSL im Detail angesehen werden.
ldapsearch -d 2 -xLLL -Z -W -D cn=admin,cn=config -b cn=config cn=config
In der Ausgabe sollten die StartTLS-Operation, die verwendete TLS-Version und die Übertragung des Server-Zertifikats sichtbar sein. Es folgt ein Auszug daraus.
ldap_write: want=31, written=31 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 -> 1.3.6.1.4.1.1466.20037 is the StartTLS LDAP operation code ldap_read: want=8, got=8 0000: 30 0c 02 01 01 78 07 0a 0....x.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... -> 01 00: 00 is resultCode = success tls_write: want=93, written=93 0000: 16 03 02 00 58 01 00 00 54 03 02 4f 48 1b 02 ca ....X...T..OH... 0010: 6e 94 24 b1 bf 50 08 38 1e 12 21 6d c6 78 7f 84 n.$..P.8..!m.x.. 0020: ee 02 14 a7 1d 93 e5 f6 dd 23 1d 00 00 24 00 33 .........#...$.3 0030: 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87 .E.9.....2.D.8.. 0040: 00 13 00 66 00 2f 00 41 00 35 00 84 00 0a 00 05 ...f./.A.5...... 0050: 00 04 01 00 00 07 00 09 00 03 02 00 01 ............. tls_read: want=5, got=5 0000: 16 03 02 00 4a ....J tls_read: want=74, got=74 0000: 02 00 00 46 03 02 4f 48 1b 02 a9 af 24 4c 96 32 ...F..OH....$L.2 -> 0x0302 is TLS v1.1 0010: 07 f0 e3 1a 18 91 98 cc fd 5f 1b d1 b7 9e e5 36 ........._.....6 0020: d8 3a c2 16 bc 8c 20 da 87 37 f2 b3 84 e5 47 cb .:.... ..7....G. 0030: 0e e0 61 6a 22 1d cc 9f 77 67 cf 9b 1a 45 7c db ..aj"...wg...E|. 0040: 32 02 50 1f 30 f7 4e 00 2f 00 2.P.0.N./. tls_read: want=5, got=5 0000: 16 03 02 08 5d ....] ...
Da eine gültige Konfiguration nötig ist, um den slapd-Daemon zu starten, allerdings der Dienst laufen muss, damit die Konfiguration geändert werden kann, empfiehlt es sich, nach jedem größeren Schritt die aktuelle Datenbank und Konfiguration zu sichern.
Beim Erstellen und Wiederherstellen von Backups ist beim cp-Befehl auf die Optipn -p
zu achten! Wird diese vergessen, hat der slapd-Daemon keine Möglichkeit, auf die Verzeichnisse zuzugreifen, und wird nicht mehr starten!
Folgende Befehle sichern den aktuellen Zustand der Datenbank und der Konfiguration.
cp -rp /var/lib/ldap /var/lib/ldap.bak cp -rp /etc/ldap/slapd.d /etc/ldap/slapd.d.bak
Wiederherstellen lässt sich beides mit
rm -r /var/lib/ldap /etc/ldap/slapd.d cp -rp /var/lib/ldap.bak /var/lib/ldap cp -rp /etc/ldap/slapd.d.bak /etc/ldap/slapd.d
Als weiteres (auch für tägliches Backup im laufenden Betrieb geeignetes) Mittel zur Sicherung von OpenLDAP können folgende Skripte verwendet werden.
Zur Sicherung:
1 2 3 4 5 6 7 8 | #!/bin/bash BACKUP_PATH=/var/backups nice slapcat -n 0 > ${BACKUP_PATH}/config.ldif nice slapcat -n 1 > ${BACKUP_PATH}/example.com.ldif nice slapcat -n 2 > ${BACKUP_PATH}/access.ldif chmod 640 ${BACKUP_PATH}/*.ldif |
Zum Wiederherstellen:
1 2 3 4 5 6 7 8 9 10 11 12 | #!/bin/bash BACKUP_PATH=/var/backups sudo service slapd stop sudo mkdir /var/lib/ldap/accesslog sudo slapadd -F /etc/ldap/slapd.d -n 0 -l ${BACKUP_PATH}/config.ldif sudo slapadd -F /etc/ldap/slapd.d -n 1 -l ${BACKUP_PATH}/domain.com.ldif sudo slapadd -F /etc/ldap/slapd.d -n 2 -l ${BACKUP_PATH}/access.ldif sudo chown -R openldap:openldap /etc/ldap/slapd.d/ sudo chown -R openldap:openldap /var/lib/ldap/ sudo service slapd start |
Die erste Methode ist für die Konfigurationsphase wegen der Einfachheit besser geeignet. Sobald man allerdings ein laufendes System hat, sollte die zweite Methode verwendet werden, denn eine Sicherung, die mit dieser Methode gemacht wurde, kann auch auf ein frisch installiertes System angewandt werden.
Die zur Konfiguration verwendeten .ldif-Dateien sollten in /etc/ldap bleiben, um den Dienst schnell und unkompliziert wieder aufsetzen oder verändern zu können!