>> Quanah Gibson-Mount <quanah(a)fast-mail.org> schrieb am
23.02.2022 um 17:46
in
Nachricht <930DB73AD6C9D8388B3A80F5(a)[192.168.1.12]>:
--On Wednesday, February 23, 2022 8:25 AM +0100 Ulrich Windl
<Ulrich.Windl(a)rz.uni-regensburg.de> wrote:
>>>> Yes, if you query the right place. I.e., cn=subschema:
>>>>
>>>> ldapsearch ... ‑s base ‑b "cn=subschema" +
>>>
>>> When I try that I get "No such object", and when I try
>>
>> Then you used a bind identity that doesn't have access to cn=subschema.
>> Generally it is advised that cn=subschema should be readable by anyone.
>
> I have this in "dn: olcDatabase={-1}frontend,cn=config":
> olcAccess: {0}to dn.exact="" by * read
> olcAccess: {1}to dn.base="cn=Subschema" by * read
>
> Shouldn't that do?
Generally yes, but your stated results would indicate otherwise.
I don't get it: The ACL is there, and the subschema seems to be there, but I
cannot find it.
In Perl the root_dse indicates:
...
6 HASH(0x2d49578)
'type' => 'subschemaSubentry'
'vals' => ARRAY(0x2d49800)
0 'cn=Subschema'
...
So it seems to be there. Likewise when I diesplay the "schema" entry I get:
'userpassword' => HASH(0x2e483b0)
'aliases' => ARRAY(0x2e48440)
empty array
'desc' => 'RFC4519/2307: password of user'
'equality' => 'octetStringMatch'
'max_length' => 128
'name' => 'userPassword'
'oid' => '2.5.4.35'
'syntax' => '1.3.6.1.4.1.1466.115.121.1.40'
'type' => 'at'
So my guess is that my query is still wrong:
# ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=Subschema' -s sub
'(objectClass=*)' '* +'
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <cn=Subschema> with scope subtree
# filter: (objectClass=*)
# requesting: * +
#
# search result
search: 2
result: 32 No such object
# numResponses: 1
------------------
Regards,
Ulrich