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 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 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 ntUniqueId: c5d1d3e96d79544c86b0ca084efa6907
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.
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 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.
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.
Created attachment 517698 [details] Patch
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