Hi!

I am using the cn=admin,o=infra,c=com with correct password to connect. I will further check ACLs! Thank you for that suggestion.

Just to make things more concrete, below are two samples. One on the MASTER with contextCSN, and one from the SLAVE without contextCSN.

EXAMPLE SLAVE:
ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b "o=infra,c=com" -s base contextCSN
# extended LDIF
#
# LDAPv3
# base <o=infra,c=com> with scope baseObject
# filter: (objectclass=*)
# requesting: contextCSN
#

# search result
search: 2
result: 0 Success

# numResponses: 1

EXAMPLE MASTER:
ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b "o=infra,c=com" -s base contextCSN
# extended LDIF
#
# LDAPv3
# base <o=infra,c=com> with scope baseObject
# filter: (objectclass=*)
# requesting: contextCSN
#

# infra, com
dn: o=infra,c=com
contextCSN: 20180917142109.765066Z#000000#000#000000
contextCSN: 20230612144901.796553Z#000000#001#000000
contextCSN: 20230612144904.899482Z#000000#002#000000

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

On Mon, 12 Jun 2023 at 16:42, Quanah Gibson-Mount <quanah@fast-mail.org> wrote:

--On Monday, June 12, 2023 5:36 PM +0200 cYuSeDfZfb cYuSeDfZfb
<cyusedfzfb@gmail.com> wrote:

> Hi Quanah,
>
> Thanks for the swift reponse! I think I do, yes, see, from consumer one:
>
> olcSyncrepl: {0}rid=202
> provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple
> filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory
> Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com"
> schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+"
> starttls=critical tls_reqcert=demand
> olcSyncrepl: {1}rid=201
> provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple
> filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory
> Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com"
> schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+"
> starttls=critical tls_reqcert=demand
> olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389
> olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389

That's syncrepl, not syncprov.

However, the issue could be ACLs.  If you use the rootdn for your database
to run the query, can you see the contextCSN value stored in your database
root?

--Quanah