In den vorhergehenden Beiträgen

Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – I
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – II
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – III

dieser Artikel-Reihe hatten wir eine einfache Installation des Cyrus IMAP-Dienstes auf einem Host namens “mycyrus” vorbereitet und durchgeführt. Der IMAP-Server nutzt einen LDAP-Server “ldap-serv” zur Authentifizierung von Benutzern, die Zugriff auf vorhandene IMAP-Mailboxen erhalten wollen.

In diesem Beitrag kümmern wir uns nun um die Anbindung eines KDE “Kmail”-Client an den IMAP-Server. Wir starten dazu “Kontact” oder “Kmail” auf einem Host “tux” im Netzwerk. Die nächsten Schritte beinhalten lediglich das Eingeben der Verbindungsdaten:

Dazu gehen wir in die Konfiguration der sog. “Zugänge” (gemeint sind Server-Zugänge – oder besser noch “Server-Konten”) über

Menüpunkt “Einstellungen” >> “Kmail einrichten” >> “Zugänge” >> Tab “Empfang”

Dort drücken wir auf den Button “Hinzufügen” und wählen im folgenden Auswahldialog die Option “IMAP-E-Mail-Server“.

Im nächsten Konfigurationsdialog geben wir die erforderlichen Zugangs- und Authentifizierungsdaten zum Server ein. Das sind zunächst vor allem unsere Userdaten für den IMAP-Dienst – also genau jene Daten, die wir im LDAP-System zu unserer Authentifizierung hinterlegt haben, und auf die der Server “mycyrus” gem. unserer Einrichtung in den letzten Artikeln per SASLAUTHD, PAM, SSSD zugreift. Wir verwenden hier wieder die Zugangsdaten unserer Testuserin “tarja” aus den vorhergehenden Artikeln:

Den Namen des Mail-Kontos (oberstes Feld) können wir dabei nach Gutdünken festlegen.

Von größerer Bedeutung ist ferner der Dialog unter dem Reiter “Erweitert“, den dort stellen wir ein, dass Kmail eine STARTTLS-Verbindung zum IMAP-Server aufbauen soll. Ein Druck auf den Button “Automatisch erkennen” sollte das fehlerfrei und im lokalen Netz innerhalb von Sekundenbruchteilen für uns erledigen. Falls der IMAP-Server TLS anbietet – und dafür haben wir ja durch die Cyrus Konfiguration im ersten Beitrag gesorgt – wird die TLS-Option automatisch ausgewählt. Als “Authentifizierung”s-Mechanismus kommt in unserem Fall nur “Plain” oder “Login” in Frage.

Sollte die automatische Konfiguration lange dauern oder zu Meldungen führen, so ist dies meist ein Zeichen dafür, dass

• entweder gar keine Kommunikation zum Server möglich ist
• oder es ein Problem mit der Zugangsberechtigung oder der Authentifizierung – in unserem Fall gegenüber einem LDAP-System – gibt
• oder TLS nicht funktioniert.

Dann sind eine Überprüfung der Kommunikation mit “telnet”, ein Check von Firewall-Einstellungen sowie spezifischere Tests (z.B. mit “imtest”) angesagt.

An dieser Stelle sollte man sich außerdem noch einmal bewusst machen, dass wir es gemäß unserer Installation mit 2 unterschiedlichen TLS-Verbindungen zu
tun haben:

• Der Mail-Client Kmail auf dem Host “tux” baut eine per STARTTLS gesicherte Verbindung zum IMAP-Server “mycyrus” auf und tauscht so abgesichert Userdaten und später auch Maildaten mit dem IMAP-Server aus.
• Der IMAP-Server “mycyrus” hingegen baut zur Authentifizierung des Users “tarja” über SASLAUTHD, PAM und vor allem SSSD eine per STARTTLS gesicherte Verbindung zum LDAP-Server (hier “ldap-serv”) auf.

Für die erste Verbindungsmöglichkeit sorgt eine adäquate Konfiguration des Cyrus IMAP-Dienstes und natürlich auch des E-Mail-Clients Kmail. Die zweite Verbindung beruht auf einer TLS-fähigen Auslegung des LDAP-Servers und einer geeigneten Konfiguration von SASL, PAM und SSSD auf dem Server “mycyrus”. Siehe hierzu die vorangegangenen Artikel.

Als nächstes schließen wir die Einrichtung unseres IMAP-Kontos durch Drücken des Buttons “OK” ab. Der Server-Zugang namens “mycyrus-tarja” sollte nun gem. der oben gewählten Einstellungen angelegt worden sein und als funktionstüchtig (“bereit”) angezeigt werden:

Wechseln wir nun zur Standardansicht von “Kontact”, so sollten wir etwa ein Bild der folgenden Art erhalten:

Natürlich ist die Mailbox im Gegensatz zur obigen Darstellung in Ihrem Fall noch leer. Aber mit Hilfe von Kontakt/Kmail können wir nun schon Mails aus anderen Mailfoldern anderer Server in die Mailfolder des neuen Accounts – hier “mycyrus-tarja” kopieren und die kopierten Mails danach auch ansehen.

Damit haben wir eine vollständige Kette

E-Mail-Client Kmail <= TLS => Cyrus IMAP-Server mit userspezifischen und allgemeinen Mailboxen < = TLS => LDAP-Server zur Authentifizierung von IMAP-User

realisiert. Denn in Zeiten wie diesen gilt auch im hauseigenen Netzwerk: Ein Schutz gegen unerwünschtes Ausspähen kann nicht verkehrt sein – zumal, wenn er sich – wie gezeigt – unter Linux doch recht einfach einrichten lässt.

Im nächsten Beitrag beschreibe ich zur Abrundung des Cyrus IMAP-Themas noch die Einrichtung von “Webmin” zur grafischen Verwaltung der Mailboxen und zugehöriger Zugriffsrechte.

In den letzten beiden Beiträgen
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – I
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – II
unserer kleinen Serie zur Implementierung eines Cyrus IMAP-Dienstes mit LDAP-Authentifizierung über PAM und SSSD hatten wir uns mit den IMAP-Konfigurationsdateien sowie der PAM, SSSD- und partiell auch der LDAP-Konfiguration herumgeschlagen. Getestet haben wir bereits den “saslauthd”-Authentifizierungsmechanismus.

