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)"
description: Winbind Idmap
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.