MAPI-Anmeldung per PAM an Kopano bzw. Zarafa
Was ist pam_mapi eigentlich genau und wann benötigt man es? Welche Funktionalitäten weist es auf und wie wird es konfiguriert? Setzt pam_mapi eine Installation von Kopano Core (KC) oder der Zarafa Collaboration Platform (ZCP) zwingend voraus? Erfahren Sie nachfolgend, wie Sie pam_mapi installieren und es anschließend auf Ihrem System optimal benutzen.
Bei pam_mapi handelt es sich um ein Modul für PAM (was für Pluggable Authentication Modules steht). PAM ist eine Bibliothek, die Schnittstellen für Authentifizierungsdienste auf Linux-/Unix-Systemen zur Verfügung stellt und es damit ermöglicht, verschiedenste Serverdienste mit einer zentralen Authentifzierungsdatenbank zu verbinden. So können Administratoren beispielsweise sicherstellen, dass alle Dienste mit einem zentral gespeicherten Passwort arbeiten - und letzlich getrennte Passwortdatenbanken vermeiden. Um die Authentifikation mit einem Kopano- bzw. Zarafa-Server als Passwortdatenbank kümmert sich das PAM-Modul pam_mapi.
Anwendungen wie die Kopano WebApp, die Kopano DeskApp, der Zarafa WebAccess, die Zarafa WebApp oder Microsoft Outlook (mit dem Zarafa Windows Client) verbinden sich über MAPI in SOAP zu Kopano Core (KC) bzw. zur Zarafa Collaboration Platform (ZCP) und wickeln auch darüber die Authentifizierung z.B. beim Versand von E-Mails ab. Alle Benutzer-Informationen dafür werden in einer MariaDB- oder MySQL-Datenbank gespeichert, wurde Kopano bzw. Zarafa mit dem Datenbank-Plugin konfiguriert. Kommt jedoch IMAP/POP3 über das Kopano- bzw. Zarafa-Gateway ins Spiel, so ist meist SMTP für ausgehende E-Mails involviert. Hierfür benötigt man üblicherweise SMTP-Authentifizierung (auch "SMTP-Auth"), um sogenannte offene Relays zu vermeiden, aber die Benutzer-Informationen in der MariaDB- oder MySQL-Datenbank sind für die gängigen SASL-Daemons nicht verwendbar.
Das Passwort wird zwar generell als MD5-Hash abgelegt, wird jedoch zusätzlich mehrmals mit einem Salt versehen und es werden jeweils erneut MD5-Hashes gebildet. Das spricht zwar für die Sicherheit, aber Cyrus SASL beispielsweise erwartet ein Klartext-Passwort in der Datenbank, wird das Plugin "SQL auxprop" verwendet. Die sogenannten "Frost-Patches" helfen hier ebenfalls leider nicht weiter - abgesehen davon, dass sie in führenden Linux-Distributionen, die auch im professionellen Umfeld verwendet werden, nicht enthalten sind. Und pam_mysql unterstützt zwar Passwörter als MD5- oder SHA1-Hash (abgesehen von Klartext-Passwörtern), doch keine Salts.
Genau diese Lücke füllt pam_mapi durch die Bereitstellung von MAPI-basierter Authentifizierung, die dann wiederum von einem SASL-Daemon für den SMTP-Dienst verwendet werden kann. Typischerweise wird Sendmail oder Postfix verwendet und "saslauthd" (aus Cyrus SASL) kümmert sich dann mittels pam_mapi um die Prüfung der Benutzer-Informationen aus dem SMTP-Dialog. Letztendlich baut pam_mapi eine Verbindung zum hinterlegten Kopano- bzw. Zarafa-Server auf und führt eine Anmeldung durch - das Ergebnis wird entsprechend zurückgeliefert woraufhin der SMTP-Dienst dann den Versand von E-Mails zulässt oder ablehnt. Lizenziert ist pam_mapi unter der 3-Klausel-BSD bzw. GNU General Public License (GPL), da es einen potentiellen Konflikt zwischen der GNU GPL und den Einschränkungen beim Copyright im BSD-Stil gibt.
Da es sich bei pam_mapi um ein generisches PAM-Modul handelt, kann es auch für andere Dienste mit Unterstützung für PAM-Authentifizierung verwendet werden, z.B. beim Apache Webserver oder Samba. Wird das Modul mit pam_unix kombiniert, so kann die Authentifizierung anhand von Kopano-/Zarafa- und Systembenutzern erfolgen, wobei ein Benutzer nur in einer der beiden Passwortdatenbanken existieren muss. Die in PAM übliche Prüfung zur Existenz von Benutzern ist ebenfalls vorhanden, jedoch aufgrund der Implementation nur eingeschränkt nutzbar, da die Existenz eines Benutzers nur durch eine erfolgreiche Anmeldung bestätigt wird. Für die allermeisten Einsatzgebiete hat dies damit keinerlei Auswirkung.
Auch wenn pam_mapi hauptsächlich für die Verwendung mit Kopano bzw. Zarafa und dem Datenbank-Plugin entwickelt wurde und gedacht ist, so ist es nicht darauf beschränkt. Jedoch sollte bei Verwendung des LDAP- oder Unix-Plugins bei Kopano bzw. Zarafa die Verwendung von pam_unix oder pam_ldap evaluiert werden. Zwar sind Kopano bzw. Zarafa zur Zeit die einzigen MAPI Service Provider, die MAPI4Linux unterstützt (welches wiederum von pam_mapi genutzt wird), jedoch kann pam_mapi damit theoretisch verschiedenste MAPI-basierte Serverdienste (z.B. Microsoft Exchange) unterstützen. OpenChange, eine andere MAPI-Implementation, unterstützt zwar das von Microsoft Exchange genutzte MAPI/RPC, jedoch ist die restliche MAPI-Unterstützung bislang deutlich unvollständiger als beim von Kopano bzw. Zarafa genutzten MAPI4Linux.
Die Installation von pam_mapi funktioniert bei einer aktuellen Version der Linux-Distribution Fedora bzw. bei Red Hat Enterprise Linux bzw. CentOS oder einer anderen auf Fedora basierenden Distribution mittels yum sehr einfach. Allerdings muss bei RHEL bzw. CentOS das Repository EPEL in yum eingebunden und aktiviert sein:
tux:~ # yum install -y pam_mapi
Ist für Ihre Linux-Distribution noch kein vorkompiliertes Paket verfügbar, so können Sie einfach pam_mapi herunterladen und selbst kompilieren. Eine entsprechende Anleitung sowie eine Liste der Abhängigkeiten zu anderen Software-Komponenten findet sich innerhalb der Archivdatei. In jedem Fall ist im Anschluss an die Installation eine Konfiguration erforderlich; gängig ist die Authentifizierung mit einem Kopano- bzw. Zarafa-Server, d.h. nur Kopano- bzw. Zarafa-Benutzer können sich anmelden. Hierfür muss in /etc/pam.d/smtp, der SMTP-Konfiguration im PAM-Konfigurationsverzeichnis, nachfolgendes eingefügt werden:
#%PAM-1.0
auth required pam_mapi.so try_first_pass
account required pam_mapi.so
Seit Kopano 8.0.0 bzw. Zarafa 7.0.0 können bestimmte Features pro Benutzer aktiviert bzw. deaktiviert werden. Die obige Konfiguration würde auch dann eine erfolgreiche Authentifizierung zurückmelden wenn z.B. IMAP für diesen Benutzer deaktiviert ist. Durch das Hinzufügen der Option service kann sichergestellt werden, dass mindestens eines der angegebenen Features für den jeweiligen Benutzer aktiviert ist bevor eine erfolgreiche Authentifizierung zurückgemeldet wird:
#%PAM-1.0
auth required pam_mapi.so try_first_pass service=imap
account required pam_mapi.so
Eine andere gängige Situation ist die Authentifizierung anhand von Kopano-/Zarafa- und Systembenutzern: Diese Konfiguration hängt maßgeblich von der verwendeten Linux-Distribution ab, wobei im Normalfall die beiden nachfolgenden Zeilen vor den bestehenden Zeilen in die PAM-Konfiguration eingefügt werden müssen.
auth sufficient pam_mapi.so try_first_pass quiet
account sufficient pam_mapi.so
Auf Red Hat Enterprise Linux 5 (und Derivaten wie CentOS) ist bei Authentifizierung gegen Kopano-/Zarafa- und Systembenutzer in /etc/pam.d/smtp nachfolgendes einzutragen:
#%PAM-1.0
auth sufficient pam_mapi.so try_first_pass quiet
auth include system-auth
account sufficient pam_mapi.so
account include system-auth
Und die gleiche Konfiguration lautet für Red Hat Enterprise Linux 6 und 7 (sowie für Derivate wie CentOS):
#%PAM-1.0
auth sufficient pam_mapi.so try_first_pass quiet
auth include password-auth
account sufficient pam_mapi.so
account include password-auth
Die Konfiguration von saslauthd für die Verwendung von PAM als Authentifizierungsmechanismus ist bei vielen Linux-Distributionen in /etc/sysconfig/saslauthd möglich. Zudem muss natürlich noch der eigentliche MTA (Mail Transfer Agent), also z.B. Sendmail oder Postfix, für die Verwendung mit saslauthd konfiguriert werden. Bei Sendmail ist die Datei /etc/mail/sendmail.mc um beispielsweise nachfolgendes zu erweitern:
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
Bei Postfix ist hingegen die Datei /etc/postfix/main.cf entscheidend und sollte daher in etwa nachfolgendes beinhalten:
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
Zudem muss noch eine weitere Datei, bei Sendmail die /etc/sasl2/Sendmail.conf bzw. /usr/lib(64)/sasl2/Sendmail.conf und bei Postfix die /etc/sasl2/smtpd.conf bzw. /usr/lib(64)/sasl2/smtpd.conf, nachfolgendes enthalten:
pwcheck_method: saslauthd
mech_list: plain login
Abschließend müssen noch die betroffenen Dienste neu gestartet werden damit die geänderte Konfiguration neu eingelesen wird; für Sendmail ist dies:
tux:~ # service sendmail restart
Shutting down sm-client: [ OK ]
Shutting down sendmail: [ OK ]
Starting sendmail: [ OK ]
Starting sm-client: [ OK ]
tux:~ #
Und für Postfix muss stattdessen der nachfolgende Befehl ausgeführt werden:
tux:~ # service postfix restart
Shutting down postfix: [ OK ]
Starting postfix: [ OK ]
tux:~ #
Unabhängig von Sendmail oder Postfix muss "saslauthd" in jedem Fall neugestartet werden:
tux:~ # service saslauthd restart
Stopping saslauthd: [ OK ]
Starting saslauthd: [ OK ]
tux:~ #
Die Benutzer einer älteren Version des SuSE Linux Enterprise Servers verwenden rcsendmail restart bzw. rcpostfix restart und rcsaslauthd restart, um die Dienste neu zu starten. Weitere Informationen zur Konfiguration und zu möglichen Optionen finden sich in der Manpage:
tux:~ # man pam_mapi
Darüber hinaus erhalten Sie unter anderem noch Unterstützung in meinem Chatraum. Sollten Sie kommerzielle Unterstützung bei der Einrichtung von pam_mapi benötigen, so kontaktieren Sie mich bitte per E-Mail mit Ihrem Anliegen.
Weiterführende Links zu pam_mapi: