Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/521 Yesterday I committed a change on a users DN and today I noticed replication issues in my logs. The logs told me the uniqueid # and CSN # So I used cl-dump to dump the changelog into a file. Here are the results of what I grep'ed out: [root@ds]# grep "50a150a4000000020000" -B2 -A13 /var/tmp/change.dump changetype: modrdn replgen: 4ff8a4c0000000010000 csn: 50a150a4000000020000 nsuniqueid: 754ce981-e4d411e1-b828c127-7d7e145e dn: uid=auser,ou=threataa,ou=ops,ou=groups,dc=company,dc=net newrdn: uid=auser deleteoldrdn: false newsuperiordn: ou=threatbb,ou=ops,ou=groups,dc=company,dc=net change:: replace: modifiersname modifiersname: cn=directory manager - replace: modifytimestamp modifytimestamp: 20121112194019Z - Here is the error message that I am receiving in /var/log/dirsrv/slap-xxxx/errors : [13/Nov/2012:20:13:27 -0600] NSMMReplicationPlugin - agmt="cn=sync001" (AD1.company.net:636): Consumer failed to replay change (uniqueid 754ce981-e4d411e1-b828c127-7d7e145e, CSN 50a150a4000000020000): Server is unwilling to perform. Will retry later. # rpm -q 389-ds-base 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 '''Rich Megginson 10:16 AM (3 hours ago)''' to me On 11/14/2012 08:56 AM, Derek Belcher wrote: This master is bi-directionally syncing with my Active Directory server. On the AD server, I have created a customer filtered view for the time this started, 11/12/2014 between 1pm and 2pm, included all possible windows log sources and I am not seeing any errors. I believe this is due to 389ds, pulls and pushes updates, and AD is not really aware of 389ds. '''Correct.''' So I am thinking that the modrdn command is not able to make the changes on the AD side? But if 389ds is pushing changes... '''It should be, but AD is more restrictive of the types of modrdn and entry move operations it will allow.''' What is also interesting is that you can in AD "move" a users to a different DN and 389ds will replicate that change to all of its multi-masters and consumers. Just does not seem to work when you do DN changes on the 389ds side and it pushes to AD. '''It should work - does this happen with any modrdn entry move operation?''' Is there a way to remove this offending entry in the change log? '''Not that I know of. What you will have to do is dump your database to ldif and reload it, then reinitialize all of your replicas and winsync agreements. Please file a ticket at https://fedorahosted.org/389 - this is definitely a bug.''' This is the first bug report ticket I have ever filled out, please let me know if anything else is needed
$ rpm -qa | grep 389 389-ds-base-libs-1.3.3.1-13.el7.x86_64 389-ds-base-1.3.3.1-13.el7.x86_64 389-ds-base-debuginfo-1.3.3.1-13.el7.x86_64 Steps: Create ou=OU and ou=SUBOU,ou=OU on both AD and DS (since I could not create ou=SUBOU under cn=Users on AD). Set up an agreement between the ou=OU on AD and on DS. 1. create an entry on DS: uid=tuser,ou=OU,<suffix> $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 -a << EOF dn: uid=tuser,ou=ou,dc=example,dc=com objectClass: inetorgperson objectClass: inetuser objectclass: ntUser uid: tuser givenName: tuser sn: tuser cn: tuser ntUserCreateNewAccount: true ntUserDomainId: tuser ntUserDeleteAccount: true userPassword: Secret123 EOF adding new entry "uid=tuser,ou=ou,dc=example,dc=com" check the entry is synchronized to AD $ ldapsearch -o ldif-wrap=no -LLL -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldap://win2k8.adrelm.com -b dc=adrelm,dc=com cn=tuser dn dn: CN=tuser,OU=OU,DC=adrelm,DC=com 2. move uid=tuser,ou=OU,<suffix> to ou=SUBOU,ou=OU,<suffix> with deleteoldrdn: 0 on DS $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 -a << EOF dn: uid=tuser,ou=OU,dc=example,dc=com changetype: modrdn newrdn: uid=tuser deleteoldrdn: 0 newsuperior: ou=SUBOU,ou=OU,dc=example,dc=com EOF modifying rdn of entry "uid=tuser,ou=OU,dc=example,dc=com" check the entry is moved on AD, as well $ ldapsearch -o ldif-wrap=no -LLL -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldap://win2k8.adrelm.com -b dc=adrelm,dc=com cn=tuser dn dn: CN=tuser,OU=SUBOU,OU=OU,DC=adrelm,DC=com 3. move uid=tuser,ou=SUBOU,ou=OU,<suffix> to ou=OU,<suffix> with deleteoldrdn: 1 on DS $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 -a << EOF dn: uid=tuser,ou=SUBOU,ou=OU,dc=example,dc=com changetype: modrdn newrdn: uid=tuser deleteoldrdn: 1 newsuperior: ou=OU,dc=example,dc=com EOF modifying rdn of entry "uid=tuser,ou=SUBOU,ou=OU,dc=example,dc=com" check the entry is moved on AD, as well $ ldapsearch -o ldif-wrap=no -LLL -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldap://win2k8.adrelm.com -b dc=adrelm,dc=com cn=tuser dn dn: CN=tuser,OU=OU,DC=adrelm,DC=com 4. create an entry on AD: uid=auser,ou=OU,<suffix> $ ldapadd -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldaps://win2k8.adrelm.com:636 << EOF dn: CN=auser,ou=OU,dc=adrelm,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: auser sn: auser uid: auser givenName: auser distinguishedName: CN=auser,ou=OU,dc=adrelm,dc=com displayName: auser sAMAccountName: auser userPrincipalName: auser@dc=adrelm,dc=com userAccountControl: 512 unicodePwd::IgBTAGUAYwByAGUAdAAxADIAMwA0ACIA EOF adding new entry "CN=auser,ou=OU,dc=adrelm,dc=com" check the entry is synchronized to DS $ ldapsearch -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 -LLL -o ldif-wrap=no -b "dc=example,dc=com" uid=auser dn dn: uid=auser,OU=OU,dc=example,dc=com 5. move uid=tuser,ou=OU,<suffix> to ou=SUBOU,ou=OU,<suffix> on AD $ ldapmodify -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldap://win2k8.adrelm.com << EOF dn: CN=tuser,OU=OU,DC=adrelm,DC=com changetype: modrdn newrdn: CN=tuser deleteoldrdn: 1 newsuperior: OU=SUBOU,OU=OU,DC=adrelm,DC=com EOF modifying rdn of entry "CN=tuser,OU=OU,DC=adrelm,DC=com" check the entry is moved on DS, as well $ ldapsearch -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 -LLL -o ldif-wrap=no -b "dc=example,dc=com" uid=tuser dn dn: uid=tuser,OU=SUBOU,OU=OU,dc=example,dc=com 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