authenticate as userA, but get authorization to user userB's account

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

authenticate as userA, but get authorization to user userB's account

Heiko Schlittermann
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 "[hidden email]")

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 [hidden email], using the credentials of the very own account
(say [hidden email])?

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

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: authenticate as userA, but get authorization to user userB's account

Thomas Leuxner
* Heiko Schlittermann <[hidden email]> 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 [hidden email], using the credentials of the very own account
> (say [hidden email])?

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

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: authenticate as userA, but get authorization to user userB's account

Kadlecsik József
In reply to this post by Heiko Schlittermann
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
> "[hidden email]")
>
> 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
> [hidden email], using the credentials of the very own account (say
> [hidden email])?

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 : [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: authenticate as userA, but get authorization to user userB's account

Heiko Schlittermann
In reply to this post by Thomas Leuxner
Thomas Leuxner <[hidden email]> (Mi 25 Okt 2017 13:11:52 CEST):

> * Heiko Schlittermann <[hidden email]> 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 ------------ -

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: authenticate as userA, but get authorization to user userB's account

Heiko Schlittermann
In reply to this post by Kadlecsik József
Hello József,

thanks for your super-fast response.

Kadlecsik József <[hidden email]> (Mi 25 Okt 2017 13:28:22 CEST):
> > [hidden email], using the credentials of the very own account (say
> > [hidden email])?
>
> 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 ------------ -

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: authenticate as userA, but get authorization to user userB's account

Kadlecsik József
On Wed, 25 Oct 2017, Heiko Schlittermann wrote:

> Kadlecsik József <[hidden email]> (Mi 25 Okt 2017 13:28:22 CEST):
> > > [hidden email], using the credentials of the very own account (say
> > > [hidden email])?
> >
> > 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.

The master users are allowed to impersonate anyone and at the same time
cannot login as themselves. Those were the issues why we couldn't choose
to use master users.
 
Best regards,
Jozsef
--
E-mail : [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: authenticate as userA, but get authorization to user userB's account

Jochen Bern-2
In reply to this post by Heiko Schlittermann
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: [hidden email]

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.


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: authenticate as userA, but get authorization to user userB's account

Heiko Schlittermann
In reply to this post by Kadlecsik József
Kadlecsik József <[hidden email]> (Mi 25 Okt 2017 14:42:11 CEST):

> The master users are allowed to impersonate anyone and at the same time
> cannot login as themselves. Those were the issues why we couldn't choose
> to use master users.

True.
--
Heiko

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: authenticate as userA, but get authorization to user userB's account

Heiko Schlittermann
In reply to this post by Jochen Bern-2
Jochen Bern <[hidden email]> (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 ------------ -

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: authenticate as userA, but get authorization to user userB's account

Steffen Kaiser-9
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 25 Oct 2017, Heiko Schlittermann wrote:
> Jochen Bern <[hidden email]> (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.
...

I didn't seen that someone mentioned user sharing via ACLs.

> 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)

Yeah, something like this should work (never tested in this full outline),
let's say:

1) you create a new account for the role, "role",
2) you create a new virtual account for each member of the role
(Funktionsträger), "user/role",
3) using passdb queries, you associcate "user/role" with "user"'s
password, but returning "role"'s user id as Extra Field

Because the returning Extra Fields are independed on how the query
matched, you need one virtual account (actually doing the mapping of login
credentials to Dovecot user, which is the role account) per human
impersonating the role.
The mechanism is the same, as if you map mail addresses to account names
a.s.o

However, I have no knowledge, if you can use attribute aliases to have
both LDAP account "user/role" and "user" *share* the same userPassword
attribute in the "user" account preferrly; or if you need to copy the
userPassword from "user" to "user/role" now and then.

To create the virtual mapping entries in LDAP (step 2) ), you should
utilize a database of some sorts with scripts to automatically create /
delete them.

Then, your role user can login with:

user/role
user's password

Dovecot logs should contain the passdb query of "user/role", then Dovecot
logs would contain "role", because you map the account name. But using the
pid of the Dovecot IMAP process, you should be able to still know, to whom
a particular Dovecot session belogs to.

- --
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBWfGMz3z1H7kL/d9rAQJQFgf/X14PuOr7mwxWJDpmBtaRs1+yBPO0zQob
ttZ3A6AM/Z7bLrc3vf4A0K7C8Vq5eOcFLeJJzweZbxlwBbTr3LGeZ2UYp7Z2NOP+
P59uUrCMMWb7uG2d8kps5pubCV19wEt67w4r+b+43rke38W5o4fu8shx/Fj+/QPF
RINqC4KonY4EpANKYnfaU9O5ArnPyg9FIBw8tq8RAgYBrim2NLHBHDEHtKpoCk5T
O+k/oiwd93K1wtv6Os7Z+dR7h35v6LYCSoj1/jp+FjWIuuL+IgB9rxDvQRP+r6CD
6uIHXde+vtVIguCF15nw9rnb07NyQWx4U2PEpANVfIgf7sloVT9B4Q==
=APAB
-----END PGP SIGNATURE-----