HI!
Today I made a strange observation tested with release 2.4.32 and git-build RE24 6f33e2c both with same results.
The following commands (lines wrapped herein) were all typed as user root which gets mapped by authz-regexp to the rootdn of the database o=example (LDAPI with SASL/EXTERNAL).
Let's check that:
# ldapwhoami SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:uid=admin,o=example
I wanted to check ACLs applied to attribute 'sambaNTPassword' and to test Samba logon of course. Samba logon did work when putting the Samba demon user in a special group which has read access everywhere but it didn't when the special Samba ACLs were to be applied. So I tried to examine a possible bug in my ACLs but noticed unexpected results during that.
Everything looks fine with a normal search as rootdn and we see that the entry indeed contains 'sambaNTPassword':
# ldapsearch -LLL "(&(objectclass=sambaSamAccount)(uid=wtester))" sambaNTPassword SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: employeeNumber=42424242,ou=users,o=example sambaNTPassword: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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...
Ciao, Michael.