Issue 5052 - BUG - Custom filters prevented entry deletion #5060
Conversation
Bug Description: When a custom filter was provided, entries which were deleted in AD did not have that event correctly reflected in 389-ds. This was due to the behaviour that when an entry in AD is deleted, it is marked with a "deleted" flag which the objectClass=* filter would (accidentally) collect when it did a search. However, a custom user filter being specified would in some cases (such as a memberOf filter) NOT show up the deletion since the entry was considered to have moved out of scope rather than being a full delete. Fix Description: In the case that we have a userfilter, we wrap it in an OR condition that always requests isDeleted flags so that we can correctly reflect the delete status. fixes: 389ds#5052 Author: William Brown <william@blackhats.net.au> Review by: ???
| */ | ||
| size_t buflen = 18 + strlen(userfilter); | ||
| filter = slapi_ch_calloc(1, buflen); | ||
| snprintf(filter, buflen, "(|(isDeleted=*)%s)", userfilter); |
There was a problem hiding this comment.
As I am not expert of Winsync, sorry for this dummy question.
This new filters looks a bit weird to me, because it will return all the matching entries (userfilter) and all the deleted entries. Is it what you expect or rather something like "(&(I(isDeleted=)(objectclass=))%s)".
Also are we sure that isDeleted attribute is indexed ?
There was a problem hiding this comment.
Good catch @tbordaz it looks like https://docs.microsoft.com/en-us/windows/win32/adschema/a-isdeleted is not indexed. But because of how the dirsync works, it's similar to syncrepl so it only sends us what has changed between the previous cookie and the current.
The other possible way to do this filter is:
(| (userFilter ...) (&(isDeleted=True)(userFilter ...)) )
That way we can lean on the userFilter to be indexed, but also means that we'll limit the isDeleted results to our userFilter set. What do you think?
There was a problem hiding this comment.
My understanding is that 'isDeleted' is similar to tombstone entry. So the initial filter would match all tombstones whether or not they match the userFilter.
IIUC the need, the second filter you proposed looks good to me
(| (userFilter ...) (&(isDeleted=True)(userFilter ...)) )
There was a problem hiding this comment.
@tbordaz See #5052 (comment) I think there is no way to fix this ....
There was a problem hiding this comment.
@tbordaz @Firstyear - any update on this? Thierry do you approve this after Williams remarks? Or do we still have concerns?
There was a problem hiding this comment.
Absolutely, Sorry I missed that it was pending on my update
|
Thanks @mreynolds389 and @tbordaz - I'll merge this later this week once I can do backports and builds and such :) |
Bug Description: When a custom filter was provided, entries which were deleted in AD did not have that event correctly reflected in 389-ds. This was due to the behaviour that when an entry in AD is deleted, it is marked with a "deleted" flag which the objectClass=* filter would (accidentally) collect when it did a search. However, a custom user filter being specified would in some cases (such as a memberOf filter) NOT show up the deletion since the entry was considered to have moved out of scope rather than being a full delete. Fix Description: In the case that we have a userfilter, we wrap it in an OR condition that always requests isDeleted flags so that we can correctly reflect the delete status. fixes: #5052 Author: William Brown <william@blackhats.net.au> Review by: @mreynolds389 @tbordaz
Bug Description: When a custom filter was provided, entries which were deleted in AD did not have that event correctly reflected in 389-ds. This was due to the behaviour that when an entry in AD is deleted, it is marked with a "deleted" flag which the objectClass=* filter would (accidentally) collect when it did a search. However, a custom user filter being specified would in some cases (such as a memberOf filter) NOT show up the deletion since the entry was considered to have moved out of scope rather than being a full delete. Fix Description: In the case that we have a userfilter, we wrap it in an OR condition that always requests isDeleted flags so that we can correctly reflect the delete status. fixes: #5052 Author: William Brown <william@blackhats.net.au> Review by: @mreynolds389 @tbordaz
|
Bug Description: When a custom filter was provided, entries
which were deleted in AD did not have that event correctly
reflected in 389-ds. This was due to the behaviour that when
an entry in AD is deleted, it is marked with a "deleted" flag
which the objectClass=* filter would (accidentally) collect
when it did a search. However, a custom user filter being
specified would in some cases (such as a memberOf filter)
NOT show up the deletion since the entry was considered
to have moved out of scope rather than being a full delete.
Fix Description: In the case that we have a userfilter, we
wrap it in an OR condition that always requests isDeleted
flags so that we can correctly reflect the delete status.
fixes: #5052
Author: William Brown william@blackhats.net.au
Review by: ???