Hide Forgot
+++ This bug was initially created as a clone of Bug #1049029 +++ This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/47642 version: 389-Directory/1.2.11.25 B2013.347.1221 389DS <--> Windows 2008 R2 Name of group: GSG_TESTE Included a lot of users on this group, including this user: choose a user to test DN of the user on windows: CN=Alberto Viana,OU=TESTE,DC=homolog,DC=rnp DN of the user on 389DS: uid=alberto.viana,ou=TESTE,dc=homolog,dc=rnp What I did: Changeg the OU of the user via windows to: NEW DN: CN=Alberto Viana,OU=NEW,DC=homolog,DC=rnp What happenned: Did not deleted all users from the group. 389DS moved correctly the user to new DN: uid=alberto.viana,ou=NEW,dc=homolog,dc=rnp 389DS Added this new uid (uid=alberto.viana,ou=NEW,dc=homolog,dc=rnp) to group, but keep the old entry too (uid=alberto.viana,ou=TESTE,dc=homolog,dc=rnp). Whe I remove the old entry manually (uid=alberto.viana,ou=TESTE,dc=homolog,dc=rnp) from the group, 389 DS deletes all users from the group on both sides (389DS and windows) Just to let you know that I have others versions of 389DS running (389-Directory/1.3.1.3 and 389-Directory/1.2.10.12), and just the fact to change the DN/OU of one user in a group, deletes all users from this group (not from 389 DS).
$ rpm -qa | grep 389 389-ds-base-debuginfo-1.3.3.1-11.el7.x86_64 389-ds-base-libs-1.3.3.1-11.el7.x86_64 389-ds-base-1.3.3.1-11.el7.x86_64 [0] Add test entries: $ ldapmodify -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldap://win2k8.adrelm.com -a << EOF dn: OU=subou,ou=adsync,dc=adrelm,dc=com objectClass: top objectClass: organizationalUnit ou: subou dn: CN=usr0,ou=adsync,dc=adrelm,dc=com objectClass: top objectClass: user cn: usr0 sn: usr0 uid: usr0 sAMAccountName: usr0 distinguishedName: CN=usr0,ou=adsync,dc=adrelm,dc=com dn: CN=grp0,ou=adsync,dc=adrelm,dc=com objectClass: top objectClass: Group cn: grp0 distinguishedName: CN=grp0,ou=adsync,dc=adrelm,dc=com name: grp0 sAMAccountName: grp0 member: CN=usr0,ou=adsync,dc=adrelm,dc=com EOF adding new entry "OU=subou,ou=adsync,dc=adrelm,dc=com" adding new entry "CN=usr0,ou=adsync,dc=adrelm,dc=com" adding new entry "CN=grp0,ou=adsync,dc=adrelm,dc=com" $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 -a << EOF dn: ou=subou,ou=People,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: subou EOF adding new entry "ou=subou,ou=People,dc=example,dc=com" [1] Move usr0 to ou=subou: $ ldapmodify -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldap://win2k8.adrelm.com << EOF dn: CN=usr0,OU=adsync,DC=adrelm,DC=com changetype: moddn newrdn: CN=usr0 deleteoldrdn: 1 newsuperior: OU=subou,OU=adsync,DC=adrelm,DC=com EOF modifying rdn of entry "CN=usr0,OU=adsync,DC=adrelm,DC=com" [2] Check uniqueMember in the group: $ ldapsearch -o ldif-wrap=no -LLL -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 -b dc=example,dc=com cn=grp0 uniqueMember dn: cn=grp0,ou=People,dc=example,dc=com uniqueMember: uid=usr0,ou=subou,ou=people,dc=example,dc=com DN of the uniquemember is adjusted to the new location, marking as VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0416.html