Test :

/usr/local/samba/bin# ./net groupmap list
domadm (S-1-5-21-3746524048-3196343125-3229652583-512) -> domadm
test (S-1-5-21-3746524048-3196343125-3229652583-520) -> newdomadm
opuspdc1:/usr/local/samba/bin# ./net groupmap modify
sid=S-1-5-21-3746524048-3196343125-3229652583-512 unixgroup=newdomadm
Updated mapping entry for
/usr/local/samba/bin# ./net groupmap list
domadm (S-1-5-21-3746524048-3196343125-3229652583-512) -> domadm
domadm (S-1-5-21-3746524048-3196343125-3229652583-512) -> newdomadm

The result of this command is unexpected ! Here is what (I think) happens :

- First, the command doesn't check for the existence of a mapping involving
newdomadm -> we should get an error here (same error as in bug #1017)

- Second, net_groupmap.c/net_groupmap_modify looks for the mapping using
the SID (it finds S-1-5-21-3746524048-3196343125-3229652583-512/domadm) and
modifies it in memory (to get
S-1-5-21-3746524048-3196343125-3229652583-512/newdomadm). BUT, when the
mapping is to be stored in LDAP via
pdb_ldap.c/ldapsam_update_group_mapping_entry, it is passed ALREADY
MODIFIED to the function that looks for the mapping but using the new GID
(the one of newdomadm) ! 

Since the search keys aren't the same (SID, then
Gid), we may get in trouble here. This is what happens, it doesn't return
the same record, it returns the second, existing one
(S-1-5-21-3746524048-3196343125-3229652583-520/newdomadm) which is modified
to S-1-5-21-3746524048-3196343125-3229652583-512/newdomadm.