Michael Ströder wrote: > Today I made a strange observation tested with release 2.4.32 and git-build > RE24 6f33e2c both with same results. > > But when requesting to use the authz-DN with which the Samba demon binds the > attribute is not shown which one might consider an ACL issue. Note that > sambaNTPassword is explicitly requested just like Samba correctly does it: > > # ldapsearch -LLL -X "dn:uid=samba_dc_1,ou=samba,o=example" > "(&(objectclass=sambaSamAccount)(uid=wtester))" sambaNTPassword > SASL/EXTERNAL authentication started > SASL username: dn:uid=samba_dc_1,ou=samba,o=example > SASL SSF: 0 > dn: employeeNumber=42424242,ou=users,o=example > > But then I would expect this search also *not* to return attribute > 'sambaNTPassword' but it does! > > # ldapsearch -LLL -X "dn:uid=samba_dc_1,ou=samba,o=example" > "(&(objectclass=sambaSamAccount)(uid=wtester))" "*" |grep -i sambaNTPassword > SASL/EXTERNAL authentication started > SASL username: dn:uid=samba_dc_1,ou=samba,o=example > SASL SSF: 0 > sambaNTPassword: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > Maybe I'm doing something wrong on the command-line but I simply > don't get it... :-/ > > Or is there some difference in ACL handling based on SearchRequest.attributes > (AttributeSelection)? > > I have an ACL which blocks access to password attributes of disabled users by > using a filter-based ACL. Hmm, I did not try what happens when explicitly > requesting the attribute used in the filter. I have to do that tomorrow... This seems to be a bug: http://www.openldap.org/its/index.cgi?findid=7495 Any chance to see a fix for this in 2.4.34? Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature