Bug 728510 - WinSync: Renaming an user(which is synced from DS to AD) at AD is creating a new user at DS.
Summary: WinSync: Renaming an user(which is synced from DS to AD) at AD is creating a ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Sync Service
Version: 1.2.9
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: 690318 389_1.2.9 729838
TreeView+ depends on / blocked
 
Reported: 2011-08-05 11:58 UTC by Sankar Ramalingam
Modified: 2015-12-10 18:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-10 18:40:51 UTC


Attachments (Terms of Use)
Patch (2.77 KB, patch)
2011-08-10 21:24 UTC, Nathan Kinder
nkinder: review?
rmeggins: review+
Details | Diff

Description Sankar Ramalingam 2011-08-05 11:58:54 UTC
Description of problem: Renaming an entry by right-clicking at the user at AD is creating a new user at DS.

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

How reproducible: Consistently.

Steps to Reproduce:
1. Install 389-ds-base latest packages and configure WinSync, bi-directional.
2. Run "Initiate Full-Resynchronization" to sync entries from both sides.
3. Once the users are in sync at both sides, create an user at DS as below.

cat user.ldif 
dn: cn=renameuser1,dc=pass_sync,dc=com
telephoneNumber: 989898191
mail: renameuser1@redhat.com
uid: renameuser1
givenName: renameuser1
objectClass: top
objectClass: person
objectClass: inetorgperson
objectclass: ntUser
sn: renameuser1
cn: renameuser1
ntUserCreateNewAccount: true
ntUserDomainId: renameuser1
ntUserDeleteAccount: true
userPassword: Secret1234

4. Go to AD machine, right-click on the entry(renameuser1) and rename it to "BugRenameUsr". 
5. Change the logon name as well in the "Rename User" window.
6. User's logon name successfully changed at AD.
7. Click on "Send and Receive updates Now" button in the winsync agreement.
8. Surprise!, yes, you will see a new account being created at DS as "uid=BugRenameUsr,dc=pass_sync,dc=com".

  
Actual results: Rename operation renames the actual entry and as well creates one more new entry at DS.


Expected results: Its expected to rename only the original entry.


Additional info: The same thing doesn't happen if the user entry is created as "dn: uid=renameuser1,$Suffix" or for the entry which is created at AD.

ldapsearch results...

# renameuser1, pass_sync.com
dn: cn=renameuser1,dc=pass_sync,dc=com
telephoneNumber: 989898191
mail: renameuser1@redhat.com
uid: renameuser1
givenName: renameuser1
objectClass: top
objectClass: person
objectClass: inetorgperson
objectClass: ntUser
objectClass: organizationalPerson
sn: renameuser1
cn: renameuser1
ntUserCreateNewAccount: true
ntUserDomainId: renameuser1
ntUserDeleteAccount: true
userPassword:: e1NTSEF9K3MyM1YrUFViajhxOE1hc2twaE9MelhUVUhNaHdLT2o5VXMwYXc9PQ=
 =

# BugRenameUsr, pass_sync.com
dn: uid=BugRenameUsr,dc=pass_sync,dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetOrgPerson
objectClass: ntUser
ntUserDeleteAccount: true
uid: BugRenameUsr
sn: renameuser1
telephoneNumber: 989898191
givenName: renameuser1
cn: BugRenameUsr
ntUserCodePage: 0
ntUserAcctExpires: 9223372036854775807
ntUserDomainId: BugRenameUsr
mail: renameuser1@redhat.com
ntUniqueId: c5d1d3e96d79544c86b0ca084efa6907

Comment 1 Nathan Kinder 2011-08-09 17:41:15 UTC
Are you waiting for the dirsync interval to happen (or forcing a dirsync) between steps 3 and 4?  When adding an entry to DS, it is not completely sync'd up with the AD entry until a dirsync occurs.  Until this happens, we don't have the GUID that AD generates for the new entry.  I'll run some tests, but we most likely see this as a new entry being added due to the rename before the GUID is sync'd.

