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: [email protected] <[email protected]>
On Wed, Jan 1, 2025 at 12:52 PM Shawn McKinney <[email protected]> wrote:
>
> > On Dec 31, 2024, at 9:08 AM, Ulises Gonzalez Horta <
> [email protected]> 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
