Samba 3.0.7 OpenLDAP 2.1.25 When winbind idmaps are imported into LDAP from an existing winbindd_idmap.tdb file, the range configured in smb.conf must cover the range previously existing in the .tdb file (e.g. 'idmap uid = 10000-20000'; 'idmap gid = 10000-20000'). When new idmap uids and gids are created, following the creation of new users or groups, these uids and gids are created inside the existing range which means that dublicate entries can be created in LDAP. The dublicate entries mean that Winbind user- and groupnames cannot be resolved. Winbindd should check properly for existing gidnumber/uidnumber in LDAP before creating a new entry. The samba LDAP-schema should be modified so that gidnumber/uidnumber is guaranteed to be unique.
Turned out to be a case of UNFPD (User Not Finding Proper Documentation). Next available uidNumber and gidNumber is taken from the uidNumber & gidNumber attributes of the Idmap ou, e.g. ldapsearch -xLLL "(objectclass=sambaunixidpool)" dn: ou=Idmap,dc=department,dc=company,dc=com objectClass: top objectClass: organizationalUnit objectClass: sambaUnixIdPool ou: Idmap description: Winbind Idmap uidNumber: 15002 gidNumber: 15003 These attributes are updated, as they should be, when you add a new user or group and this user or group is used by winbindd (e.g. for assigning an ACL). However, when you load users and groups from a previously used winbindd_idmap.tdb file, the above attributes are NOT updated and you will get the problem described in this bug-report, if you do not update them 'manually'. You can (sort of) obtain this information from p.406 (CHAPTER 30. UPGRADING FROM SAMBA-2.X TO SAMBA-3.0.0 in "Samba Project Documentation 2003"), where 'sambaUNIXIdPool' is described.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.