Den IMAP-Service selbst hatten wir dagegen noch gar nicht gestartet oder benutzt. Wir holen dies nun nach und testen dann den Zugriff zunächst rein per “telnet” (oder “imtest”) und expliziten IMAP-Komandos. Ich finde es lehrreich, unabhängig von echten Mail-Clients auch mal die Kommandozeile zu nutzen.

Starten des Cyrus- IMAP-Servers

Wir starten den IMAP-Dienst:

systemctl start cyrus.service

Das sollte nach den Konfigurationsvorbereitungen der letzten Artikel anstandslos funktionieren ! Also etwa so:

mycyrus:~ # systemctl start cyrus.service
mycyrus:~ # systemctl status cyrus.service
cyrus.service – LSB: The cyrus-imapd mail system
Loaded: loaded (/etc/init.d/cyrus)
Active: active (running) since Wed 2014-03-12 19:56:23 CET; 7s ago
Process: 9392 ExecStop=/etc/init.d/cyrus stop (code=exited, status=0/SUCCESS)
Process: 9404 ExecStart=/etc/init.d/cyrus start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/cyrus.service
├─9412 /usr/lib/cyrus/bin/master -p /var/run/cyrus.pid -d
└─9417 idled
Mar 12 19:56:23 mycyrus master[9418]: about to exec /usr/lib/cyrus/bin/ctl_cyrusdb
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: checkpointing cyrus databases
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: archiving log file: /var/lib/imap/db/log.0000000001
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: archiving log file: /var/lib/imap/db/log.0000000001
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: archiving log file: /var/lib/imap/db/log.0000000001
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: archiving database file: /var/lib/imap/annotations.db
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: archiving database file: /var/lib/imap/mailboxes.db
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: archiving log file: /var/lib/imap/db/log.0000000001
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: done checkpointing cyrus databases
Mar 12 19:56:23 mycyrus master[9412]: process 9418 exited, status 0

Danach “enablen” wir den Service mal prophylaktisch:

mycyrus:~ # systemctl enable cyrus.service

Anlegen von Mailverzeichnissen für unsere Test-Userin “tarja”

Wir legen nun gezielt eine Mailbox mit Subfoldern für unsere Testuserin “tarja” an. Dazu benutzen wir die “cyradm“-Umgebung:

mycyrus:/etc/pam.d # su – cyrus
cyrus@mycyrus:~> cyradm
cyradm> connect localhost
Password:
localhost> cm user.tarja
localhost> cm user.tarja.Drafts
localhost> cm user.tarja.Sent
localhost> cm user.tarja.Spam
localhost> cm user.tarja.Junk
localhost> cm user.tarja.Archive
localhost> lm user.tarja.*
user.tarja.Archive (\HasNoChildren) user.tarja.Sent (\HasNoChildren)
user.tarja.Drafts (\HasNoChildren) user.tarja.Spam (\HasNoChildren)
user.tarja.Junk (\HasNoChildren)
localhost> exit
cyrus@mycyrus:~> exit
Abgemeldet
mycyrus:/etc/pam.d #

Test des Remote-Zugangs

Nun testen wir von einem Remote-Host “tux” aus, ob wir den IMAP-Dienst auf “mycyrus” erreichen können. Ich setze voraus, dass alle Firewall-Einstellungen so gesetzt sind, dass ein Zugang über den Standard Imap-Port 143 möglich ist. Mehr benötigen wir bei Anwendung von STARTTLS nicht. Erstmal remote über “telnet” von einem anderen Linux-System “tux” aus :

tarja@tux:~> telnet mycyrus 143
Trying 192.168.0.88…
Connected to mycyrus.
Escape character is ‘^]’.
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN AUTH=LOGIN SASL-IR COMPRESS=DEFLATE] mycyrus Cyrus IMAP v2.3.16 server ready
starttls login tarja TARJAPWD
starttls OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID LOGINDISABLED COMPRESS=DEFLATE ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE X-NETSCAPE URLAUTH] User logged in
r list all “*”
r OK Completed (0.000 secs 1 calls)
r list “” “*”
* LIST (\Noinferiors) “.” “INBOX”
* LIST (\HasNoChildren) “.” “Archive”
* LIST (\HasNoChildren) “.” “Drafts”
* LIST (\HasNoChildren) “.” “Junk”
* LIST (\HasNoChildren) “.” “Sent”
* LIST (\HasNoChildren) “.” “Spam”
* LIST (\HasNoChildren) “.” “Trash”
r OK Completed (0.000 secs 8 calls)
s select Drafts
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]
* 2 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1394475578]
* OK [UIDNEXT 3]
* OK [NOMODSEQ] Sorry, modsequences have not been enabled on this mailbox
* OK [URLMECH INTERNAL]
s OK [READ-WRITE] Completed
t search all
* SEARCH 1 2
t OK Completed (2 msgs in 0.000 secs)
E fetch 1 (body[text])
* 1 FETCH (BODY[TEXT] {6}
test
)
E OK Completed (0.000 sec)
. logout
* BYE LOGOUT received
. OK Completed
Connection closed by foreign host.
tarja@tux:~>

Man erkennt nach der Initiierung des Dialogs, dass der Cyrus IMAP-Server zunächst seine Fähigkeiten – u.a. STARTTLS- ausweist. Das explizit abgesetzte “starttls”-Kommando funktioniert entsprechend problemlos.

Ferner sieht man, dass habe ich danach einige IMAP-Kommandos an den Server abgesetzt habe. Welche IMAP-Kommandos es gibt und wie man mit ihrer Hilfe unter “telnet” oder “imtest” direkt mit dem IMAP-Server kommunizieren kann, erfährt man z.B. hier:

http://www.skytale.net/blog/archives/23-Manual-IMAP.html
http://www.tcpipguide.com/free/t_IMAPOverviewHistoryVersionsandStandards.htm
http://donsutherland.org/crib/imap
http://adityo.blog.binusian.org/?tag=telnet-imap-command
http://busylog.net/telnet-imap-commands-note/
http://help.notify.net/TechDocs/enterprise/Troubleshooting/NetHelp/index.html?turl=WordDocuments%2Fotherimapcommands.htm

