Hi Shawn

After closely inspecting both/all entries with slapcat on each of the servers I confirmed that all the user entries are being replicated -except- for the userPassword one.

So it looks like we found the issue.

Question is how to fix it, why is it not replicating the userPassword attribute?

I have removed my filter entry from my olcSyncrepl, now it looks like this

olcSyncrepl: {0}rid=100 provider=ldap://master:389 type=refr
eshOnly interval=00:00:05:00 retry="300 +" searchbase="dc=metrocast,dc=net" t
imelimit=unlimited sizelimit=unlimited bindmethod=simple binddn="cn=repl,ou=boxes,dc=metrocast,dc=net" credentials="aaa" starttls
=critical tls_cacertdir="/etc/ldap/certs"

But still not replicating the userPassword attribute, any clue??

Thanks in advance

Ulises Gonzalez Horta

Lead Linux Engineer

C: 786 450 2970/ 240 727 6267

E: ugonzalezhorta@breezeline.com

On Wed, Jan 1, 2025 at 12:52 PM Shawn McKinney <smckinney@symas.com> wrote:

> On Dec 31, 2024, at 9:08 AM, Ulises Gonzalez Horta <ugonzalezhorta@breezeline.com> wrote:
>
> Hi and happy new year.
>
> I was checking to see if a bad acl could be the cause here, after enabling all logs including -1 level, I still did not get anything useful on syslog.
>
> So I went this route
> I get my slave server, removed the config for oldSyncRepl and olcUpdateref, stopped slapd, removed the database, and loaded a backup, then started slapd, then attempted the queries and it worked fine

Hello,

Have you tried slapcat on that entry on both instances, comparing the results to ensure they match?

Also, are password policies enabled?

Your earlier question about which log level for ACL's:

man slapd.conf

…

128 (0x80 ACL) access control list processing

—
Shawn