Einer für alles – so lautet die Devise der LDAP-Befürworter. Das Plugin »ldapdb« agiert als Proxy zwischen einem Postfix-Mailserver und dem zentralen Verzeichnisdienst und sorgt für sichere Nutzerauthentifizierung mit den Mechanismen des Simple Authentication and Security Layer.

Kein ernst zu nehmender Mailserver erlaubt es unauthentifizierten Usern, Mails zu verschicken. Wer zur gemeinsamen Nutzerverwaltung und Authentifizierung in seinem Postfix-Mailserver OpenLDAP nutzen wollte, hatte mit den gängigen Softwareversionen schlechte Karten. Zwar ließen sich beide über das Authentifizierungs-Framework Cyrus-SASL verbinden, doch der Authentifizierungs-Daemon »saslauthd« als Mittler hat Schwächen. Beispielsweise überträgt er Passwörter und Login-Namen unverschlüsselt zwischen Verzeichnisdienst und Mailserver.

Neue OpenLDAP-Versionen bringen das Cyrus-SASL-Plugin »ldabdb« mit, das die Funktion des Authentifizierungs-Daemon übernehmen kann. Der Workshop beschreibt, wie Sie per »ldapdb«-Plugin im Verzeichnisdienst gespeicherte Postfix-User mit Hilfe des SASL-Mechanismus Digest-MD5 authentifizieren. Die Vorteile sind, dass kein Passwort, und zwar weder als Klartext noch verschlüsselt, übers Netz muss und der SMTP-Server nicht lesend auf den Datenbestand zugreifen kann.

Der Simple Authentication and Security Layer (SASL) ermöglicht es den verbindungsorientierten Protokollen wie LDAP, SMTP und IMAP, Anwender zu authentifizieren und Datenpakete sicher und verschlüsselt zu transportieren. Dazu wählt SASL einen von mehreren Mechanismen wie Cram-MD5, Digest-MD5 und GSSAPI. Die Mechanismen Plain und Login lassen sich in dem hier beschriebenen Modell jedoch nur nutzen, wenn die »STARTTLS«-Funktion in »ldapdb« aktiviert ist oder die Kommunikation über den Localsocket »ldapi« erfolgt.

RFC 2222[1] beschreibt den SASL-Standard. Das Dokument legt zum Beispiel fest, dass SASL-Mechanismen in Großbuchstaben zu schreiben sind. Es definiert aber nicht, wie Anwenderdaten, also User-ID und Passwort, vorzuhalten sind. Das liegt im Verantwortungsbereich des Administrators.

Abbildung 1: Der Client authentifiziert sich per SASL-Mechanismus am Mailserver Postfix. Der Mailserver benutzt das Ldapdb-Plugin, um ebenfalls per SASL die Benutzerdaten im OpenLDAP-Verzeichnis zu prüfen. Dazu meldet er sich erst unter seiner eigenen Proxyuser-Identität an, um sich danach stellvertretend unter der Identität des Mailclients zu authentifizieren.

SASL-Mechanismen

SASL-Mechanismen müssen bei der Internet Assigned Numbers Authority (IANA,[2]) registriert sein. Neben kommerziellen Anbietern gibt es die Open-Source-Mechanismen der Carnegie Mellon University. Sie sind in dem Paket Cyrus-SASL enthalten, das außerdem noch das C-API »libsasl«, die Datenbankanwendung »sasldb2«, Schnittstellen für den Zugriff auf externe Datenquellen und so genannte Auxiliary-Property- Plugins mitbringt.

Gemäß RFC 2222 kann die Anwenderauthentifizierung durch einen Proxyuser erfolgen, also durch eine dritte Identität, die als Statthalter für den realen Anwender agiert. OpenLDAP unterstützt diese RFC-Empfehlung, die als Basis für das folgende Modell dient.

