Michael Ströder wrote:
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.
access to dn.subtree="o=example" attrs=sambaNTPassword filter="(organizationalStatus=0)" by group="uid=samba_dc,o=example" write
ldapsearch -LLL -X "dn:uid=samba_dc,o=example"
Is "uid=samba_dc,o=example" a group or an account?