When trying to add a groupmap entry for a unix group that already has a
groupmap entry I get the following
error "ldapsam_add_group_mapping_entry: Group 3 already exists in LDAP"
I can reproduce this with rc1 to rc4
It does not happen if use tdb backend, is ldap backend supposed to be
I am running mandrake samba3 packages thus net3 instead of net.
John H Terpstra in an email to samba list said *
"You can not have more than one NT Domain Group per UNIX Group.
But you can have more than on NT Local Group per UNIX group.
net groupmap add ntgroup="Flying Pigs" unixgroup=sys type=l"
so I assume ldap behaviour is wrong.
Commands entered below
[root@server01 samba3]# net3 groupmap list
Administrators (S-1-5-21-1617713866-2789119093-1479812082-512) -> root
Backup Operators (S-1-5-32-551) -> bin
Replicators (S-1-5-21-1617713866-2789119093-1479812082-1005) -> daemon
Power Users (S-1-5-32-547) -> sys
Print Operators (S-1-5-32-550) -> lp
Domain Admins (S-1-5-21-1617713866-2789119093-1479812082-21003) -> ntadmin
Staff (S-1-5-21-1617713866-2789119093-1479812082-22001) -> staff
Accounts (S-1-5-21-1617713866-2789119093-1479812082-22005) -> accounts
Family (S-1-5-21-1617713866-2789119093-1479812082-22007) -> family
Domain Guests (S-1-5-21-1617713866-2789119093-1479812082-514) -> nogroup
[root@server01 extract]# net3 groupmap add ntgroup=test unixgroup=sys
[2003/09/14 20:14:36, 0]
ldapsam_add_group_mapping_entry: Group 3 already exists in LDAP
adding entry for group test failed!
The code in passdb/pdb_ldap.c is I would guess supossed to give this
error but it is not consistent with tdb backend.
*** This bug has been marked as a duplicate of 905 ***
should not have been closed. It was an accident.
"It does not happen if use tdb backend, is ldap backend supposed
to be different?"
Yes. LDAP is different. entries can be replaced with no
trouble in a tdb while the code to add an entry to LDAP
is different than the code to modify an entry.
I look into changing the tdb behavior.
just checked the current 3.0 code and both tdb and ldap work
in the same fashion.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.