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 Fri, Jan 3, 2025 at 4:24 AM Windl, Ulrich <[email protected]> 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 <[email protected]>
> *Sent:* Friday, December 27, 2024 8:22 PM
> *To:* Quanah Gibson-Mount <[email protected]>
> *Cc:* [email protected]
> *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:* [email protected] <[email protected]>
>
>
>
>
>
>
>
> On Fri, Dec 27, 2024 at 2:09 PM Quanah Gibson-Mount <[email protected]>
> wrote:
>
>
>
> --On Friday, December 27, 2024 10:34 AM -0500 Ulises Gonzalez Horta
> <[email protected]> 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=*[email protected])
>
> 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
>
>
