I found something in the ACL that looks like it is the problem:
# grep -R -i olcaccess ./*
./cn=config/olcDatabase={0}config.ldif:olcAccess: {0}to * by * none
./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {0}to * by * none
./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {1}to attrs=userpassword
by anonymous auth by * none break
./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {2}to dn.base="" by * read
./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {3}to attrs=entry by *
read
./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {4}to
dn.subtree="o=ldap,c=com" attrs=objectclass,mail,givenName,sn
./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {5}to * by
dn.base="cn=mirrormode,ou=system,o=ldap,c=com"
followed by more of the same.
We are actually running slapd.conf with included files, but output above
was taken from the slapd.d directory, generated using slaptest -f
slapd.conf -F /tmp/slapd.d
The slapd.d generated dir contains olcDatabase={1}mdb.ldif:olcAccess: {0}to
* by * none *ABOVE * olcAccess: {1}to attrs=userpassword by anonymous
auth by * none break
That's probably our issue! But I can't find that line olcAccess: {0} in our
slapd.conf and the included files.
Wondering now how it got there. But... locating that is something for
another day.
You helped us again. (unless you disagree that this is most likely our
issue?)
Thanks, I will post the result after I manage to get that ACL {0} out of my
config.
On Mon, 26 Jun 2023 at 16:44, cYuSeDfZfb cYuSeDfZfb <cyusedf...@gmail.com>
wrote:
> Hi,
>
> I was preparing some more logging to show. You were *really* quick in your
> reply! :-)
>
> Below more logging, and I will reply to your ACL question next.
>
> Replication after setting the password:
>
> Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 ACCEPT from IP=
> 192.168.16.36:45316 (IP=0.0.0.0:636)
> Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 TLS established
> tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
> Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 closed
> (connection lost)
> Jun 26 16:36:09 ldapserver1 slapd[409642]: do_syncrep2: rid=234
> cookie=rid=234,sid=0dd,csn=20230626143609.891703Z#000000#0dd#000000
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_message_to_entry:
> rid=234 DN: uid=testuser,ou=Users,o=ldap,c=com, UUID:
> a8ccf30a-88d0-103d-8b70-5f35ddf1cc44
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
> csn=20230626143609.891703Z#000000#0dd#000000 tid 0x7f68a6afd640
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
> be_search (0)
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
> uid=testuser,ou=Users,o=ldap,c=com
> Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing
> 0x7f689c10e190 20230626143609.891703Z#000000#0dd#000000
> Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=-1 op=0 syncprov_matchops:
> recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com on
> opc=0x7f689c008f90
> Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1
> syncprov_matchops: skipping original sid 0dd
> Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1
> syncprov_matchops: skipping original sid 0dd
> Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
> removing 0x7f689c10e190 20230626143609.891703Z#000000#0dd#000000
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
> be_modify uid=testuser,ou=Users,o=ldap,c=com (0)
> Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing
> 0x7f689c10a010 20230626143609.891703Z#000000#0dd#000000
> Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
> removing 0x7f689c10a010 20230626143609.891703Z#000000#0dd#000000
>
> Failed authentication using the correct password:
>
> Jun 26 16:36:26 ldapserver1 slapd[409642]: conn=1164 fd=17 ACCEPT from IP=
> 192.168.16.36:46196 (IP=0.0.0.0:636)
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 TLS established
> tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 BIND
> dn="uid=testuser,ou=Users,o=ldap,c=com" method=128
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0
> syncprov_matchops: recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com
> on opc=0x7f689c008ed0
> Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_get_csn: conn=1164 op=0
> generated new csn=20230626143627.270437Z#000000#0de#000000 manage=1
> Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_queue_csn: queueing
> 0x7f689c110220 20230626143627.270437Z#000000#0de#000000
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_qresp:
> set up a new syncres mode=2 csn=20230626143627.270437Z#000000#0de#000000
> Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
> removing 0x7f689c110220 20230626143627.270437Z#000000#0de#000000
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1
> syncprov_sendresp: to=0dd,
> cookie=rid=243,sid=0de,csn=20230626143627.270437Z#000000#0de#000000
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1
> syncprov_sendresp: sending LDAP_SYNC_MODIFY,
> dn=uid=testuser,ou=Users,o=ldap,c=com
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 RESULT tag=97
> err=49 qtime=0.000015 etime=0.001002 text=
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=1 UNBIND
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 closed
>
> On Mon, 26 Jun 2023 at 16:36, Quanah Gibson-Mount <qua...@fast-mail.org>
> wrote:
>
>>
>>
>> --On Monday, June 26, 2023 5:28 PM +0200 cYuSeDfZfb cYuSeDfZfb
>> <cyusedf...@gmail.com> wrote:
>>
>> >
>> >
>> > Hi all!
>> >
>> >
>> > We have this in place:olcAccess: {1}to attrs=userpassword by anonymous
>> > auth by * none break
>>
>> It's impossible to answer this question without knowing the rest of your
>> ACLs. For example the acl in slot {0} could mean that the acl in slot
>> {1}
>> is never evaluated.
>>
>> --Quanah
>>
>>
>>
>>
