Red Hat Bugzilla – Bug 1090178
#481 breaks possibility to reassemble memberuid list
Last modified: 2015-03-05 04:34:26 EST
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/47770 since the changes of #481 it is not possible any more to regenerate memberuids from uniquemember list by create a memberuid task. Steps to reproduce -- test: - assign a user on AD Posix values - check this is synced - assign user a group membership in AD - check it is synced to DS and memberuid value is added in corresponding group on DS - delete memberuid value on DS - start fix_memberuid task - nothing happend --> wrong! the memberuid should be regenerated The idea of my implemetation was, that memberuid only maintained on DS and NOT in AD. So that AD admins only have to assign group memberships and never touch the memberuid list in AD.
$ rpm -qa | grep 389 389-ds-base-debuginfo-1.3.3.1-10.el7.x86_64 389-ds-base-1.3.3.1-10.el7.x86_64 389-ds-base-libs-1.3.3.1-10.el7.x86_64 Add user and group entry with POSIX attributes to AD: $ ldapadd -x -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldap://win2k8.adrelm.com << EOF dn: CN=usr0,ou=adpasssync,dc=adrelm,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user objectClass: posixAccount uidNumber: 111 gidNumber: 111 cn: usr0 sn: usr0 uid: usr0 givenName: usr0 distinguishedName: CN=usr0,ou=adpasssync,dc=adrelm,dc=com displayName: usr0 unixHomeDirectory: /home/usr0 homeDirectory: /home/usr0 loginShell: /bin/bash sAMAccountName: usr0 userPrincipalName: usr0@dc=adrelm,dc=com dn: CN=grp0,ou=adpasssync,dc=adrelm,dc=com objectClass: top objectClass: Group objectClass: posixGroup cn: grp0 gidNumber: 222 distinguishedName: CN=grp0,ou=adpasssync,dc=adrelm,dc=com name: grp0 sAMAccountName: grp0 groupType: 2 objectCategory: CN=Group,CN=Schema,CN=Configuration,dc=adrelm,dc=com EOF adding new entry "CN=usr0,ou=adpasssync,dc=adrelm,dc=com" adding new entry "CN=grp0,ou=adpasssync,dc=adrelm,dc=com" Assign user a group membership in AD: $ ldapmodify -x -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldap://win2k8.adrelm.com << EOF dn: CN=grp0,OU=adpasssync,DC=adrelm,DC=com changetype: modify add: member member: CN=usr0,OU=adpasssync,DC=adrelm,DC=com EOF modifying entry "CN=grp0,OU=adpasssync,DC=adrelm,DC=com" Refresh replica to sync changes to DS: $ ldapmodify -H ldap://localhost:1189 -D "cn=Directory Manager" -w Secret123 -x << EOF dn: cn=WinPassSync,cn=replica,cn=dc\3Dpasssync\,dc\3Dcom,cn=mapping tree,cn=config changetype: modify add: nsds5BeginReplicaRefresh nsds5BeginReplicaRefresh: start EOF modifying entry "cn=WinPassSync,cn=replica,cn=dc\3Dpasssync\,dc\3Dcom,cn=mapping tree,cn=config" Check it is synced to DS and memberuid value is added in corresponding group on DS: $ ldapsearch -LLL -H ldap://localhost:1189 -D "cn=Directory Manager" -w Secret123 -x -b cn=grp0,ou=dswinsync,dc=passsync,dc=com "memberUid" dn: cn=grp0,ou=dswinsync,dc=passsync,dc=com memberUid: usr0 Delete memberuid attribute on DS: $ ldapmodify -H ldap://localhost:1189 -D "cn=Directory Manager" -w Secret123 -x << EOF dn: cn=grp0,ou=dswinsync,dc=passsync,dc=com changetype: modify delete: memberUid EOF modifying entry "cn=grp0,ou=dswinsync,dc=passsync,dc=com " Check that is was deleted: $ ldapsearch -LLL -H ldap://localhost:1189 -D "cn=Directory Manager" -w Secret123 -x -b cn=grp0,ou=dswinsync,dc=passsync,dc=com "memberUid" dn: cn=grp0,ou=dswinsync,dc=passsync,dc=com Run fix_memberuid task: $ ldapmodify -H ldap://localhost:1189 -D "cn=Directory Manager" -w Secret123 -x -a << EOF dn: cn=memuidtask,cn=memberuid task,cn=tasks,cn=config cn: memuidtask objectClass: extensibleObject objectClass: top EOF adding new entry "cn=memuidtask,cn=memberuid task,cn=tasks,cn=config" Check that memberuid was regenerated: $ ldapsearch -LLL -H ldap://localhost:1189 -D "cn=Directory Manager" -w Secret123 -x -b cn=grp0,ou=dswinsync,dc=passsync,dc=com "memberUid" dn: cn=grp0,ou=dswinsync,dc=passsync,dc=com memberUid: usr0 memberuid is regenerated, hence marking this bug 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