#47327 error syncing group if group member user is not synced
Closed: Fixed None Opened 6 years ago by rmeggins.

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

  • the first problem is that the group in rhds now contains a user that does not exist in rhds

4) add a group member to the group in AD - the group member should be a user that is synced to rhds

  • error - the group is not synced to rhds - error 20 - type or value exists

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

Since the user doesn't exist, map_dn_values does not add it to the restricted_local_values. Then winsync calls windows_generate_dn_value_mods to add the members from the AD group to the rhds group. This fails because the group member that does not exist in RHDS is not in restricted_local_values, so winsync attempts to add it to the RHDS - but it already is present in the group, brought over by the initial sync.

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.

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.

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.

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.

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

2 years ago

Login to comment on this ticket.

Metadata