Bug 734831 - WinSync: Certain entries in DS are not updated properly when using WinSync API
Summary: WinSync: Certain entries in DS are not updated properly when using WinSync API
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On: 722292
Blocks: 734933
TreeView+ depends on / blocked
 
Reported: 2011-08-31 14:59 UTC by Nathan Kinder
Modified: 2015-01-04 23:50 UTC (History)
6 users (show)

Fixed In Version: 389-ds-base-1.2.9.11-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 722292
Environment:
Last Closed: 2011-12-06 17:56:21 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2011:1711 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2011-12-06 01:02:20 UTC

Description Nathan Kinder 2011-08-31 14:59:37 UTC
+++ This bug was initially created as a clone of Bug #722292 +++

Description of problem:

Certain entries in DS are not being updated properly over Active Directory agreement when WinSync API plugin is enabled (Using the test plugin code that is provided in winsync-plugin.h).

Version-Release number of selected component (if applicable):

1.2.8.3

How reproducible:
100%


Steps to Reproduce:
1. Compile and configure a WinSync API plugin (I used the exact example that is in the winsync-plugin.h file)
2. Create sync agreement between 389 and Active Directory, replicating the DS subtree (ou=People,dc=example,dc=com) and the Windows subtree (dc=example,dc=local)
3. In AD create an Test OU under dc=example,dc=local (ou=Test,dc=example,dc=local)
4. Create two users, one in the dc=example,dc=local subtree (user1), and the other user (user2) in the Test OU (ou=Test,dc=example,dc=local)
5. Run and sync, either incrmental or total and the two entries will be created on the DS side in the ou=People,dc=example,dc=com.
6. In AD, perform updates on both accounts (ie Add an email address or something)
7. Run incremental update.
8. In DS, you should now see that user1 should have the updated attribute, but user2 does not.  

  
Actual results:

User1 should be updated properly, but user2 will not be.  If you have nsslapd-errorlog-level set to 65536, there should be an error similar to this:

[14/Jul/2011:13:21:13 -0700] NSMMReplicationPlugin - failed to rename entry (uid=User2,ou=People,dc=example,dc=com); LDAP error - 32

Expected results:

Both users should be updated properly

Additional info:

The plugin works correctly on version 1.2.5

--- Additional comment from nkinder@redhat.com on 2011-08-25 14:04:15 EDT ---

Here is a more complete log snippet that demonstrates what is logged when we receive the update to the user contained in an OU:

=============================================================================
[25/Aug/2011:10:57:04 -0700] NSMMReplicationPlugin - received entry from dirsync: CN=Test 2,CN=level0,CN=Users,DC=example,DC=com
[25/Aug/2011:10:57:04 -0700] NSMMReplicationPlugin - agmt="cn=meTo10.14.54.184389" (10:389): map_entry_dn_inbound: looking for local entry matching AD entry [CN=Test 2,CN=level0,CN=Users,DC=example,DC=com]
[25/Aug/2011:10:57:04 -0700] NSMMReplicationPlugin - agmt="cn=meTo10.14.54.184389" (10:389): map_entry_dn_inbound: looking for local entry by guid [3b120754626be2438de88d4f43404fd2]
[25/Aug/2011:10:57:04 -0700] test_winsync_api - --> test_winsync_pre_ds_search_cb -- begin
[25/Aug/2011:10:57:04 -0700] test_winsync_api - <-- test_winsync_pre_ds_search_cb -- end
[25/Aug/2011:10:57:04 -0700] NSMMReplicationPlugin - agmt="cn=meTo10.14.54.184389" (10:389): map_entry_dn_inbound: found local entry [uid=test2,ou=People,dc=example,dc=com]
[25/Aug/2011:10:57:04 -0700] - Calling windows entry search request plugin
[25/Aug/2011:10:57:04 -0700] test_winsync_api - --> test_winsync_pre_ad_search_cb -- begin
[25/Aug/2011:10:57:04 -0700] test_winsync_api - <-- test_winsync_pre_ad_search_cb -- end
[25/Aug/2011:10:57:05 -0700] - windows_search_entry: received 2 messages, 1 entries, 0 references
[25/Aug/2011:10:57:05 -0700] - _csngen_adjust_local_time: gen state before 4e568cf00001:1314295024:0:0
[25/Aug/2011:10:57:05 -0700] - _csngen_adjust_local_time: gen state after 4e568cf10000:1314295025:0:0
[25/Aug/2011:10:57:05 -0700] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4e568cf1000000010000 into pending list
[25/Aug/2011:10:57:05 -0700] NSMMReplicationPlugin -  csn=4e568cf1000000010000 process postop: canceling operation csn
[25/Aug/2011:10:57:05 -0700] NSMMReplicationPlugin - failed to rename entry (uid=test2,ou=People,dc=example,dc=com); LDAP error - 32
[25/Aug/2011:10:57:05 -0700] NSMMReplicationPlugin - agmt="cn=meTo10.14.54.184389" (10:389): windows_process_dirsync_entry: failed to update inbound entry for CN=Test 2,CN=level0,CN=Users,DC=example,DC=com.
=============================================================================

It appears that the problem is not in the winsync API plug-in itself based off of the logs.  Something in the replication plug-in must be getting tripped up due to the flattening of the DN that is done by the winsync API plug-in.

--- Additional comment from rmeggins@redhat.com on 2011-08-25 14:31:10 EDT ---

