Winsync OneWay fromWindows not replicate deletion

[rainolf]

Issue Description
After added winSyncWindowsFilter parameter in winsync agreement, the deletion of an entry in AD does not reflect D389

Package Version and Platform:

• Platform: Debian Bullseye
• Package and version: 389-Directory/1.4.4.11 B2021.139.1122

Steps to Reproduce
Steps to reproduce the behavior:

1. Add for example this winSyncWindowsFilter: (&(objectCategory=Person)(sAMAccountName=*)(memberOf=CN=Portal Users,OU=Groups,DC=lab,DC=local))
2. Try to delete a synced entry in AD
3. The corresponding entry in D389 will not be deleted

Expected results
Expected deletion as for winSyncWindowsFilter is not set

[Firstyear]

@rainolf I have resolved the issue in #5052, but in general I think you will encounter a lot of problems trying to use the MemberOf filter like this, since we can not accurately determine an entry needing to be deleted due to removal from a group.

Consider the situation we have user X and group Y, which X is memberOf. When you remove X from Y, the memberOf will no longer show, but the entry for user X is not now in the isDeleted state, meaning it will persist on the 389-ds side.

This is a limitation of the AD sync state that we consume, so we can not easily or effectively work around it.

[rainolf]

Sure, i agree with you but how we can have more control on this?
Consider the fact that anyone would sync only a subset of AD users that is placed in a existing structure.
In a real scenario it is quite difficult to place all users in a single OU due to the needs to apply different Group Policies and i think i am not alone.
So, considering what you stated( i agree with you, in which other way it can be accomplish?
Thanks

[Firstyear]

Well currently the ability to sync these via a single group membership works, so that's fine. It's un-syncing when you remove them from that group that's the problem. I think that may be a seperate bug ...

[Firstyear]

@tbordaz @rainolf welcome back to the new year! I've been investigating this today to see if we could finish it off, and what I have learnt is ... well, I think that we need to actually remove win-filter as a feature.

There are a large number of race conditions in the application of the filter to windows in the way that we currently apply it.

An example, is if we have a (memberOf=somegroup). Let's say we create some user named A, and we intend to add them to the group somegroup. There are actually two possible outcomes in 389-ds.

• The addition to somegroup occurs before the next replication sync, and we retrieve A.
• The addition to somegroup occurs AFTER the next replication sync, and we DO NOT retrieve A because A didn't change - the group did!

And that's just one example! It appears that if we send any filter to winsync, regardless of the isDeleted filter is applied, we actually won't get the entries in many cases because the memberOf attributes are removed at entry deletion meaning that we can't actually perceive the isDeleted. We also can't just search 'isDeleted=*' since that's un-indexed, and has a lot of other potential issues.

So as a result, I think that filtering in this manner is actually fundamentally broken, there are too many edge cases that can occur, and you are likely (if not guaranteed) to end up with inconsistent data in your 389-ds system.

The only way to guarantee your dataset is complete is to set the basedn to the root of the AD environment LDAP, and to have no win-filter applied. The only other option we have is to only apply filters on the client side of 389-ds when we receive entries, rather than applying them to the winsync search, but that has a lot of potential for other issues.

IMO there is no easy fix here .... :(