Der Ablauf erfolgt in drei Schritten. Der Mail User Agent (MUA) des Anwenders öffnet beim Versand von E-Mail eine verschlüsselte Verbindung zum SMTPD. Dieser entnimmt seiner Konfigurationsdatei »smtpd.conf«, dass die Authentifizierung durch das Plugin »ldapdb« und die Identität des Proxyusers erfolgt. Der Proxyuser authentifiziert sich nun per SASL-Mechanismus am Verzeichnisdienst, übernimmt die Identität des Anwenders, prüft das Passwort und gibt im Erfolgsfalle sein Okay. Der gesamte Datenverkehr zwischen MUA, SMTPD und LDAP-Server erfolgt verschlüsselt. Abbildung 1 stellt den Ablauf dar.

In dieser Konstruktion lassen sich unterschiedliche SASL-Mechanismen verwenden. Die Kommunikation zwischen MUA und SMTPD richtet sich danach, welche Mechanismen beide kennen. Nicht alle Mailprogramme beherrschen qualifizierte Verschlüsselungsmethoden. Die einkompilierten SASL-Mechanismen des SMTPD erfragen Sie am besten in einer Telnet-Sitzung: Nach dem »ehlo server .example.com« verrät Postfix unter anderem, welche Mechanismen es unterstützt (Abbildung 2).

Die Kommunikation zum Verzeichnisdienst richtet sich ebenfalls nach den in OpenLDAP einkompilierten SASL-Mechanismen. Diese prüfen Sie mit dem Befehl »ldapsearch -x -b “” -s base +«, in der Ausgabe taucht zum Beispiel Folgendes auf:

supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: ANONYMOUS
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: DIGEST-MD5

Das Plugin »ldapdb« bringt Cyrus-SASL ab Release 2.1.19 mit. In dieser oder in neueren Versionen sollte im Verzeichnis »/usr/lib/sasl2« die Datei »libldapdb.so« liegen. Den folgenden Abschnitt über die Kompilation dürfen Sie in diesem Fall überspringen und gleich beim Thema Konfiguration einsteigen.

Abbildung 2: In einer Telnet-Sitzung verrät Postfix per »250-AUTH«-Ausgabe, welche SASL-Mechanismen es unterstützt. Dieser Server beherrscht »GSSAPI«, »CRAM-MD5« und »DIGEST-MD5«.

Auch in ältere Release-Versionen lässt sich »ldapdb« integrieren. Die erforderlichen Zutaten sind die aktuellen OpenLDAP- und Cyrus-SASL-Quellen ([3],[4]), vorzugsweise in den Versionen OpenLDAP 2.2.11 und Cyrus-SASL 2.1.17 oder aktueller, sowie eine installierte Berkeley-DB 4.2.52 samt Headerdateien. Wer diese Versionen nicht auf seinem System hat, muss aktuelle Versionen kompilieren und installieren.

01 ./configure --disable-checkapop --disable-otp  --disable-krb4 --disable-plain --with-dblib=berkeley  --with-bdb-libdir=/usr/local/BerkeleyDB.4.2/lib  --with-bdb-incdir=/usr/local/BerkeleyDB.4.2/include  --disable-saslauth --with-gss_impl=heimdal

01 ./configure --enable-local  --enable-spasswd --enable-bdb=yes  --enable-hdb=yes --enable-monitor=yes

01 sh ../libtool --mode=link gcc -Wall -W -g 02 -L/usr/local/lib -WL, -rpath,/usr/local/lib -module -export-dynamic -rpath /usr/lib/sasl2 -o libldapdb.la  -version-info 2:18:0 ldapdb.lo -lldap -llber -lssl -lcrypto

