Thank you very much to all that read this thread, but especially to those
replied and provided any guidance, I/We fixed the issue, the problem was
caused by this default ACL
{0}to attrs=userPassword by self write by anonymous auth by * none
It default "stop" was avoiding that my replication user read the
userPassword attribute for other users, hence the attribute was not being
replicated, and for some reason if that attribute is not present and you
try to authenticate a user then slapd does not produce too many logs, it
only returns error 49.
Thank you all and happy new year
Ulises Gonzalez Horta
Lead Linux Engineer
C: 786 450 2970/ 240 727 6267
E: [email protected] <[email protected]>
On Thu, Jan 2, 2025 at 11:59 AM Stefan Kania <[email protected]> wrote:
> Did you test the access to the attribute with slapacl? "slapacl -D
> dn=search-user,ou=users... -b cn=object-to-check,ou=.... userPassword"
>
>
> Am 02.01.25 um 15:37 schrieb Ulises Gonzalez Horta:
> > 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] <mailto:[email protected]>
> >
> >
> >
> > On Wed, Jan 1, 2025 at 12:52 PM Shawn McKinney <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >
> > > On Dec 31, 2024, at 9:08 AM, Ulises Gonzalez Horta
> > <[email protected]
> > <mailto:[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
>
