RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1044143 - modrdn + NSMMReplicationPlugin - Consumer failed to replay change
Summary: modrdn + NSMMReplicationPlugin - Consumer failed to replay change
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:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-17 21:22 UTC by Nathan Kinder
Modified: 2020-09-13 20:20 UTC (History)
4 users (show)

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

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 521 0 None None None 2020-09-13 20:20:06 UTC
Red Hat Product Errata RHSA-2015:0416 0 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Nathan Kinder 2013-12-17 21:22:14 UTC 
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
Comment 4 Viktor Ashirov 2015-01-29 18:02:26 UTC 
$ 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
Comment 6 errata-xmlrpc 2015-03-05 09:29:40 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.