Quanah Gibson-Mount quanah@fast-mail.org schrieb am 23.02.2022 um 17:46
in Nachricht <930DB73AD6C9D8388B3A80F5@[192.168.1.12]>:
--On Wednesday, February 23, 2022 8:25 AM +0100 Ulrich Windl Ulrich.Windl@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