Re: authenticate as userA, but get authorization to user userB's account
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 25 Oct 2017, Heiko Schlittermann wrote: Jochen Bern (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-
Re: authenticate as userA, but get authorization to user userB's account
Jochen Bern (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
Description: PGP signature
Re: authenticate as userA, but get authorization to user userB's account
Kadlecsik József (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 Description: PGP signature
Re: authenticate as userA, but get authorization to user userB's account
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.b...@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. smime.p7s Description: S/MIME Cryptographic Signature
Re: authenticate as userA, but get authorization to user userB's account
On Wed, 25 Oct 2017, Heiko Schlittermann wrote: > Kadlecsik József (Mi 25 Okt 2017 13:28:22 > CEST): > > > sa...@example.com, using the credentials of the very own account (say > > > h...@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. 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 : kadlecsik.joz...@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
Re: authenticate as userA, but get authorization to user userB's account
Hello József,
thanks for your super-fast response.
Kadlecsik József (Mi 25 Okt 2017 13:28:22
CEST):
> > sa...@example.com, using the credentials of the very own account (say
> > h...@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 -
signature.asc
Description: PGP signature
Re: authenticate as userA, but get authorization to user userB's account
Thomas Leuxner (Mi 25 Okt 2017 13:11:52 CEST):
…
> * Heiko Schlittermann 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
Description: PGP signature
Re: authenticate as userA, but get authorization to user userB's account
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 > "i...@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 > sa...@example.com, using the credentials of the very own account (say > h...@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 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.joz...@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
Re: authenticate as userA, but get authorization to user userB's account
* Heiko Schlittermann 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 sa...@example.com, using the credentials of the very own account > (say h...@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 signature.asc Description: PGP signature
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 "i...@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 sa...@example.com, using the credentials of the very own account
(say h...@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 -
signature.asc
Description: PGP signature