Jedes IMAP-Kommando wird durch einen Klein- oder Groß-Buchstaben oder einen “.” am Anfang der Zeile mit anschließendem Blank eingeleitet. Dieser Buchstabe ist syntaktisch erforderlich; er erleichtert die Orientierung im Kommandoablauf und zeigt anhand abschließender Bestätigungsmeldungen zu gleichen Startbuchstaben am Anfang der Zeile an, welche Antworten zu welchem Kommando gehören.

Einen ähnlichen Dialog
mit dem IMAP-Dienstes hätte man auch im Rahmen des Testkommando “imtest” führen können:

imtest -v -t “” -a tarja -u tarja -m login mycyrus

Das Absetzen des imtest-Kommandos erlaubt es einem zudem, den Austausch von TLS-Informationen direkt zu verfolgen. Das kann jeder mal selbst testen. Zu “imtest”findet man weitere Infos auf der man-Seite:
http://linux.die.net/man/1/imtest
http://www.cyrusimap.org/docs/cyrus-imapd/2.3.16/man/imtest.1.php

Der aufmerksame Leser wird beim Studieren des obigen IMAP-Dialogs unter “telnet” natürlich mitbekommen haben, dass ich dort im Ordner Drafts zwei Mails gefunden und eine davon sogar geöffnet habe. Natürlich muss man sich fragen, wie das vor sich gehen soll, wenn der Folder “Drafts” doch gerade erst angelegt wurde. Keine Sorge: Die Mails kommen nicht aus dem Nirwana; ich hatte sie dort vorab händisch reinkopiert, um zeigen zu können, dass man Mails auch über telnet öffnen kann.

Im nächsten Teil
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – IV
kümmere ich mich dann um eine Kmail-Anbindung an unseren offenbar funktionstüchtigen IMAP-Server, der unsere Testuserin “tarja” erfolgreich über ein LDAP-System authentifiziert hat.

Im ersten Teil dieser kleinen Serie von Beiträgen zur Implementierung des Cyrus IMAP-Dienstes auf einem Opensuse-System
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – I
hatte ich mögliche Inhalte der Konfigurationsdateien

/etc/cyrus.conf
/etc/imap.conf

angegeben und kurz diskutiert.

Bzgl. des Authentifizierungsverfahrens für spätere IMAP-User hatten wir “saslauthd” vorgegeben (siehe den Inhalt von imap.conf). Durch die Implementierung der Kette

SASLAUTHD => PAM => SSSD => LDAP

gemäß meines früheren Blog-Beitrags “SASL mit PAM, SSSD, LDAP unter Opensuse” kann auf dem IMAP-Host eine User-Authentifizierung gegen ein LDAP-System im Netzwerk vorgenommen werden. Den Host mit dem IMAP-Dienst nennen wir nachfolgend “mycyrus“, den LDAP-Server dagegen “ldap-serv“. Beide sollen der Domaine “anraconx.de” angehören.

So schön das verkettete Authentifizierungs-Verfahren auch sein mag – es ist in der bisher beschriebenen Form unzureichend:

Wir wollen schon aus Sicherheitsgründen nicht, dass diese Art der Authentifizierung einen echten User-Login mit Shell-Zugang auf dem IMAP-Server “mycyrus” ermöglicht. Folgt man den Rezepten des eben genannten Artikels, so ist dies aber leider der Fall. Nach der beschriebenen Einrichtung von PAM, SSSD und LDAP als Auth-Backend ist es jedem User, der einen gültigen Eintrag auf dem LDAP-Server hat, möglich, sich auf jedem Host, auf dem die PAM-SSSD-LDAP-Kette eingerichtet wurde – also auch “mycyrus” – einzuloggen. Dabei würde sogar ein Home-Verzeichnis eingerichtet werden. Dieses Verhalten ist für dedizierte Server wie “mycyrus” überhaupt nicht wünschenswert.

Wir müssen uns daher etwas andere Ziele stecken und diese mit möglichst geringem Aufwand realisieren.

Ziele der Authentifizierungskette auf dem IMAP-Server “mycyrus”

Bzgl. der Zugangsberechtigungen zu “mycyrus” und dem dortigen IMAP-Dienst wollen wir folgende Ziele erreichen:

• Die User, die auf dem LDAP-System hinterlegt sind, sollen nicht autorisiert werden, sich auf dem Host “mycyrus” normal einzuloggen. Sie dürfen keinen Shell-Zugang erhalten.
• Die im LDAP verwalteten User sollen sich aber sehr wohl für die Nutzung des IMAP-Dienstes authentifizieren können und zwar letztlich durch einen sog. “Simple Bind” auf dem LDAP-System.
• Dabei soll die Verbindung zwischen “mycyrus” und “ldap-serv” mit TLS abgesichert aufgebaut werden.
• Über spezielle Einträge auf dem LDAP-Server soll der Zugang zum Host “mycyrus” für bestimmte User ausgeschlossen werden

Auf unserem “mycyrus”-Server sollen ein Login und eine Shell-Nutzung nur für Root und ggf. für ganz bestimmte, lokal angelegte User (wie “cyrus”) möglich sein. Verdeutlicht wird dies durch folgende Abbildung:

Aus der Skizze wird der Lösungsansatz bereits erkennbar, den wir nun schrittweise umsetzen. Zwei explizite Warnungen sind angebracht:

Warnung 1:
Die von mir vorgeschlagenen Änderungen können bei Fehlern dazu führen, dass sich auch root nicht mehr auf “mycyrus” einloggen kann. Also bitte Vorsicht walten lassen und das ganze Verfahren zunächst auf einem Spielsystem testen, bevor man es auf produktive Systeme anwendet!

Warnung 2:
Wir werden mit YaST2 LDAP als Authentifizierungs-Backend für User abschalten und dann etliche grundlegende Konfigurationsdateien ändern. Danach darf man die YaST Konfigurationstools für den LDAP-Client oder für dir Backend-Einrichtung zur User-Authentifizierung nicht ohne Wissen um die Konsequenzen für die Konfigurationsdateien nutzen – denn YaST stellt u.a. bei einem Deaktivieren oder Aktivieren des LDAP-Clients zu viele Dinge parallel und automatisch um und würde unsere vorgenommenen Einstellungen ggf. wieder zunichte machen. Also bitte Backups der eigenen Konfigurationsdateien anlegen!

