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 jsutherland1@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