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: ugonzalezhorta@breezeline.com

 



On Thu, Jan 2, 2025 at 11:59 AM Stefan Kania <stefan@kania-online.de> 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:ugonzalezhorta@breezeline.com <mailto:jsutherland1@breezeline.com>
>
>
>
> On Wed, Jan 1, 2025 at 12:52 PM Shawn McKinney <smckinney@symas.com
> <mailto:smckinney@symas.com>> wrote:
>
>
>      > On Dec 31, 2024, at 9:08 AM, Ulises Gonzalez Horta
>     <ugonzalezhorta@breezeline.com
>     <mailto: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