Schritt 1: LDAP-Backend für die User-Authentifizierung zwischenzeitlich und partiell abstellen

Als erstes stellen wir mittels “YaST2 => User und Group Administration => Reiter “Authentication Settings” => LDAP” und durch den entsprechenden Radiobutton im Dialogfenster die Benutzung von LDAP als Auth-Backend für das System ab. YaST stoppt dann u.a. den sog. “LDAP-Client”, indem es SSS (genauer: den SSSD-Dämon) deaktiviert; dies entspricht einem

systemctl stop sssd.service;   systemctl disable sssd.service    .

Die Einstellungen der Datei “/etc/sssd/sssd.conf” bleiben dabei aber erhalten. Das ist jedoch nicht ganz das, was wir wünschen:
Wir wollen ja vielmehr gerade, dass der Cyrus IMAP-Service später den “SSSD-Service” nutzen soll. Bei einer “normalen” Authentifizierung im Rahmen eines Logins soll sich PAM aber auf die lokalen Standardprüfungen beschränken. Deshalb müssen wir noch weitere Schritte durchführen, bevor wir SSSD schließlich wieder aktivieren und für saslauthd nutzbar machen.

Schritt 2 – SSS-Einträge aus der “Name Service Switch-Konfiguration” entfernen

Wir entfernen die “sss”-Einträge in der Datei “/etc/nsswitch.conf”. Also:

#passwd: compat sss
#group: compat sss
passwd: compat
group: compat

Dieser Schritt ist von zentraler Bedeutung ! Zur Bedeutung der “/etc/nsswitch.conf” bzw. des “Name Service Switch”-Dienstes siehe etwa
http://searchitchannel.techtarget.com/feature/Using-nsswitchconf-to-find-Linux-system-information
http://de.wikipedia.org/wiki/Name_Service_Switch
http://www.dummies.com/how-to/content/network-administration-linux-nsswitchconf-file.html

Die Entfernung des “sss”-Eintrags führt in unserem Fall zur Realisierung der in der obigen Skizze durch einen senkrechten roten Strich dargestellten Blockierung eines LDAP-Zugrifffes für die Standard-Authentifizierung von Usern durch den Login- und Passwort-Prozess. Will man ganz sicher gehen, kann man auch noch die Zeile

+::::::

aus der “/etc/passwd” entfernen.

Schritt 3 – “pam_sss.so”-Modul aus den PAM “common”-Dateien entfernen

Dann entfernen wir zusätzlich alle “pam_sssd.so“- Referenzen in den (susespezifischen) Dateien

“/etc/pam.d/common-auth”,
“/etc/pam.d/common-account”,
“/etc/pam.d/common-password”,
“/etc/pam.d/common-session”.

Betroffen ist pro Datei jeweils eine der folgenden Zeilen:

auth required pam_sss.so try_first_pass
account required pam_sss.so use_first_pass
password required pam_sss.so use_authtok
session optional pam_sss.so

Schritt 4 – “pam_sss.so”-Modul in der PAM-Datei “/etc/pam.d/imap” eintragen :

Danach editieren wir die service-spezifische Datei “/etc/pam.d/imap” und ersetzen deren Inhalt durch folgenden:

mycyrus:/etc/pam.d # cat imap
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_unix.so try_first_pass
auth required pam_sss.so use_first_pass
account sufficient pam_sss.so use_first_pass
account required pam_unix.so try_first_pass
account sufficient pam_localuser.so
session required pam_limits.so
session required pam_unix.so try_first_pass
session optional pam_sss.so
mycyrus:/etc/pam.d #

Oder alternativ:

#%PAM-1.0
auth sufficient pam_sss.so
auth required pam_env.so
auth required pam_unix.so try_first_pass
account sufficient pam_sss.so use_first_pass
account required pam_unix.so try_first_pass
account required pam_localuser.so
session optional pam_sss.so
session required pam_limits.so
session required pam_unix.so try_first_pass

Wichtig ist in jedem Fall die Reihenfolge der Statements. Warum die komplizierte Abfolge aus “required”- und “sufficient”-Bedingungen?

Weil wir wollen, dass neben den LDAP-Usern auch lokale User auf den IMAP-Dienst zugreifen dürfen. Dieser Bedarf besteht mindestens mal für den User “cyrus“; dieser muss ja den IMAP-Dienst und im Besonderen auch die Mailboxen verwalten dürfen. Dazu muss er eine Zugriffsberechtigung erhalten.

Es bleibt dem geneigten Leser überlassen zu überlegen und ggf. zu testen (ein Blick in “/var/log/messages” lohnt sich), warum man dann die vorgegebene Reihenfolge für die PAM-Module einhalten muss.

Übrigens: Wer beim Einsatz von Postfix SMTP-User auch über saslauthd authentifizieren will, legt sich am besten gleich eine Datei “/etc/pam.d/smtp” mit gleichem Inhalt an.

Schritt 5 – den “sssd.service” wieder aktivieren und Zugriffe samt Authentifizierung testen

Nun enablen wir erneut den “SSSD-Dämon” und starten ihn:

systemctl enable sssd.service
systemctl start sssd.service

Wir können nun z.B. durch einen Login-Versuch mittels testsaslauthd-Zugriffsversuch sowie durch “su” und “ssh” prüfen, dass für “tarja” kein Login mehr möglich ist:

mycyrus:/etc/pam.d # testsaslauthd -s login -u tarja -p TARJAPWD
0: NO “authentication failed”

und :

mycyrus:/etc/pam.d # su – tarja
su: user tarja does not exist
mycyrus:/etc/pam.d #

bzw. remote:

user@tux:~> ssh tarja@mycyrus
Permission denied (publickey,keyboard-interactive).
user@tux:~>

Dagegen:

mycyrus:/etc/pam.d # testsaslauthd -s imap -u tarja -p TARJAPWD
0: OK “Success.”
mycyrus:/etc/pam.d # testsaslauthd -s smtp -u tarja -p TARJAPWD
0: OK “Success.”

