FW: Storing SASL secrets in the directory

["Howard Chu" <hyc@highlandsun.com>]

Some issues here... The code in passwd_extop only allows the operation to
proceed
if (conn->c_authz_backend is non-NULL and this backend supports extended ops)
or
(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
to
change the password of the bound user, but the extop can specify a target DN
to
change which may not be the bound user. So the check for c_authz_backend
really
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
sasl_auxprop,
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
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support
-----Original Message-----
From: Andrew Findlay [mailto:andrew.findlay@skills-1st.co.uk]
Cc: openldap-software@OpenLDAP.org
If I specify the DN of the entry I want to change then the error is
different:

	$ ldappasswd -S -C -U u000997 "cn=Andrew
	Pathan+uid=u000997,dc=example,dc=org"
	New password:
	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.