Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 951616
Description of problem: User is not being synced over to the LDAP side when the user is added to a group on the AD. The user is believed to be already existing on the LDAP server when it does not exist. Version-Release number of selected component (if applicable): 389-ds-base-libs-1.2.10.2-20.el6_3.x86_64.rpm 389-ds-base-1.2.10.2-20.el6_3.x86_64.rpm 389-ds-base-debuginfo-1.2.10.2-20.el6_3.x86_64.rpm How reproducible:100% Steps to Reproduce: 1. Please find these details as one of the comments to the ticket.. 2. 3. Actual results: The user does not get update on the LDAP server Expected results: All the necessary checks are performed and the user is synced over to the LDAP side. Additional info: [09/Apr/2013:16:27:14 -0400] NSMMReplicationPlugin - agmt="cn=SyncADtoLDAP" (ldap:636): map_entry_dn_outbound: found AD entry dn="CN=User,OU=Users,OU=container,DC=example,dc=com" [09/Apr/2013:16:27:14 -0400] NSMMReplicationPlugin - windows_generate_update_mods: cn=groupname,ou =Groups,ou=container,dc=example,dc=com, ntUserDomainId : values are equal [09/Apr/2013:16:27:14 -0400] - smod - windows sync [09/Apr/2013:16:27:14 -0400] - smod 0 - add: uniquemember [09/Apr/2013:16:27:14 -0400] - smod 0 - value: uniquemember: uid=user1,ou=Users,OU=container,DC=example,dc=com [09/Apr/2013:16:27:14 -0400] - smod 1 - add: uniquemember [09/Apr/2013:16:27:14 -0400] - smod 1 - value: uniquemember: uid=user1,OU=DoNotSyncThisOU,OU=container,DC=example,dc=com [09/Apr/2013:16:27:14 -0400] NSMMReplicationPlugin - modifying entry: cn=groupname,ou=Groups,ou=container,dc=example,dc=com ... [09/Apr/2013:16:27:14 -0400] NSMMReplicationPlugin - windows_update_local_entry: failed to modify entry cn=groupname,ou=Groups,ou=container,dc=example,dc=com - error 20:Type or value exists
Steps: 1) setup winsync - the windows subtree should have at least one ou in the sync area that exists in rhds, and at least one ou in the sync area that does not exist in rhds 2) create a group in AD - the group should have at least one member that is in an ou that exists in rhds (i.e. the user is synced to rhds) and at least one member that is in an ou that does not exist in rhds (i.e. the user is not synced to rhds) 3) do a winsync init - check the group in rhds
4) add a group member to the group in AD - the group member should be a user that is synced to rhds
the problem is in windows_generate_update_mods() - for DN values, winsync calls map_dn_values to find the local entries in the group: restricted_local_values at line 4317.
The problem is that does not find all of the entries - with replication logging you will see this: [10/Apr/2013:16:11:35 -0400] - map_dn_values: no local entry found for uid=userdoesnotexistinrhds,OU=DoesNotExistInRHDS,cn=users,dc=example,dc=com
Note on the steps to reproduce. You may fail to create OU in "cn=users": OU=DoesNotExistInRHDS,cn=users,dc=example,dc=com
In that case, you could create a container with "cn" e.g. cn=DoesNotExistInRHDS using ADSI Edit.
The symptom I'm observing looks a bit different from the original bug. I don't see error 20. But once I do winsync init, the group is synced where member users which exist in the DS are synced and found in the group on DS, but not uid=userdoesnotexistinrhds, which is good. BUT, the group is synced back to AD and the original group on AD loses uid=userdoesnotexistinrhds from the members... That should not be, shouldn't it?
Now, I'm a bit confused. The expected result would be DS should not send the delete request for uid=userdoesnotexistinrhds to AD, and DS and AD share a same group which members may not match?
Replying to [comment:5 nhosoi]:
The symptom I'm observing looks a bit different from the original bug. I don't see error 20. But once I do winsync init, the group is synced where member users which exist in the DS are synced and found in the group on DS, but not uid=userdoesnotexistinrhds, which is good.
Initial sync or incremental update?
BUT, the group is synced back to AD and the original group on AD loses uid=userdoesnotexistinrhds from the members... That should not be, shouldn't it?
No.
I think we need to have a way for DS to store groups that have members that may not exist in DS.
Replying to [comment:6 rmeggins]:
Replying to [comment:5 nhosoi]: The symptom I'm observing looks a bit different from the original bug. I don't see error 20. But once I do winsync init, the group is synced where member users which exist in the DS are synced and found in the group on DS, but not uid=userdoesnotexistinrhds, which is good. Initial sync or incremental update? I did initial sync. I did incremental update, then "error 20:Type or value exists" is logged! Interestingly, the results from initial sync and incremental update are different (both bad, though...) BUT, the group is synced back to AD and the original group on AD loses uid=userdoesnotexistinrhds from the members... That should not be, shouldn't it? No. Now, I'm a bit confused. The expected result would be DS should not send the delete request for uid=userdoesnotexistinrhds to AD, and DS and AD share a same group which members may not match? I think we need to have a way for DS to store groups that have members that may not exist in DS.
Initial sync or incremental update? I did initial sync. I did incremental update, then "error 20:Type or value exists" is logged! Interestingly, the results from initial sync and incremental update are different (both bad, though...)
All right... I'm going to look into it. Thanks a lot, Rich!
Bug description: Windows Sync synchronizes member attributes in a group entry if the member entry itself is synchronized. The entries in the sync scope are basically to be synchronized. But there is an exception such as a container in the scope is not synchronized due to the objecttype constraints. Such an unsync'ed entry could have users in it. Users are the target of Windows Sync. But since the parent container is not synch- ronized, the users in the container are not, neither. If a group contains such special user as a member, synchronization failed there and the other normal members are failed to get synchronized.
Fix description: Windows Sync has a helper function is_subject_of_agreement_remote, which checks if the entry is in the scope to be synchronized. This patch adds the check if the checking entry's parent locally exists in the DS. If it does not exist, it considers the entry is out of scope. AD strictly checks if the entry exists prior to adding it to a group entry as a member. That is, a member to be added is supposed to be in the server, as well as its parent is. With this change, the AD user which is not synchronized to the DS is just skipped to add to the group in the DS in the same manner as an user out of scope is.
git patch file (master) 0001-Ticket-47327-error-syncing-group-if-group-member-use.patch
Reviewed by Rich (Thank you!!)
Pushed to master: commit 9b0834c
Pushed to 389-ds-base-1.3.1: commit c7e0b79
Pushed to 389-ds-base-1.3.0: commit d89bc22
Pushed to 389-ds-base-1.2.11: commit ec592bb
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.2.11.22
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/664
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.