Bug 728510
| Summary: | WinSync: Renaming an user(which is synced from DS to AD) at AD is creating a new user at DS. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Sankar Ramalingam <sramling> | ||||
| Component: | Sync Service | Assignee: | Rich Megginson <rmeggins> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ben Levenson <benl> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 1.2.9 | CC: | edewata, nhosoi, nkinder, rmeggins | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-12-10 18:40:51 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: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 690318, 708096, 729838 | ||||||
| Attachments: |
|
||||||
|
Description
Sankar Ramalingam
2011-08-05 11:58:54 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. 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 |