Comment 2 Nathan Kinder 2011-08-09 17:58:07 UTC
The problem does look related to us not having the GUID of the entry that was newly added to AD before the rename is sent as a part of the dirsync update.  Here are the logs on the DS side when we receive the renamed entry from dirsync:

------------------------------------------------------------------------------
[09/Aug/2011:10:53:28 -0700] - Calling dirsync search request plugin
[09/Aug/2011:10:53:28 -0700] - Sending dirsync search request
[09/Aug/2011:10:53:28 -0700] NSMMReplicationPlugin - received entry from dirsync: CN=bugrenameuser1,CN=Users,DC=example,DC=com
[09/Aug/2011:10:53:28 -0700] NSMMReplicationPlugin - agmt="cn=meTo10.14.54.184389" (10:389): map_entry_dn_inbound: looking for local entry matching AD entry [CN=bugrenameuser1,CN=Users,DC=example,DC=com]
[09/Aug/2011:10:53:28 -0700] NSMMReplicationPlugin - agmt="cn=meTo10.14.54.184389" (10:389): map_entry_dn_inbound: looking for local entry by guid [aedb19bce30b08408048a56c330c7ae2]
[09/Aug/2011:10:53:28 -0700] NSMMReplicationPlugin - agmt="cn=meTo10.14.54.184389" (10:389): map_entry_dn_inbound: problem looking for guid: -1
[09/Aug/2011:10:53:28 -0700] NSMMReplicationPlugin - agmt="cn=meTo10.14.54.184389" (10:389): map_entry_dn_inbound: looking for local entry by uid [bugrenameuser1]
[09/Aug/2011:10:53:28 -0700] NSMMReplicationPlugin - agmt="cn=meTo10.14.54.184389" (10:389): map_entry_dn_inbound: problem looking for username: -1
[09/Aug/2011:10:53:28 -0700] - Windows sync entry: Adding new local entry dn: uid=bugrenameuser1,ou=people,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetOrgPerson
objectClass: ntUser
ntUserDeleteAccount: true
uid: bugrenameuser1
sn: bugrenameuser1
telephoneNumber: 989898191
givenName: bugrenameuser1
cn: bugrenameuser1
ntUserCodePage: 0
ntUserAcctExpires: 9223372036854775807
ntUserDomainId: bugrenameuser1
mail: renameuser1@redhat.com
ntUniqueId: aedb19bce30b08408048a56c330c7ae2
------------------------------------------------------------------------------

As you can see, we attempt to find the DS entry by GUID (which fails), then we try by uid (which also fails due to the rename).  We treat this as a new entry, which results in adding a new DS entry since we have no way to map it to the the original DS entry.

Comment 3 Nathan Kinder 2011-08-09 20:01:42 UTC
This issue is not a regression, but I do see some room for improvement that we could make in a future version.

The problem stems from updates that happen in the window between ADD operations syncing to AD, and the GUID being synced back to DS as a part of the dirsync update.  Updates in this 5 minute window should not be common in the real world, but we would reduce the chance for problems if we can minimize this window.

One way of minimizing this update window is to always perform a dirsync update immediately after we send updates to AD.  We currently only perform the dirsync at 5 minute intervals, but there would be no harm in doing a dirsync after we send updates to AD from our changelog.  This would ensure that we get the GUID back from AD for ADD operations in a minimum amount of time.  This would need to be done for both the total and incremental sync protocols.

Comment 4 Nathan Kinder 2011-08-10 21:24:12 UTC
Created attachment 517698 [details]
Patch

Comment 5 Nathan Kinder 2011-08-10 22:15:22 UTC
Pushed to master.  Thanks to Rich for his review!

Counting objects: 25, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (16/16), 2.44 KiB, done.
Total 16 (delta 12), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   d7d0b2a..a150e8e  master -> master


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