Für “smtp” funktioniert das natürlich nur, wenn man die Datei “/etc/pam.d/smtp” entsprechend – also analog zur Datei “imap” – angelegt hat.

Wir löschen nun das Verzeichnis “/home/tarja”
(soweit vorhanden). Sicherstellen müssen wir noch, dass “root” handlungsfähig ist und ins System kommt :

user@tux:~> ssh root@mycyrus
Password:
Last login: Wed Mar 12 17:50:39 2014 from tux.anraconx.de
Have a lot of fun…
mycyrus:~ #

Und nun noch:

myyrus:/etc/pam.d # testsaslauthd -u cyrus -p CYRUSPWD
0: OK “Success.”
mycyrus:/etc/pam.d #

Sieht alles OK aus. 🙂 Was haben wir erreicht ?

Die im LDAP vorhandene “tarja” wie jeder andere im LDAP hinterlegte User kann sich nicht mehr auf dem System “mycyrus” einloggen, aber “saslauthd” authentifiziert potentielle Benutzer des kommenden IMAP-Services trotzdem über den LDAP-Server! Zudem kann auch der lokale User “cyrus” auf den IMAP-Dienst zugreifen.

Unterbinden des Zugriffs auf den IMAP-Server für bestimmte User

Die oben verfolgte Politik ist bislang eine, die allen Nutzern, die im LDAP hinterlegt sind, auch einen Zugriff auf IMAP-Dienste zugesteht. Dennoch will man i.d.R. einige Benutzer explizit nicht an das IMAP-System lassen. Welche Möglichkeiten hat man dazu?

Variante 1 : “userdeny_db”
Die einfachste Variante ist eine explizite Sperre bestimmter User auf dem IMAP-System selbst. Hierzu kann man einen Liste “userdeny_db” pflegen. Mehr Informationen erhält man hierzu unter folgenden Links
http://asg.andrew.cmu.edu/archive/message.php?mailbox=archive.info-cyrus&msg=50826
http://cyrusimap.org/docs/cyrus-imapd/2.4.16/internal/database-formats.php (s. dort userdeny_db)

Variante 2 : “host”-Attribut in den LDAP-User-Einträgen setzen und auswerten
Alternativ kann man bei den User-Einträgen, die man ausschließen will, auf dem LDAP-System das Attribut “host” hinzufügen und SSSD so konfigurieren, dass dieses Feld abgefragt wird. Siehe zu Letzterem:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/config-sssd-domain-access.html

Wir gehen nachfolgend vor, wie auch im Blog-Artikel
SASL mit PAM, SSSD, LDAP unter Opensuse – II
dargestellt.

Wie man das Attribut “host” dem User-Eintrag auf dem LDAP-Server hinzufügt, wenn man den Zweig “ou=people,dc=anraconx,dc=de” ursprünglich mit YaST angelegt hatte, habe ich unter
Opensuse 12.1 – LDAP V
beschrieben. (anraconx ist hier natürlich nur eine Beispielname und durch die eigene Domain zu ersetzen).

Wir nehmen mal einen User “rmu”, der auf dem LDAP-System vorhanden sei. Ich ergänze mittels des LDAP-Tools “gq” oder eines anderen LDAP Tools wie des von ApacheDirectoryStudio die “ObjectClasses” des User-Eintrags um “extensibleObject”:

Danach füge ich dann das Attribut “host” zum Satz hinzu:

Als Wert des Feldes gebe ich dann – im Gegensatz zur Abbildung! – zunächst “mycyrus.anraconx.de” an. Ohne das “!” in der Abbildung. Zu dem “!” komme ich gleich noch. Der FQDN muss natürlich auf dem
netzwerkeigenen DNS-Server bekannt sein. (In der Praxis würde man statt mit “gq” natürlich mit LDIF-Dateien für alle betroffenen User arbeiten.)

Nun ändern wir auf “mycyrus” die Standard-SSSD-Konfiguration, die wir gem. SASL mit PAM, SSSD, LDAP unter Opensuse angelegt hatten:

[sssd]
config_file_version = 2
services = nss,pam
domains = default
 
[nss]
filter_groups = root
filter_users = root
 
[pam]
 
# Section created by YaST
[domain/default]
ldap_uri = ldap://ldap-serv.anraconx.de
ldap_search_base = dc=anraconx,dc=de
ldap_schema = rfc2307bis
id_provider = ldap
ldap_user_uuid = entryuuid
ldap_group_uuid = entryuuid
ldap_id_use_start_tls = False
enumerate = True
cache_credentials = False
ldap_tls_cacertdir = /etc/ssl/certs
ldap_tls_cacert = /etc/ssl/certs/YaST-CA.pem
chpass_provider = ldap
auth_provider = ldap
 
access_provider = ldap
ldap_access_order = host

Wichtig und neu sind lediglich die zwei letzten Zeilen. Infos zur Bedeutung der Parameter findet man hier:
http://manpages.ubuntu.com/manpages/precise/en/man5/sssd-ldap.5.html

Neustarten des sssd.service nicht vergessen:

mycyrus:~ # systemctl restart sssd.service

Dann versuchen wir eine Authentifizierung auf “mycyrus”

tux:~ # testsaslauthd -u rmu -p RMUPWD
0: OK “Success.”
mycyrus:/etc/pam.d #

Nun ändern wir den Wert auf “!mycyrus.anraconx.de” ab !
Das führt zu:

tux:~ # testsaslauthd -u rmu -p RMUPWD
0: NO “authentication failed”

mycyrus:/etc/pam.d #

Aha ! Hosts schließen wir explizit mit einem “!” aus, das dem FQDN vorangestellt wird. SSSD prüft erst auf solche Einträge, danach auf explizit freigegebene Hosts.

Lassen wir unsere sssd.conf nun wie sie ist, ist allerdings auch unsere Testuserin “tarja” auf dem “mycyrus”-System nicht mehr durch “saslauthd” authentifizierbar , wenn wir nicht bei ihr das “host”-Attribute mit “mycyrus.anraconx.de” füllen. Analog für alle anderen User. Eine mögliche Einstellung im LDAP-“host”-Attribut ist übrigens auch “allow_all“.

