[Dovecot] ldap: LDAP attribute used multiple times. This is currently unsupported

[Lukas Haase]

Dear Timo,

Thank you for your advice!

Am 08.02.2011 18:35, schrieb Timo Sirainen:
> On 8.2.2011, at 17.23, Lukas Haase wrote:
>>[...]
>>
>> I know, but the message is somehow "weird" since it says it is
>> *currently* unsupported. However, it seems to me that it is not
>> supported any more. Is this true? Is there a reason for this?
>
> I'm pretty sure it never worked. I think in v1.0 it simply ignored
> the first uid=user. So you could probably just remove that.

Unfortunately not. I am really sure it worked in v1.0. For example:

# id luke
uid=1000(luke) gid=100(users) 
groups=51683(family),25783(ssh_users),63315(projects),19580(multimedia),1019(data),51684(friends),100(users)

So luke's *primary* group is "users" but he is also member of the other 
groups (like "family").


An IMAP folder in my shared namespace has permissions as follows:

# ls -la /var/mail/shared
[...]
drwxrwx---  5 root family 4096 Feb  8 22:53 .Family
[...]

So the folder "Family" in the shared namespace is *not* accessible in 
the *default* configuration since the directory is not accessible by the 
group "users" but only by the group "family". And in the default 
configuration the groups are ignored by dovecot (except the primary group).

In Debian Lenny (dovecot 1.xx) I set "uid=system_user" in the 
"user_attrs" setting of my ldap config. According to the Wiki, this 
should read out the primary groups of the user contained in the LDAP 
field "uid". And this worked: I could access the folder.

Now I upgraded to Debian sequeeze (dovecot 1.2) and I get the mentioned 
error message. So I am somehow sure that it actually worked and was not 
just ignored.

Nevertheless, is there a way to overcome this issue? Can dovecot just 
read out the group membership from the "user" field of "pass_attrs"?

Another obvious solution would be to define a manual scheme with a 
manual attribute "uid_dovecot" and copy the value of "uid". But this 
seems to me like a using a sledgehammer method since it provides 
unnecessary redundancy in the LDAP tree (where the increased complexity 
might cause problems and inconsistencies) and requires defined a manual 
LDAP scheme.

Any solution would be greatly appreciated!

Best regads,
Luke