I have a IPA winsync plugin setup already - want me to take a look at this?

--- Additional comment from nkinder@redhat.com on 2011-08-25 16:19:30 EDT ---

(In reply to comment #2)
> I have a IPA winsync plugin setup already - want me to take a look at this?

No, I already have this reproduced using the sample winsync API plug-in.

--- Additional comment from nkinder@redhat.com on 2011-08-25 16:34:17 EDT ---

The problem was introduced when we added support for moving an entry in AD, which triggers a rename (MODRDN) in DS.

Since the winsync API plug-in in this test flattens the DN, the windows_update_local_entry() function thinks that the entry was renamed on the AD side.  We then attempt to do a MODRN operation on the DS side against the mapped DN, but that entry doesn't exist since the winsync API plug-in rewrote it when the entry was initially added.

We need some way of detecting a rename operation without interfering with winsync API plug-ins that rewrite the DN of the entry.  We might be able to do this by making windows_update_local_entry() call the registered winsync_get_new_dn_cb callback to determine if the entry has really been renamed or not.

--- Additional comment from nkinder@redhat.com on 2011-08-30 16:29:28 EDT ---

Created attachment 520685 [details]
Patch

--- Additional comment from rmeggins@redhat.com on 2011-08-30 17:03:09 EDT ---

Comment on attachment 520685 [details]
Patch

in https://bugzilla.redhat.com/attachment.cgi?id=520685&action=diff#a/ldap/servers/plugins/replication/windows_protocol_util.c_sec5

Do you need to use slapi_create_dn_string() instead?  That is, if it is possible that local_pndn, remote_subtree, or local_subtree could contain a character that needs to be DN escaped, you would need to call slapi_create_dn_string() instead - for example, see process_replay_add()

--- Additional comment from nkinder@redhat.com on 2011-08-30 17:10:53 EDT ---

(In reply to comment #6)
> Comment on attachment 520685 [details]
> Patch
> 
> in
> https://bugzilla.redhat.com/attachment.cgi?id=520685&action=diff#a/ldap/servers/plugins/replication/windows_protocol_util.c_sec5
> 
> Do you need to use slapi_create_dn_string() instead?  That is, if it is
> possible that local_pndn, remote_subtree, or local_subtree could contain a
> character that needs to be DN escaped, you would need to call
> slapi_create_dn_string() instead - for example, see process_replay_add()

Yes, we should use slapi_create_dn_string() instead of PR_smprintf().  I will make the change and attach a revised patch.

--- Additional comment from nkinder@redhat.com on 2011-08-30 17:20:45 EDT ---

Created attachment 520694 [details]
Revised Patch

--- Additional comment from rmeggins@redhat.com on 2011-08-30 18:22:49 EDT ---

Comment on attachment 520694 [details]
Revised Patch

assuming local_pndn, remote_subtree, and local_subtree have no DN special characters, this is fine

--- Additional comment from nkinder@redhat.com on 2011-08-31 10:56:44 EDT ---

Pushed to master.  Thanks to Rich and Noriko for their reviews!

Counting objects: 13, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 2.56 KiB, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   4fdd413..402cd42  master -> master

Comment 1 Nathan Kinder 2011-08-31 16:31:34 UTC
Pushed patch to internal ds-replication-RHEL-6 branch:

Counting objects: 17, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 2.84 KiB, done.
Total 10 (delta 7), reused 0 (delta 0)
To ssh://git.engineering.redhat.com/srv/git/users/rmeggins/ds.git
   adca2fe..aa94e2d  ds-replication-RHEL-6 -> ds-replication-RHEL-6

Comment 4 Rich Megginson 2011-09-16 20:27:50 UTC
This bug and the two patches have been rolled into the 389-ds-base package - we are not going to have a separate ds-replication package in RHEL 6.2.  see https://bugzilla.redhat.com/show_bug.cgi?id=739196

git://git.engineering.redhat.com/srv/git/users/rmeggins/ds.git
branch RHEL-6
commit 1e098d7b770de2f6b11b4e02eb07efdf696d3890
Author: Nathan Kinder <nkinder@redhat.com>
Date:   Thu Sep 1 09:41:06 2011 -0700

    Bug 722292 - (cov#11030) Leak of mapped_sdn in winsync rename code
    
    The previous fix for bug 722292 introduced a memory leak of the
    mapped DN used to detect entry renames.  This ensures that we
    free the mapped DN.
    (cherry picked from commit 93f079a9eea2472e9481bfd482a624f980e17c9a)
    (cherry picked from ds-replication-RHEL-6 branch)
commit 4211296c1c521af9a64f3d96ac2fd2e9468870ec
Author: Nathan Kinder <nkinder@redhat.com>
Date:   Tue Aug 30 14:19:11 2011 -0700

    Bug 722292 - Entries in DS are not updated properly when using WinSync API
    (cherry picked from commit 7b266fbfd0a56fc4cc5cf167cfa3402c6bf89425)
    (cherry picked from ds-replication-RHEL-6 branch)

Comment 6 Amita Sharma 2011-09-22 11:00:36 UTC
Marking as verified as clone https://bugzilla.redhat.com/show_bug.cgi?id=722292 is verified.

Comment 7 errata-xmlrpc 2011-12-06 17:56:21 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.

http://rhn.redhat.com/errata/RHEA-2011-1711.html


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