Variante 3 : Attribut “ldap_user_authorized_service” abfragen
Man kann aber offenbar noch feingranularer arbeiten und den Host zulassen, nicht aber eine bestimmten Service wie “imap”. Hierzu dient die Abfrage eines Attributs “ldap_user_authorized_service”. Hierzu muss auf dem LDAP-Server zusätzlich das “ldapns”-Schema geladen werden. Wie man dafür auf einem Openldap-System 2.4 vorgeht, findet man hier:
http://grungelabs.com/guides/2012/06/08/ha-openldap-debian/
http://wiki.ubuntuusers.de/OpenLDAP_ab_Precise

Ich habe das aber selbst nicht für LDAP-Server getestet, die mit YaST eingerichtet wurden. Es mag daher Inkompatibilitäten geben.

Alternativen zur LDAP-Authentifizierung

Im Blog-Beitrag
Cyrus IMAP unter Opensuse auf die Schnelle
hatte ich gezeigt, wie man die Authentifizierung für den IMAP-Zugriff auch über eine lokal gepflegte “sasldb2”-Datenbank abwickeln kann.

Genug für diesen Beitrag. Im nächsten Teil dieser Artikel-Serie
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – III
starten und testen wir dann unseren IMAP-Server.

In diesem und den folgenden Beiträgen möchte ich die Installation eines Cyrus IMAP-Dienstes beschreiben, der unter Opensuse zum Laufen gebracht werden soll und dessen Anwender über ein LDAP-System authentifiziert werden. Themen der Artikel werden sein :

1. Einfache Varianten der benötigten Konfigurationsdateien unter Berücksichtigung von SASL (genauer “saslauthd“) und STARTTLS.
2. Eine bestimmte Authentifizierungsvariante über SASLAUTHD, PAM, SSSD, LDAP. Diese ist aus meiner Sicht in einem kleinen internen Netzwerk durchaus ausreichend.
3. Test der Funktionstüchtigkeit des Authentifizierungsverfahrens.
4. Starten des Servers und Einrichten einer Test-Mailbox.
5. Prüfen der Funktionstüchtigkeit des IMAP-Servers per “telnet” und “imtest”.
6. Anbindung Kmail.
7. Webmin zur Mailbox-Verwaltung.

Einschränkung
Ich gehe in diesem Beitrag ausschließlich auf die Installation des IMAP-Dienstes auf einem Linux-Host ein. Dem Zusammenspiel mit dem MTA Postfix widme ich dagegen eine andere Artikelserie. Will man einen kompletten E-Mail-Server mit Fetchmail, Postfix, Cyrus IMAP aufbauen, lohnt es sich aus meiner Sicht aber, das Pferd von hinten aufzuzäumen:

Für Tests der gesamten Verarbeitungskette muss man letztlich in der Lage sein, E-Mails entgegen zu nehmen und abzulegen. Dafür ist ein bereits laufender IMAP-Server das richtige. Der Zugriff eines Mailclients wie Kmail auf den IMAP-Dienst ist schnell umgesetzt. Im übrigen lohnt sich der Einsatz einer “Stand Alone”-IMAP-Instanz auch für die Aufnahme von Mail aus einem Backup. Siehe hierzu den Artikel:
https://linux-blog.anracom.com/2011/11/28/cyrus-imap-auf-die-schnelle/

Getestet habe ich die gesamte Vorgehensweise auf einem System unter Opensuse 12.3. Ich gehe aber davon aus, dass die Konfiguration auch unter Opensuse 13.1 laufen würde.

Voraussetzungen: Hostkonfiguration mit SASL, PAM, SSSD und LDAP-Zugriff

Da LDAP ins Spiel kommen soll, muss der Host, auf dem der Cyrus IMAP-Dienst implementiert werden soll, eine Reihe von Voraussetzungen erfüllen. Ferner muss im Netzwerk natürlich ein LDAP-System vorhanden sein, auf den unser IMAP-Host zugreifen kann und darf. Ich kann weder die Einrichtung eines LDAP-Systems an dieser Stelle besprechen, noch die Bereitstellung aller oder spezieller Zugriffsvarianten von bestimmten Serverdiensten auf ein LDAP-System. Ich betrachte weiter unten vielmehr eine einfache, etwas spezielle Variante des LDAP-Zugriffs. Dabei werde ich bestimmte Dinge voraussetzen, die ich bereits früher in anderen Artikeln behandelt habe:

Cyrus IMAP kann (wie manche andere Dienste auch) auf das Authentifizierungs-Framework Cyrus SASL zurückgreifen. SASL wiederum kann eine ganze Reihe unterschiedlicher Backends einsetzen. In einem der letzten Beiträge in diesem Blog hatte ich bereits dargestellt, wie man eine Kette aus

SASLAUTHD => PAM => SSSD => LDAP

nutzen kann, um damit eine Authentifizierung vorzunehmen. Siehe hierzu den Blog-Artikel:
SASL mit PAM, SSSD, LDAP unter Opensuse

Die Ausführungen des genannten Beitrags werden hier vorausgesetzt. D.h., ich gehe davon aus,

• dass es einen LDAP-Server im Netz gibt, der Standard-Information zu Usern beherbergt, die einen IMAP-Zugang erhalten sollen,
• dass die Userinformationen
  auf dem LDAP-Server in einem von SuSE’s YaST eingerichteten Zweig des LDAP-Baums angelegt wurden,
• dass SASL, PAM und SSSD wie im obigen Artikel besprochen auf unserem Host “mycyrus” eingerichtet sind,
• dass Server-SSL-Zertifikate sowohl auf dem IMAP-Host wie auch auf dem LDAP-Host eingerichtet wurden und zwar jeweils nach dem Muster des SuSE “Common Server Certificates”.

Wie man unter Opensuse zu einem LDAP-Server gelangt und die Server-Zertifikate von einem CA-System auf die Server bringt, habe ich in früheren Artikeln beschrieben.
Opensuse 12.1 – LDAP I // Opensuse 12.1 – LDAP II // Opensuse 12.1 – LDAP III // Opensuse 12.1 – LDAP IV // Opensuse 12.1 – LDAP V

Host-, Server- und Testuser-Bezeichnungen in den Artikeln dieser Serie