01 dn: o=example,c=com
02 objectclass: organization
03 o: example
04 
05 dn:ou=users,o=example,c=com
06 objectclass: organizationalUnit
07 ou: users
08 
09 dn: cn=Mailadmin,o=example,c=com
10 objectclass: person
11 objectclass: extensibleObject
12 sn:Mailadmin
13 cn:Mailadmin
14 uid: mailadmin
15 userPassword: geheim
16 saslAuthzTo: dn.regex: cn=(.*),  o=example,c=com
17 
18 dn: cn=Hans Mustermann,ou=users,  o=example,c=com
19 objectclass: inetorgPerson
20 sn: Mustermann
21 cn: Hans Mustermann
22 uid:hansmu
23 mail: hansmu@example.com
24 userPassword:StrengGeheim

01 password-hash {CLEARTEXT}
02 access to attrs=userPassword
03   by self write
04   by anonymous auth
05 sasl-authz-policy To
06 sasl-regexp uid=(.*),cn=.*,cn=auth
07   ldap:///ou=users,o=example,c=com??one?uid=$1
08 database hdb
09 directory /var/openldap
10 suffix o=example,c=com
11 rootdn cn=admin,o=example,c=com
12 rootpw sagIchNicht

Kompilationsschritte

Die Listing 1 und 2 führen die minimalen »configure«-Parameter für einen erfolgreichen Einsatz auf. Da OpenLDAP von der Cyrus-SASL- und Berkeley-DB-Version abhängt, kompilieren und installieren Sie zuerst Cyrus-SASL. Für die Version 2.1.19 geben Sie zusätzlich die Parameter »–with-ldapdb –with-ldap= /Pfad-zu-OpenLDAP« an.

Die in Listing 1 enthaltenen Pfadangaben für Berkeley-DB und auch die Kerberos-Implementierung dienen als Beispiel. Kerberos ist nicht zwingend, aber schön zu haben. Die Parameter für OpenLDAP gelten nur für 2.2, die Version 2.1 hat eine andere Syntax. Mit »./configure && make depend && make && make install« kompilieren Sie das jeweilige Paket.

Um das Plugin Ldapdb zu erzeugen, kopieren Sie die Datei »ldapdb.c« im Unterverzeichnis »contrib/ldapsasl« des OpenLDAP-Quellverzeichnisses nach »cyrus-sasl-2.1.18/plugins«. Nach dem Wechsel in das Verzeichnis »plugins« erzeugen Sie mit dem Befehl »make ldapdb.lo« das Binary.

Da kein Makefile vorhanden ist, linken Sie es mit dem Befehl in Listing 3 manuell. Dieser Aufruf erzeugt die nötigen Libraries »libldapdb.la« und ».libs/libldapdb.so.2.0.18«. Kopieren Sie beide nach »/usr/local/lib/sasl2« und legen zum Schluss noch zwei symbolische Links »libldapdb.so« und »libldapdb.so.2« auf die Datei »libldapdb.so.2.0.18«.

LDAP konfigurieren

Nach der Installation richten Sie zuerst den Verzeichnisdienst ein. Listing 4 zeigt eine Muster-LDIF-Datei mit den nötigen Angaben für den Proxyuser »Mailadmin« und einen Anwenderaccount. Der Eintrag des »Mailadmin« enthält zwei Besonderheiten: Da das nötige Attribut »uid« in der Objektklasse »person« nicht enthalten ist, ergänzen Sie den Eintrag um die Objektklasse »extensibleObject«, sie verfügt stellvertretend über alle eingebundenen Attribute. »saslAuthzTo« ist ein operationales Attribut, das heißt, es gehört keiner Objektklasse an.

Den in Listing 4, Zeile 16 dargestellten Wert des Attributs »saslAuthzTo« gibt es nur in OpenLDAP 2.2, für Version 2.1 stellen Sie diesen Wert als LDAP-URL dar, zum Beispiel:

saslAuthzTo: ldap:///ou=users,o=example,
  c=com??one?objectclass=inetorgPerson

In die URL müssen Sie die Werte für Ihren Server eintragen. Im Gegensatz zu »dn.regex«, das jeweils nur einen Wert ausgeben sollte, durchsucht LDAP hier die gesamte Datenbank und kann daher mehrere Suchergebnisse zurückliefern. Aus Sicherheitsgründen ist deshalb davon abzuraten, diese Konstruktion zu verwenden.

