olcRootDN: cn=Manager,dc=van,dc=company,dc=com olcRootPW:: e1NTSEF9cEpWbEIzOEh4UXJpcjnvSUl2enZzWTF1akt4Nnd6OTk=
You should change that password now, since you just shared its SSHA hash to the world ;)
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by dn.ba se="cn=Manager,dc=van,dc=company,dc=com" write by * none olcAccess: {1}to * by self write by dn="cn=Manager,dc=van,dc=company,dc= com" write by * read
It depends how your replica is connecting as. The above means that only cn=Manager and the user itself can read userPassword. Also note that since cn=Manager is also the rootdn, you don't need to add an ACL for it.
The second ACL also means that a user can change any of his/her own attributes (to * by self write), I'm not sure that is wise as I haven't seen what's in those entries. But if you are using RFC2307 and have attributes like uidNumber and gidNumber, it means the user can change the uidNumber and gidNumber to 0, for example, and become root on the machine that is using this directory as an NSS source for passwd and shadow.
entryCSN: 20200504150528.806636Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20200504150528Z
Now I found on the slave(ldap-03) all userPassword attributes is disappeared. So I think the ACL may blocked the replication. I think I need add the replication user (rpuser) to the ACL on the master and allow the rpuser read(or RW?) access.
Ah, now I saw this bit. Yes, you need to add the replication user to the acls to allow reading all attributes you want replicated, and also change the limits for that user so that it is not hampered by time and size limits.