Der Host, der den IMAP-Server beherbergen soll, heiße nachfolgend “mycyrus“. Der LDAP-Server heiße dagegen “ldap-serv“.
Auf dem LDAP-System sei ferner ein Eintrag für eine Test-Userin “tarja” angelegt worden (Password: TARJAPWD).

Benötigte CYRUS IMAP Pakete

Unter Opensuse installiert man sich per YaST oder Yum folgende Pakete aus den Standard- und Update-Repositories für sein Opensuse-System:

cyrus-imapd, cyrus-sasl, cyrus-sasl-plain, cyrus-sasl-saslauthd, perl-Cyrus-IMAP, perl-Cyrus-SIEVE-managesieve,
perl-Authen-SASL-Cyrus, perl-Authen-SASL

CYRUS IMAP Konfigurationsdateien

Meine Cyrus Konfigurationsdateien sehen wie folgt aus:

/etc/cyrus.conf:

# standard standalone server implementation
 
START {
# do not delete this entry!
recover cmd=”ctl_cyrusdb -r”
 
# this is only necessary if using idled for IMAP IDLE
idled cmd=”idled”
}
 
# UNIX sockets start with a slash and are put into /var/lib/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd=”imapd” listen=”imap” prefork=0
imaps cmd=”imapd -s” listen=”imaps” prefork=0
pop3 cmd=”pop3d” listen=”pop3″ prefork=0
pop3s cmd=”pop3d -s” listen=”pop3s” prefork=0
sieve cmd=”timsieved” listen=”sieve” prefork=0
 
# at least one LMTP is required for delivery
# lmtp cmd=”lmtpd” listen=”lmtp” prefork=0
lmtpunix    cmd=”lmtpd” listen=”/var/lib/imap/socket/lmtp” prefork=0
 
# this is only necessary if using notifications
# notify cmd=”notifyd” listen=”/var/lib/imap/socket/notify” proto=”udp” prefork=1
}
 
EVENTS {
# this is required
checkpoint cmd=”ctl_cyrusdb -c” period=30
 
# this is only necessary if using duplicate delivery suppression
delprune cmd=”cyr_expire -E 3″ at=0400
 
# this is only necessary if caching TLS sessions
tlsprune cmd=”tls_prune” at=0400
 
# Uncomment the next entry, if you want to automatically remove
# old messages of EVERY user.
# This example calls ipurge every 60 minutes and ipurge will delete
# ALL
messages older then 30 days.
# enter ‘man 8 ipurge’ for more details
 
# cleanup cmd=”ipurge -d 30 -f” period=60
}

Details zu den Parametern findet man etwa hier: http://linux.die.net/man/5/cyrus.conf.
Diese Datei ist nach der Installation unter Opensuse fast schon genau so vorhanden wie oben dargestellt. Geändert habe ich, dass die Bereitstellung der IMAP und POP-Dienste auch auf verschlüsselten Ports (imaps: 993, pop3s: 995) erfolgen soll.

Wichtig ist die Vorbereitung der LMTP-Socket-Kommunikation innerhalb des Blockes SERVICES {} dann, wenn man später Postfix als MTA einsetzt will: Postfix kann seine Mails lokal auf demselben System (Socket !) per LMTP-Protokoll an den Cyrus-IMAP -Server und dessen Mailboxen übergeben. Beachte: Die LMTP-Socket-Bereitstellung wird durch die gestartete Cyrus IMAP-Instanz selbst vorgenommen. Es ist keine zusätzliche Paketinstallation erforderlich. (In der Postfix-Konfiguration muss dann allerdings auch genau auf den hier angegebenen Socket Bezug genommen werden.)

Wichtig für die Authentifizierung im Rahmen eines User-Zugriffs auf den IMAP-Dienst ist folgende Konfigurationsdatei für den IMAP-Dämon:

/etc/imapd.conf:

# Configuration
# ************
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
sievedir: /var/lib/sieve
 
servername: mycyrus
admins: cyrus
 
reject8bit: no
poptimeout: 10
timeout: 30
 
# DRAC
# ******
drachost: localhost
dracinterval: 0
 
# Quota und Autocreate
# ******************
quotawarn: 90
autocreatequota: 5242880
autocreateinboxfolders: Drafts|Sent|Trash|Junk|Spam
autosubscribeinboxfolders: Drafts|Sent|Trash|Junk|Spam
 
# LMTP
# ****
lmtp_overquota_perm_failure: no
lmtp_downcase_rcpt: yes
 
# SASL
# ****
allowplaintext: yes
sasl_pwcheck_method: saslauthd
sasl_mech_list: PLAIN LOGIN
 
# TLS (STARTTLS)
# *************
tls_key_file: /etc/ssl/servercerts/serverkey.pem
tls_cert_file: /etc/ssl/servercerts/servercert.pem
tls_ca_file: /etc/ssl/certs/YaST-CA.pem

Genauere Informationen zu den einzelnen Parametern findet man unter den man-Seiten:
http://linux.die.net/man/5/imapd.conf.
Oder hier: http://www.postfix-howto.de/v1/cyrus_conf.html
Ich gehe kurz auf einige der wichtigeren Einträge ein:

Drac deaktivieren
DRAC realisiert “pop/imap before smtp” unter Cyrus IMAP. Das wird hier nicht benötigt und durch “dracinterval: 0” deaktiviert.

Nutzung von SASL für die Authentifizierung
Cyrus IMAP nutzt das SASL-Framework zur Authentifizierung allein aufgrund der 3 Zeilen unter meiner Kommentarzeile “# SASL”. Dabei werden eingehende Klartext-Passwörter zugelassen.
Dass der “saslauthd”-Dämon PAM nutzen soll, wird durch saslauthd’s eigene Startup-Dateien auf dem Host geregelt. Beschrieben habe ich das in meinem oben zitierten Blog-Beitrag SASL mit PAM, SSSD, LDAP unter Opensuse . Dort findet man auch,

• wie man PAM zur Nutzung von SSSD einstellen muss und
• wie man SSSD konfigurieren muss, damit ein LDAP-Server als Auth-Backend über eine TLS-gesicherte Verbindung genutzt werden kann.

