Bug 1049030 - Windows Sync group issues
Summary: Windows Sync group issues
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On: 1049029
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-06 20:05 UTC by Noriko Hosoi
Modified: 2015-03-05 09:33 UTC (History)
1 user (show)

Fixed In Version: 389-ds-base-1.3.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1049029
Environment:
Last Closed: 2015-03-05 09:33:22 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Noriko Hosoi 2014-01-06 20:05:10 UTC
+++ 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).

Comment 2 Viktor Ashirov 2015-01-17 22:19:29 UTC
$ 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.

Comment 4 errata-xmlrpc 2015-03-05 09:33:22 UTC
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


Note You need to log in before you can comment on or make changes to this bug.