dovecot - Oct 2017 - authenticate as userA, but get authorization to user userB's account

Hello,

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 at
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 at example.com, using the credentials of the very own account
(say hans at example.com)?

- how to do it in Dovecot? (We use LDAP)
- how to set up this in Thunderbird?
- how to set up this in a generic MUA, as some webmail client?

Thanks in advance,

    best regards from Dresden/Germany
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --------------- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20171025/bbe7baa7/attachment.sig>

* Heiko Schlittermann <hs at 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 at example.com, using the credentials of the very own account
> (say hans at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20171025/d5c916dd/attachment.sig>

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 at 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 at example.com, using the credentials of the very own account (say 
> hans at 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 at 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

Thomas Leuxner <tlx at leuxner.net> (Mi 25 Okt 2017 13:11:52 CEST):
?
> * Heiko Schlittermann <hs at schlittermann.de> 2017.10.25 12:58:
> 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?
Not sure. Because userA wants to "impersonate" as userB. In
Thunderbird
this is associated with an per-account set of options (Sent folder, sync
policy, identites used for sending, etc pp).

Using ACLs I can access that other mailbox, but that's it.
I still have to take care about my identity when sending mails, and any
mail sent is not stored in userB's folders, but in mine.

    Best regards from Dresden/Germany
    Viele Gr??e aus Dresden
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --------------- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20171025/a340329b/attachment-0001.sig>

Hello J?zsef,

thanks for your super-fast response.

Kadlecsik J?zsef <kadlecsik.jozsef at wigner.mta.hu> (Mi 25 Okt 2017
13:28:22 CEST):
> > sales at example.com, using the credentials of the very own account
(say
> > hans at example.com)?
> 
> We faced the same problem and solved it with a PAM module:
?
> The users must use the username "groupusername*realusername" and
the
Yes, this follows the maser-user idea. Great.
I'm curious if the master user mechanism isn't usable.
Maybe it is, I'll check this.
> - 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.
I think, it's there already for the master user mechanism.
I'll send a follow-up on how I solved it, if I do not get any further input.

    Best regards from Dresden/Germany
    Viele Gr??e aus Dresden
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --------------- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20171025/55d2940b/attachment.sig>

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 at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20171025/7cb693d3/attachment.p7s>

Jochen Bern <Jochen.Bern at binect.de> (Mi 25 Okt 2017 14:44:26 CEST):
?
> > 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, ... ?
If some of the users isn't allowed to access that "role" account
anymore, then I've to "revoke" the old password and to re-issue a
new
one to the lefterover members for that role.
> dovecot can take the "username" from a client certificate used in
the
?

Client certificates are no option currently, as it is difficult to
maintain and probably not compatible with a broader range of MUAs.

?
> 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.)
That brings some other idea: We use LDAP authentication. It is possible
to have multiple (how many?) userPassword fields per LDAP object. If we
are able to track the password hashes (which hash for which user), we
can have each user using his very own password to login as another user
(provided that other user has an additional userPassword field)
 
    Best regards from Dresden/Germany
    Viele Gr??e aus Dresden
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --------------- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20171025/f5c643a1/attachment.sig>