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

[Steffen Kaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 25 Oct 2017, Heiko Schlittermann wrote:
> 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.
...

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