samba - Mar 2004 - getpwnam() fails! (with working nss_ldap setup)

Hi list,
I've seen this error now many times (at my own setup and in the
archives):

  sam_account_ok: Checking SMB password for user Simon Dassow
[2004/03/05 12:54:19, 1] auth/auth_util.c:make_server_info_sam(821)
  User Simon Dassow in passdb, but getpwnam() fails!

But:
# id 'Simon Dassow'
uid=1000(Simon Dassow) gid=513(Domain Users) groups=513(Domain Users),
512(Domain Admins)

nss_ldap _is_ working... to verify this from another place (i'm using
FreeBSD so there is no getent):
# perl -e 'print join(" - ",getpwnam("Simon
Dassow"))."\n"'
Simon Dassow - x - 1000 - 513 - 0 -  - Simon Dassow - /home/dasi -
/usr/local/bin/zsh - 0

If i logon with an `normal' unix account that has been added via
`smbpasswd -a user' everything is working. Maybe someone has a hint for
me.

And before i forgot, that's my setup:
FreeBSD 5.2.1 with nss_ldap (and yes, i have ldap in /etc/nsswitch.conf)
OpenLDAP 2.0.27
Samba 3.0.1
smbldap-tools 0.8.4

Any help is appreciated.

Regards,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.samba.org/archive/samba/attachments/20040305/bd837c26/attachment.bin

I have the same experience.
IMHO problem is in access rights to password attributes on ldap (slapd).
Recomended access to userPassword for anonymous is only auth (it's right
policy). Recommended configuration of  nss_ldap is to use anonymous bind for
non-root processes (and it is also right policy). Then when getpwnam() is
called by unprivileged process and nss_ldap try to read attribute
userPassword among others from posixAccount, this must be unsuccessfull
attempt (and it is right but wrong to me).
What to do ? I think, it is mistake in nss_ldap behaviour. It must omit
userPassword attribute from readed attributes when called by nonprivileged
process.
My solution is simple, but wrong - weaken of access restrictions to password
attribute or bind to ldap as "manager" for all users.

M. Vancl