• Heiko Schlittermann hs@schlittermann.de 2017.10.25 12:58:

Question: Is there any way to split the authentication from the authorization within common mail clients (as Thunderbird) in combination with Dovecot. That is, doing something like logging in to the account sales@example.com, using the credentials of the very own account (say hans@example.com)?

Hi,

wouldn't this be a use case for acl_groups, where a user would belong to group "Sales" and this "role" would gain specific access?

Regards Thomas

Hi,

On Wed, 25 Oct 2017, Heiko Schlittermann wrote:

given a small organization. There are *personal* mailboxes (mailbox per user, incl. subfolders et cetera). The users can share specic folders via the ACL (we call it "other users/", Dovecot calls it "shared" folder. Additionally there are mailboxes Dovecot calls "public" (we use the term "groups/"). They are not associated with a specific account, but acessible via ACL only. (Good example for the latter is "info@example.com")

But now they're seeking for a way to implement "role" Accounts.

We could create new "role" users, share the password and create an additional account within the mail client (thunderbird) they use. From users perspective it is exactly what they want. But I dislike the idea of sharing the password.

Question: Is there any way to split the authentication from the authorization within common mail clients (as Thunderbird) in combination with Dovecot. That is, doing something like logging in to the account sales@example.com, using the credentials of the very own account (say hans@example.com)?

We faced the same problem and solved it with a PAM module:

https://gitlab.kfki.hu/kadlec/pam-groupuser

Any kind of MUA are supported with whatever background authentication you have. Here follows the README:

This tiny PAM module makes possible to authenticate to group user accounts, where

• the group user has got an own group with the same name as its username
• the group members are real users, who want to access the resources (email, files) of the group user

The pam_groupuser.so module must be referred two times in the PAM configuration for the given service/resources, i.e.

auth required pam_groupuser.so <all normal auth modules> auth required pam_groupuser.so second-pass

The users must use the username "groupusername*realusername" and the password belonging to "realusername". The first call to pam_groupusers.so sets the username for PAM to "realusername", so the authentication modules will use the real username for authentication. The second call to pam_groupusers.so sets the username for PAM to "groupusername", so the account and session environment is set up according to groupusername.

The applications which supports this kind of setups:

• dovecot POP/IMAP server
• vsfptd FTP server

Addendum: for dovecot, add "*" to the allowed username chars to auth_username_chars in /etc/dovecot/conf.d/10-auth.conf.

Best regards, Jozsef

E-mail : kadlecsik.jozsef@wigner.mta.hu PGP key: http://www.kfki.hu/~kadlec/pgp_public_key.txt Address: Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary

On 10/25/2017 12:58 PM, Heiko Schlittermann wrote:

We could create new "role" users, share the password and create an additional account within the mail client (thunderbird) they use. From users perspective it is exactly what they want. But I dislike the idea of sharing the password.

For what reason exactly? It not being personalized, too easy to leak, potentially not expiring ever, ... ?

dovecot can take the "username" from a client certificate used in the connection (default is to use the CN of it). Based on that, you could give user A (actual wetware using Thunderbird) a client cert with an appropriately limited validity period and a DN of, say, "CN=userB, OU=userA, ..." to use for logging in as userB. Within Thunderbird, that cert+key would be exactly as safe as the cert+key userA uses for S/MIME

• read, "usually considered safe enough". ;-)

I seem to remember that at least some of the userdb backends dovecot supports allow to have *several different* passwords stored for userB, too ... (But that would probably imply that you cannot allow userB to change "the" password themselves.)

(For actual group access rights userA->userB *within* dovecot, I'll have to refer you to others' replies.)

Kind regards,

Jochen Bern Systemingenieur

Fon: +49 6151 9067-231 Fax: +49 6151 9067-290 E-Mail: jochen.bern@binect.de

www.binect.de www.facebook.de/binect

Binect ist ausgezeichnet: Sieger INNOVATIONSPREIS-IT 2017 | Das Büro: Top 100 Büroprodukte 2017

Binect GmbH

Robert-Koch-Straße 9, 64331 Weiterstadt, DE

Geschäftsführung: Dr. Frank Wermeyer, Nils Manegold Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 94685 Umsatzsteuer-ID: DE 221 302 264

MAX 21-Unternehmensgruppe ✁ Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge an dieser Nachricht durchzuführen. Wir schließen, außer für den Fall von Vorsatz oder grober Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch virenbefallene Software oder E-Mail aus.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of contents of this e-mail is strictly prohibited. All Binect GmbH emails are created thoroughly, nevertheless we do not accept any legal obligation for the information and wording contained herein. Binect GmbH has taken precautionary measures to reduce the risk of possible distribution of virus infected software or emails. However, we advise you to check attachments to this email for viruses. Except for cases of intent or gross negligence, we cannot accept any legal obligation for loss or damage by virus infected software.