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

TEst query
ldapsearch -ZZ -x -LLL -H ldap://slave:389 -D "cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net" -w aaa -b "ou=employees,dc=metrocast,dc=net"

ldapsearch -ZZ -LLL -H ldap://slave:389 -D "uid=user,ou=employees,dc=metrocast,dc=net" -W -b "ou=employees,dc=metrocast,dc=net"

Then stopped slapd, removed the database /var/lib/ldap, start slapd and put back the olcSyncRepl config, waited for replication then attempted the queries same again and got error 49

This proves that this is not an ACL issue, in both cases the binding user for the queries are present on the database with the exactly the same fields

I noticed that same server with the same level of olcLoglevel it it produces more logs as master than as slave

As master
(...)
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: conn=1004 op=1 do_bind
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: >>> dnPrettyNormal: <cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net>
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: <<< dnPrettyNormal: <cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net>, <cn=boxreadgeneric,ou=boxes,dc=metrocast,dc=net>
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: conn=1004 op=1 BIND dn="cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net" method=128
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: do_bind: version=3 dn="cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net" method=128
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: ==> mdb_bind: dn: cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: mdb_dn2entry("cn=boxreadgeneric,ou=boxes,dc=metrocast,dc=net")
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: => mdb_dn2id("cn=boxreadgeneric,ou=boxes,dc=metrocast,dc=net")
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: <= mdb_dn2id: got id=0x5
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: => mdb_entry_decode:
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: <= mdb_entry_decode
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: => access_allowed: result not in cache (userPassword)
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: => access_allowed: auth access to "cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net" "userPassword" requested
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: => acl_get: [1] attr userPassword
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: => acl_mask: access to entry "cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net", attr "userPassword" requested
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: => acl_mask: to value by "", (=0)
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: <= check a_dn_pat: self
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: <= check a_dn_pat: anonymous
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: <= acl_mask: [2] applying auth(=xd) (stop)
Dec 31 14:17:19 nm03-lab-roc1 slapd[220344]: <= acl_mask: [2] mask: auth(=xd)

(...)

--------

As slave - Only outputs this - not a line more-

Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: conn=1001 op=1 do_bind
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: >>> dnPrettyNormal: <cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net>
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: <<< dnPrettyNormal: <cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net>, <cn=boxreadgeneric,ou=boxes,dc=metrocast,dc=net>
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: conn=1001 op=1 BIND dn="cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net" method=128
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: do_bind: version=3 dn="cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net" method=128
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: ==> mdb_bind: dn: cn=BoxReadGeneric,ou=Boxes,dc=metrocast,dc=net
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: mdb_dn2entry("cn=boxreadgeneric,ou=boxes,dc=metrocast,dc=net")
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: => mdb_dn2id("cn=boxreadgeneric,ou=boxes,dc=metrocast,dc=net")
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: <= mdb_dn2id: got id=0x5
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: => mdb_entry_decode:
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: <= mdb_entry_decode
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: send_ldap_result: conn=1001 op=1 p=3
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: send_ldap_result: err=49 matched="" text=""
Dec 31 14:36:49 nm03-lab-roc1 slapd[221205]: send_ldap_response: msgid=2 tag=97 err=49

What I see from these outputs is that when configured as slave it does not lookup the userPassword attribute. Is there any explanation for log difference and for not looking for the userPassword attr?

Thanks you

Ulises Gonzalez Horta

Lead Linux Engineer

C: 786 450 2970/ 240 727 6267

E: ugonzalezhorta@breezeline.com

On Fri, Dec 27, 2024 at 2:22 PM Ulises Gonzalez Horta <ugonzalezhorta@breezeline.com> wrote:

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

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