>>> Quanah Gibson-Mount <[email protected]> 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 > <[email protected]> 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
