Yeah, the error message was misleading here, error 49 is wrong password, but I knew for sure the password was right. Maybe a log entry as the one you suggested will help you fast pinpoint the issue
Ulises Gonzalez Horta Lead Linux Engineer C: 786 450 2970/ 240 727 6267 E: [email protected] <[email protected]> On Fri, Jan 3, 2025 at 4:44 AM Windl, Ulrich <[email protected]> wrote: > Hi! > > > > Makes me wonder: How much does a “no UserPassword – cannot authenticate” > error message cost, and how much time will it save? 😉 > > > > Kind regards, > > Ulrich > > > > *From:* Ulises Gonzalez Horta <[email protected]> > *Sent:* Thursday, January 2, 2025 6:57 PM > *To:* Stefan Kania <[email protected]> > *Cc:* [email protected] > *Subject:* [EXT] Re: Replication issues with openldap 2.5 {resolved} > > > > 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 > >
