Bug 1109381
Summary: | winsync doesn't sync DN valued attributes if DS DN value doesn't exist | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Noriko Hosoi <nhosoi> |
Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> |
Status: | CLOSED ERRATA | QA Contact: | Sankar Ramalingam <sramling> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.6 | CC: | jgalipea, mkubik, nkinder, rmeggins, vashirov |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 389-ds-base-1.2.11.15-34.el6 389-ds-base-1.2.11.15-40.el6 | Doc Type: | Bug Fix |
Doc Text: |
1)
Problem:
A group on AD has a member which is not a target of windows
sync and exists only on AD. The member value in the group is synchronized to DS. If an operation is executed on AD so that the member is replaced with other members which are the target of the windows sync, the new member values are not synchronized.
Fix:
In windows_generate_update_mods, even if a sync'ed member value in a DS entry is not the target of windows sync and it is does not exist on DS, a following modify operation including the member value is proceeded by confirming the existence on AD.
2)
Problem:
If a group on AD and DS have members which are local and are
not synchronized and the members are removed in the group on
the other side, the delete operation is synchronized and
deletes all the members including the local members.
Fix:
Added the code to check if an attribute is completely deleted on one side, then the each value on the other side is in the sync scope or not. Put the value to the mod for the delete only if the value is in the sync scope.
|
Story Points: | --- |
Clone Of: | 1044142 | Environment: | |
Last Closed: | 2014-10-14 07:55:45 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: | 1044142 | ||
Bug Blocks: |
Description
Noriko Hosoi
2014-06-13 18:54:09 UTC
Thank you for identifying the bug, Milan. Looking at the 389-ds-base-1.2.11 git log, once we had a NULL vs checking (Ticket #415), but it was accidentally removed by the next commit (Ticket 346). I'm adding it back to 1.2.11 / rhel-6.6. 737169e0afd0547b6de0a61081508314d076cc6a valueset.c commit 737169e0afd0547b6de0a61081508314d076cc6a Author: Noriko Hosoi <nhosoi> Date: Thu Feb 20 14:32:41 2014 -0800 Ticket #415 - winsync doesn't sync DN valued attributes if DS DN value doesn't exist slapi_valueset_find(const Slapi_Attr *a, const Slapi_ValueSet *vs, const Slapi_Value *v) { Slapi_Value *r= NULL; - if(!valuearray_isempty(vs->va)) + if(vs && !valuearray_isempty(vs->va)) { int i= valuearray_find(a,vs->va,v); if(i!=-1) ==================================================== commit 890fc22687821279f3862fc0862a4e8d93c00291 Author: Noriko Hosoi <nhosoi> Date: Tue Mar 4 09:35:29 2014 -0800 Ticket 346 - version 4 Slow ldapmodify operation time for large quantities of multi-valued attribute values @@ -945,12 +710,14 @@ Slapi_Value * slapi_valueset_find(const Slapi_Attr *a, const Slapi_ValueSet *vs, const Slapi_Value *v) { Slapi_Value *r= NULL; - if(vs && !valuearray_isempty(vs->va)) - { - int i= valuearray_find(a,vs->va,v); - if(i!=-1) - { - r= vs->va[i]; + if(vs->num > 0) { + if (vs->sorted) { + r = valueset_find_sorted(a,vs,v,NULL); + } else { + int i= valuearray_find(a,vs->va,v); + if(i!=-1) { + r= vs->va[i]; + } } } return r; 0) Add test entries to AD - see that it is synced over to DS $ ldapadd -c -x -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldap://win2k8.adrelm.com << EOF > dn: CN=AD_ONLY,cn=users,dc=adrelm,dc=com > objectClass: top > objectClass: user > cn: AD_ONLY > uid: AD_ONLY > sAMAccountName: AD_ONLY > distinguishedName: CN=AD_ONLY,cn=users,dc=adrelm,dc=com > > dn: CN=AD_AND_DS,cn=users,dc=adrelm,dc=com > objectClass: top > objectClass: user > cn: AD_AND_DS > sn: AD_AND_DS > uid: AD_AND_DS > sAMAccountName: AD_AND_DS > distinguishedName: CN=AD_AND_DS,cn=users,dc=adrelm,dc=com > > dn: CN=grp0,cn=users,dc=adrelm,dc=com > objectClass: top > objectClass: Group > cn: grp0 > distinguishedName: CN=grp0,cn=users,dc=adrelm,dc=com > name: grp0 > sAMAccountName: grp0 > EOF adding new entry "CN=AD_ONLY,cn=users,dc=adrelm,dc=com" adding new entry "CN=AD_AND_DS,cn=users,dc=adrelm,dc=com" adding new entry "CN=grp0,cn=users,dc=adrelm,dc=com" 1) Add an entry to AD with a member: DN that only exists in AD $ ldapmodify -c -x -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldap://win2k8.adrelm.com << EOF > dn: CN=grp0,cn=users,DC=adrelm,DC=com > changetype: modify > add: member > member: CN=AD_ONLY,CN=Users,DC=adrelm,DC=com > EOF modifying entry "CN=grp0,cn=users,DC=adrelm,DC=com" 2) See that the ADD is synced over to DS - the DS will see that member is DN valued and try to map appropriately $ ldapsearch -LLL -H ldap://localhost:1189 -D "cn=Directory Manager" -w Secret123 -x -b dc=passsync,dc=com "(cn=grp*)" uniquemember dn: cn=grp0,ou=dswinsync,dc=passsync,dc=com uniquemember: uid=AD_ONLY,ou=dswinsync,dc=passsync,dc=com 3) Change the member attribute in AD to a real user that is synced over $ ldapmodify -c -x -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldap://win2k8.adrelm.com << EOF > dn: CN=grp0,CN=Users,DC=adrelm,DC=com > changetype: modify > replace: member > member: CN=AD_AND_DS,CN=Users,DC=adrelm,DC=com > > EOF modifying entry "CN=grp0,CN=Users,DC=adrelm,DC=com" 4) MOD is synced over to DS $ ldapsearch -LLL -H ldap://localhost:1189 -D "cn=Directory Manager" -w Secret123 -x -b dc=passsync,dc=com "(cn=grp*)" uniquemember dn: cn=grp0,ou=dswinsync,dc=passsync,dc=com uniquemember: uid=AD_AND_DS,ou=dswinsync,dc=passsync,dc=com Hence marking as VERIFIED. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1385.html |