Bug 1044143

Summary:	modrdn + NSMMReplicationPlugin - Consumer failed to replay change
Product:	Red Hat Enterprise Linux 7	Reporter:	Nathan Kinder <nkinder>
Component:	389-ds-base	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	7.0	CC:	amsharma, nhosoi, nkinder, vashirov
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	389-ds-base-1.3.3.1-1.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-05 09:29:40 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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