As reported by Denis Cardon on the Samba mailing list (https://lists.samba.org/archive/samba/2021-November/238452.html), slightly edited here:
We have had this issue a few time today with latest 4.14 when upgrading client installations (I didn't have time to check if it was latest 4.14.10 or if it happened in some earlier version).
If you have DN strings with consecutive space characters (yeah, it shouldn't happen, but if one can do it, it will be done), then the upgrade will break a few things.
In the replication you'll get this kind of error message :
[2021/11/10 15:15:33.150632, 1] ../../source4/dsdb/repl/replicated_objects.c:904(dsdb_replicated_objects_commit)
Failed to apply records: operational_search_post_process failed for attribute 'parentGUID' - No such Base DN: CN=USERNAME Romain,OU=Sync Azure,DC=mydomain,DC=lan: Operations error
[2021/11/10 15:15:33.150754, 0] ../../source4/dsdb/repl/drepl_out_helpers.c:1184(dreplsrv_op_pull_source_apply_changes_trigger)
If you try a samba-tool dbcheck --cross-ncs, you'll may get this kind of error :
ERROR: Object CN=USERNAME Romain,OU=Sync Azure,DC=mydomain,DC=lan disappeared during check
Another symptom is that the search with an attribute (like samba-tool user show dcardon) does work, but a ldbsearch with a DN like below (beware of the two spaces) does not work
If you have this case, a reindex should fix it (it need to be run on each DC)
samba-tool dbcheck --reindex
Another option is to fix this before upgrade, or if it is already upgraded, downgrade, fix and then upgrade.
If you have the case where you have two quasi-identical entries, one with two space and one with only one (ie CN=denis cardon, and CN=denis cardon), then you have to delete one of them before re-indexing (yeah we have seen this one today also).
There seems to be a discrepancy in the way multiple spaces are handled in the index and in the DN string itself.
Note : if you recreate an entry with multiple consecutive spaces after upgrade it seems to work though...
I suspect this is due to fixes for bug 14656 which were backported in the November 2021 security release to 4.14.10 (and 4.13).
Those patches changed the way spaces are handled in searches and maybe indexes. I think they are probably correct, at least insofar as they do what the old code was trying to do.
However, for the indexes, it might be that the old index has treated values with the incorrect space collapsing, which would I think have mapped
'CN=denis cardon' to 'CN=denis ccardon', while the new code uses one space 'CN=denis cardon'. So the index doesn't match.
The real bug is this hypothesis is that the values are not being escaped first ('CN=denis\ \ cardon') for the indexing.
Before 'CN=denis cardon' and 'CN=denis ccardon' were quasi-identical pair, and we never/rarely saw it because no-one is called ccardon.