In die Datei »slapd.conf« fügen Sie – wie in Listing 5 beschrieben – die für die Proxy-Authentifizierung erforderlichen Parameter ein. Da die Authentifizierung durch den SASL-Mechanismus Digest-MD5 erfolgt, muss das Passwort unverschlüsselt eingegeben werden. Mit »password-hash {CLEARTEXT}« teilen Sie dem LDAP-Server mit, dass er das Passwort im Klartext erhält. Das erfordert besonderen Leseschutz, damit nicht jeder das Passwort auslesen kann. Die Access-Regel in den folgenden drei Zeilen beschränkt deshalb den Zugriff auf das Passwortattribut.

Die Anweisung in Zeile 5 initiiert die Proxy-Authentifizierung durch den Mailadmin, »sasl-regexp« mappt den Authentifizierungsstring

uid=hansmu,cn=digest-md5,cn=auth

auf den Distinguished Name »cn=Hans Mustermann,ou=users,o=example,c= com«. Mit dem Befehl »slapadd -l muster.ldif« laden Sie nun die LDIF-Datei.

Abbildung 3: Der Befehl »ldapwhoami« prüft, ob die Proxy-Authentifizierung klappt. Hier authentifiziert der Proxyuser »admanager« erfolgreich den Benutzer »dieter«.

SASL- und Postfix-Setup

Jetzt müssen Sie noch den Mailserver Postfix (Listing 6) und Cyrus-SASL konfigurieren. Leider gibt es dafür zwei Möglichkeiten. Die Konfiguration für Cyrus-SASL 2.1.19 beschreibt Listing 7, die Konfiguration für selbst kompilierte Versionen das Listing 8.

Dann ist es Zeit für erste Funktionstests. Ob die Proxy-Authentifizierung erfolgreich ist, prüfen Sie mit:

ldapwhoami -U mailadmin -Y DIGEST-MD5 -X 
  u:hansmu -H ldap://server.example.com

Als Passwort geben Sie das von Mailadmin ein und passen die LDAP-URL an Ihre Konfiguration an. Das Ergebnis zeigt Abbildung 3. Ein MUA sollte jetzt unauthentifiziert keine E-Mails mehr versenden können.

Jeder MUA muss anders konfiguriert werden, um sich über SASL zu authentifizieren. Üblicherweise aktivieren Sie in der SMTP-Konfiguration den Punkt »Sichere Verbindung zum Server« beziehungsweise »Server verlangt Passwort« und wählen als Mechanismus »DIGEST- MD5« oder »CRAM-MD5« aus.

Damit ist die Konfiguration abgeschlossen. Der MUA kommuniziert in Zukunft verschlüsselt per SASL mit Postfix, der über den Proxyuser im LDAP-Verzeichnis ebenfalls per SASL die Daten des Anwenders überprüft. (eba)

01 smtpd_client_restrictions = permit_sasl_authenticated
02 smtpd_recipient_restrictions = permit_sasl_authenticated,      reject_unauth_destination
03 smtpd_sasl_auth_enable = yes
04 smtpd_sasl_security_options = noanonymous

01 pwcheck_method: auxprop
02 auxprop_plugin: ldapdb
03 ldapdb_uri:ldap://server.example.com
04 # ldapdb_uri:ldapi:///
05 ldapdb_id: mailadmin
06 ldapdb_pw: geheim
07 ldapdb_mech: DIGEST-MD5
08 # ldapdb_starttls: try

01 pwcheck_method: ldapdb
02 ldapdb_uri:ldap://server.example.com
03 # ldapdb_uri:ldapi:///
04 ldapdb_id: mailadmin
05 ldapdb_pw: geheim
06 ldapdb_mech: DIGEST-MD5
07 # ldapdb_starttls: try