dovecot - Feb 2006 - Broken NSS Implementation

We're getting this error when IMAP clients attempt to authenticate using 
their aliases rather than their actual username:

Feb ... dovecot: auth(default): BROKEN NSS IMPLEMENTATION: getpwnam() 
lookup returned different user than was requested (campbellmckilligan != 
campbell.mckilligan).
Feb  ... dovecot: imap-login: Internal login failure: 
user=<campbell.mckilligan>, method=plain, rip=82.148.120.110, 
lip=172.20.2.2, TLS
Feb  ... dovecot: child 27345 (auth) returned error 89

For historic reasons, there is no consistency with which username in 
individuals mail client.  NSS correctly returns the name that dovecot 
should use for the purposes of accessing mailboxes etc.

Dovecot-0.99.14 worked fine in this regard - but since upgrading to 
1.0beta3 we have this problem.  It's running on a Fedora Core 4 server.  
It compiled fine with selinux enabled.

Is there a switch to control the response to this NSS behaviour?

Any help appreciated.

Campbell

On 8.2.2006 22:50, "Campbell McKilligan"
<campbell.mckilligan at daedoha2006.com> wrote:
> We're getting this error when IMAP clients attempt to authenticate
using
> their aliases rather than their actual username:
> 
> Feb ... dovecot: auth(default): BROKEN NSS IMPLEMENTATION: getpwnam()
> lookup returned different user than was requested (campbellmckilligan !>
campbell.mckilligan).
> Feb  ... dovecot: imap-login: Internal login failure:
> user=<campbell.mckilligan>, method=plain, rip=82.148.120.110,
> lip=172.20.2.2, TLS
> Feb  ... dovecot: child 27345 (auth) returned error 89
> 
> For historic reasons, there is no consistency with which username in
> individuals mail client.  NSS correctly returns the name that dovecot
> should use for the purposes of accessing mailboxes etc.
> 
> Dovecot-0.99.14 worked fine in this regard - but since upgrading to
> 1.0beta3 we have this problem.  It's running on a Fedora Core 4 server.
> It compiled fine with selinux enabled.
> 
> Is there a switch to control the response to this NSS behaviour?
Well, you could simply remove the check from src/auth/userdb-passwd.c.
Perhaps I could make this also optional. I'd anyway not want to remove that
check completely because nss_ldap is still not fixed.