A RDN can contain ASTERISK without the need to escape it ( https://www.ietf.org/rfc/rfc4514.txt). So 'uid=asterisk_*_in_value,ou=People,dc=example,dc=com' is a valid DN

A ldapclient search filter should escape ASTERISK it its filter (https://tools.ietf.org/html/rfc4515#section-3). Only 'subtstring' item can contain ASTERISK. So it is normal that item "uid=asterisk_*_in_value" is treated as a subtring (any) filter.
If a '*' is present is an assertion it should be escaped

========================================

   For AssertionValues that contain UTF-8 character data, each octet of
   the character to be escaped is replaced by a backslash and two hex
   digits, which form a single octet in the code of the character.  For
   example, the filter checking whether the "cn" attribute contained a
   value with the character "*" anywhere in it would be represented as
   "(cn=*\2a*)".

...

The following examples illustrate the use of the escaping mechanism.

        (o=Parens R Us \28for all your parenthetical needs\29)
        (cn=*\2A*)
        (filename=C:\5cMyFile)
        (bin=\00\00\00\04)
        (sn=Lu\c4\8di\c4\87)
        (1.3.6.1.4.1.1466.0=\04\02\48\69)

   The first example shows the use of the escaping mechanism to
   represent parenthesis characters.  The second shows how to represent
   a "*" in an assertion value, preventing it from being interpreted as
   a substring indicator.  The third illustrates the escaping of the
   backslash character.
========================================


Is it possible for the ldapclient to change the filter it requests and transforms '*' into '\2a'. ?

The ldapclient is 'replication plugin' itself !!!

The case identified internal searches with filter "(&(objectclass=nstombstone)(nscpentrydn=<entryDN))" (during ADD). So this is a bug in replication plugin that uses filter assertion without appropriate escaping. Changing the BZ title to reflect that.

upstream ticket https://pagure.io/389-ds-base/issue/51244

Fix pushed upstream => POST

============================================================================================================ test session starts =============================================================================================================
platform linux -- Python 3.6.8, pytest-6.1.1, py-1.9.0, pluggy-0.13.1 -- /usr/bin/python3
cachedir: .pytest_cache
metadata: {'Python': '3.6.8', 'Platform': 'Linux-3.10.0-1160.6.1.el7.x86_64-x86_64-with-redhat-7.9-Maipo', 'Packages': {'pytest': '6.1.1', 'py': '1.9.0', 'pluggy': '0.13.1'}, 'Plugins': {'metadata': '1.10.0', 'html': '2.1.1'}}
389-ds-base: 1.3.10.2-7.1.el7_9
nss: 3.53.1-3.el7_9
nspr: 4.25.0-2.el7_9
openldap: 2.4.44-22.el7
cyrus-sasl: 2.1.26-23.el7
FIPS: disabled
rootdir: /workspace/ds/dirsrvtests, configfile: pytest.ini
plugins: metadata-1.10.0, html-2.1.1
collected 15 items / 14 deselected / 1 selected                                                                                                                                                                                              

tests/suites/replication/acceptance_test.py::test_urp_trigger_substring_search PASSED                                                                                                                                                  [100%]

========================================================================================== 1 passed, 14 deselected in 61.24s ================================================================================================================

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 (389-ds-base bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:5041