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

On Wed, Jan 1, 2025 at 12:52 PM Shawn McKinney smckinney@symas.com wrote:

...

On Dec 31, 2024, at 9:08 AM, Ulises Gonzalez Horta <

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

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

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 ugonzalezhorta@breezeline.com Sent: Thursday, January 2, 2025 6:57 PM To: Stefan Kania stefan@kania-online.de Cc: openldap-technical@openldap.org 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: ugonzalezhorta@breezeline.commailto:jsutherland1@breezeline.com

On Thu, Jan 2, 2025 at 11:59 AM Stefan Kania <stefan@kania-online.demailto: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.commailto:E%3Augonzalezhorta@breezeline.com <mailto:jsutherland1@breezeline.commailto:jsutherland1@breezeline.com>

On Wed, Jan 1, 2025 at 12:52 PM Shawn McKinney <smckinney@symas.commailto:smckinney@symas.com <mailto:smckinney@symas.commailto:smckinney@symas.com>> wrote:

 > On Dec 31, 2024, at 9:08 AM, Ulises Gonzalez Horta
<ugonzalezhorta@breezeline.com<mailto:ugonzalezhorta@breezeline.com>
<mailto: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

--On Friday, January 3, 2025 8:49 AM -0500 Ulises Gonzalez Horta ugonzalezhorta@breezeline.com wrote:

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

That's not what result code 49 means.

--Quanah

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 Fri, Jan 3, 2025 at 4:24 AM Windl, Ulrich u.windl@ukr.de wrote:

Hi!

I used slapacl to test the ACLs; for example

slapacl -v -d none \

-D 'uid=PP-Checker,…' \

-b 'uid=windl,…' \

'pwdPolicySubentry/read' \

'shadowMax/read' \

'pwdLastChange/read'

It says something like this:

read access to pwdPolicySubentry: ALLOWED

read access to shadowMax: ALLOWED

slap_str2ad(pwdLastChange) failed 17 (Undefined attribute type)

Kind regards,

Ulrich Windl

*From:* Ulises Gonzalez Horta ugonzalezhorta@breezeline.com *Sent:* Friday, December 27, 2024 8:22 PM *To:* Quanah Gibson-Mount quanah@fast-mail.org *Cc:* openldap-technical@openldap.org *Subject:* [EXT] Re: Replication issues with openldap 2.5

Thanks for replying, from what I see in your answer, I have already distracted a and b, I can say c is also ruled out but I would like to double check it, maybe acls are not processing in the expected order. What is the best way to troubleshoot acls?? Any recommended log level?

*Ulises Gonzalez Horta*

*Lead Linux Engineer*

*C: 786 450 2970/ 240 727 6267*

*E:* ugonzalezhorta@breezeline.com jsutherland1@breezeline.com

On Fri, Dec 27, 2024 at 2:09 PM Quanah Gibson-Mount quanah@fast-mail.org wrote:

--On Friday, December 27, 2024 10:34 AM -0500 Ulises Gonzalez Horta ugonzalezhorta@breezeline.com wrote:

...

Good morning

I am trying to setup a replication in ldap 2.5, using syncrepl, I have a provider server and a consumer, both of the servers are running 2.5.11 from Ubuntu 22.04, I followed the admin guide chapter 18.3.1 to do the configuration. I have some information on the provider that is successfully being replicated to the consumer without any errors

Consumer configuration ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config olcSyncRepl olcUpdateref dn: olcDatabase={1}mdb,cn=config olcSyncrepl: {0}rid=100 provider=ldap://provider:389 type=refr eshOnly interval=00:00:05:00 retry="300 +" searchbase="dc=metrocast,dc=net" f ilter="(|(entryDN:=dc=metrocast,dc=net)(entryDN:dnOneLevelMatch:=dc=met

Why do you have such a complicated filter?

...

On the consumer this same query returns error 49

ldapsearch -Z -LLL -H ldap://providert:389 -D "uid=user1,ou=employees,dc=metrocast,dc=net" -W -b "ou=employees,dc=metrocast,dc=net" "(mail=*pepe@breezeline.com)

Either:

a) The user entry doesn't exist b) The user entry is missing the userPassword attribute c) The ACLs don't allow anonymous "auth" access on the userPassword attribute

--Quanah