[Date Prev][Date Next]
FW: Storing SASL secrets in the directory
Some issues here... The code in passwd_extop only allows the operation to
if (conn->c_authz_backend is non-NULL and this backend supports extended ops)
(conn->c_authz_backend is NULL and we have SASL).
I think this test is in the wrong place, it assumes the extop is only trying
change the password of the bound user, but the extop can specify a target DN
change which may not be the bound user. So the check for c_authz_backend
belongs after the req has been parsed, to see if a target DN was given, or if
they're just trying to change their own password.
And, none of the in-directory SASL code is doing ACL checks anywhere. For
do we just want to check ACL_AUTH on everything we lookup? The code that
currently uses backend_attribute will have to be rewritten to do an internal
search, since the actual entry is needed for access_allowed().
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support
From: Andrew Findlay [mailto:firstname.lastname@example.org]
If I specify the DN of the entry I want to change then the error is
$ ldappasswd -S -C -U u000997 "cn=Andrew
Re-enter new password:
SASL/DIGEST-MD5 authentication started
Please enter your password:
SASL username: u000997
SASL SSF: 128
SASL installing layers
Result: DSA is unwilling to perform (53)
Additional info: user must change own password
This suggests to me that the server is not applying saslRegexp when
handling the exop.