Bereitstellung von STARTTLS für den sicheren Zugang zum IMAP-Dienst
Um das potentielle Sicherheitsloch mit den Klartext-Passwörtern zu kompensieren, soll der Cyrus-Server TLS-Verschlüsselung für Clients anbieten (STARTTLS). Dies
geschieht über die Einträge unterhalb meiner “# TLS”-Kommentarzeile.

Wie gesagt: Die host-spezifischen TLS/SSL-Schlüssel-Dateien sind von einer zentralen YaST-CA erstellt worden. Die zugehörigen Dateien wurden exportiert und auf “mycyrus” als “Common Server Certificate” importiert. Dann landen die Schlüssel-Dateien mit den angegebenen Standard-Namen und passenden Rechten in den angegebenen Verzeichnissen.

Wichtig ist, die Datei “YaST-CA.pem” der eigenen CA für SSL/TLS gesicherte Verbindungen auch auf allen späteren IMAP-Clients im eigenen Netzwerk bereitzustellen – und dort unter dem jeweiligen Verzeichnis “/etc/ssl/certs” (Opensuse-spezifisches Standard-Verzeichnis). Diese Datei wird später auf den Clients für die Prüfung der Vertrauenswürdigkeit des Zertifikats benötigt. (Natürlich kann es sein, dass die öffentliche Zertifikatsdatei für die eigene oder eine externe CA einen anderen Dateinamen als YaST-CA.pem aufweist. Unter anderen Linux-Distributionen ist ggf. auch ein anderer Pfad zu wählen, an den dann die Einstellungen in der imapd.conf anzupassen sind.)

Modifizierte Anzeige des Posteingangs
Die Mailverzeichnisse des Cyrus IMAP-Servers sind hierarchisch aufgebaut. Unter “/var/spool/imap/user” werden wir später für unsere Testuserin “tarja” explizit Mail-Verzeichnisse anlegen. Das Verzeichnis für den Posteingang ist dabei im Filesystem identisch mit “/var/spool/imap/user/tarja”. IMAP-intern wird die Mailbox unter “user.tarja” verwaltet. Unter diesem Knoten werden dann typische weitere Subverzeichnisse für “Drafts”, “Spam”, “Sent” etc. angelegt. Mail Clients wie Kmail zeigen diese Hierarchie an Mailfoldern auch genauso an. Mich stört dabei regelmäßig die übergeordnete Rolle des Posteingangs. Um das (spezielle) Posteingangsverzeichnis auf der gleichen Ebene wie die eigentlich untergeordneten Ordner anzeigen zu lassen, nutzt man die Option

altnamespace: yes

Quota und Autocreate-Optionen
Der aufmerksame Leser mag sich über die automatische Quota-Zuteilung von 5GB an neue User wundern. (Der numerische Wert von “autocreatequota” bezieht sich auf die Einheit KB). Würde er die User kennen, die sich auf meinem System tummeln werden, würde er sich nicht mehr wundern. Aber hier muss jeder selber wissen, was er sich und seinen Usern zugestehen will.
Zu den Autocreate-Optionen für die automatische Anlage neuer Verzeichnisse bei Posteingang für User, für die bislang noch keine Mailbox angelegt wurde, und zu den erforderlichen Voraussetzungen für die automatische Anlage muss ich auf die Literatur verweisen.

Ein paar Checks und Vorbereiten des “cyrus”-Users

Wir prüfen vorab, dass folgende Services ordnungsgemäß gestartet sind und fehlerfrei laufen:

• systemctl status saslauthd.service
• systemctl status sssd.service

Beide Services sollten für den automatischen Start durch systemd auf dem IMAP-Server bereits “enabled” sein oder spätestens jetzt werden.

Ferner testen wir, wie im früheren Beitrag beschrieben, dass “saslauthd” im Kern funktioniert.

mycyrus:/etc/init.d # testsaslauthd -u tarja -p TARJAPWD
0: OK “Success.”
mycyrus:/etc/init.d #

Ferner prüfen wir, ob ein Login auf dem System “mycyrus” für “tarja” möglich ist – z.B. über ssh von einem Remote-System; SSH muss dafür auf “mycyrus” aktiviert sein. Der Login ist möglich, wenn man auf “mycyrus” alles so eingerichtet hat, wie ich das im oben zitierten Artikel SASL mit PAM, SSSD, LDAP unter Opensuse vorgegeben hatte:

user@tux:~> ssh -X tarja@mycyrus
Password:
Last login: Wed Mar 12 18:21:16 2014 from tux.anraconx.de
nHave a lot of fun…
tarja@mycyrus:~>

Passwort und TLS-Gruppe für den User “cyrus” setzen
Der User “cyrus” wurde zwar bei der IMAP-Installation automatisch als Mitglied der Gruppe “mail” angelegt. Aber wir sollten nun sein Passwort mit einem Tool unserer Wahl (z.B. YaST oder usermod) setzen. Der Platzhalter für das “cyrus”-Passwort ist nachfolgend CYRUSPWD.

Zudem: Sowohl dieser User “cyrus” als später auch der User “postfix” benötigen für TLS den lesenden Zugang zum privaten SSL-Key. Ich will diese User aber natürlich nicht der root-Gruppe zuordnen. Mein Lösungsansatz ist, eine Gruppe “tls” einzurichten, der auf dem IMAP-Server nur die User “cyrus” und “postfix” angehören. Ich setze dann die Rechte wie folgenden Zeilen entnehmbar:

mycyrus:/etc/ssl/servercerts # ls -l
total 8
-rw-r–r– 1 root root 1809 Jan 18 15:03 servercert.pem
-rw-r—– 1 root tls 1704 Jan 18 15:03 serverkey.pem

Damit genug für den ersten Artikel dieser Serie. Was haben wir bis jetzt erreicht? Wir haben bislang nur Konfigurationsdateien vorbereitet und gecheckt, dass für eine Testuserin eine saslauthd-basierte Authentifizierung über einen LDAP-Server funktioniert. Leider kann sich unsere Testuserin auf dem geplanten IMAP-Server-Host auch einloggen. Wollen wir das? Klare Antwort: Nein ! Im nächsten Beitrag
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – II
müssen wir daher die Grundeinstellungen des Authentifizierungsverfahrens zuerst noch etwas modifizieren.