Re: sasl/plain with hashed password not working

[Dan White <dwhite@olp.net>]

On 10/07/13 21:49 -0400, btb@bitrate.net wrote:
> On Oct 2, 2013, at 09.44, Dan White <dwhite@olp.net> wrote:
>
> > libsasl2, with default configuration, requires that the password be stored
> > in cleartext, even for PLAIN.
> >
> > To support {ssha} in this scenario, I recommend you configure your SASL
> > slapd.conf file to authenticate against saslauthd, which in turn should be
> > configured to perform ldap simple (non-sasl) authentication against slapd.
> > Think of it as a two-level deep recursive authentication.
> >
> > Create a slapd.conf SASL file (e.g. /usr/lib/sasl2/slapd.conf) with these
> > contents:
> >
> >  pwcheck_method: saslauthd
> >  # Disallow shared secret mechanisms
> >  mech_list: PLAIN LOGIN GSSAPI EXTERNAL
>
> thanks, this worked.  though the slapd/sasl recursive auth was a bit of a
> brain teaser to get straight in my head, if i'm honest.  :)
>
> a few follow up questions, if i may.
>
> i'd like to, just for the sake of my own edification, understand the
> internal bits a little better.  having gone through this exercise, if i
> understand correctly now, when a client connects to slapd and uses sasl,
> slapd hands over [so to speak] the authentication portion to libsasl2 in
> almost the same way any other server software which might be using
> libsasl2 does - even though slapd is likely to ultimately be the source of
> the authentication data?  the one notable difference being that when the
> libsasl2 is used in its default state [e.g. pwcheck_method: auxprop],
> slapd knows to include/use a "special" internal auxprop module
> [auxprop_plugin: slapd - i see this referenced in doc/options.html].  this
> in turn allows slapd to, in essence, work "internally" to itself, but
> still within the constraints of libsasl2?

Right. libsasl2 authenticates, and the slapd auxprop plugin uses ldap
as a database to retrieve authentication data (on behalf of libsasl2).

> that came out a bit long winded, but i'm hoping i have the essence straight.
>
> you mention "libsasl2, with default configuration, requires that the
> password be stored in cleartext, even for PLAIN.".  was that just
> referring to the default of pwcheck_method: auxprop, or is there some
> scenario in which pwcheck_method: auxprop could be made to somehow handle
> hashed password values?

That was referring to auxprop. In newer versions (> 2.1.23) of Cyrus SASL
there is an undocumented 'pwcheck_method: auxprop-hashed' which you can use
to support hashed passwords, but I do not believe that slapd/ldapdb are
supported. I assume the hash is either salted or unsalted md5. You would
need to use the sasldb or sql auxprops to make use of it.

> regarding using saslauthd in the mix with slapd/libsasl2, it seems that
> perhaps olcauthzregexp does not really apply any longer in this scenario?
> slapd does not need to itself canonicalize the username, as that work is
> done by the saslauthd ldap auth mechanism?  removing the olcauthzregexp
> elements from my config seems to confirm this, but i'm wondering if there
> are other effects i've not considered.

saslauthd does not preform any canonicalization. You'll still use
olcauthzregexp for that.

With libsasl2, authentication and canonicalization are independent.
Regardless of the authentication method (gssapi/saslauthd/etc),
olcauthzregexp is still used to canonicalize the username to a DN.

> lastly, i'm curious about some logging i see going to the syslog auth
> facility.  when using pwcheck_method: saslauthd, i see the following
> logged when starting slapd:
>
> Oct  7 21:26:12 aurora slapd[20228]: DIGEST-MD5 common mech free
> Oct  7 21:26:14 aurora slapd[20240]: auxpropfunc error invalid parameter supplied
> Oct  7 21:26:14 aurora slapd[20240]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb
> Oct  7 21:26:14 aurora slapd[20240]: canonuserfunc error -7
> Oct  7 21:26:14 aurora slapd[20240]: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb
> Oct  7 21:26:14 aurora slapd[20240]: sql_select option missing
> Oct  7 21:26:14 aurora slapd[20240]: auxpropfunc error no mechanism available
> Oct  7 21:26:14 aurora slapd[20240]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql
>
> i understand from reading various ml discussions that those messages are
> largely innocuous, but was curious nonetheless why messages that seem to
> be related to auxprop appear if i've explicitly specified saslauthd.  is
> auxprop still being used in some capacity?

What version of slapd are you running? Newer versions should default to
only loading the slapd auxprop. You can include:

auxprop_plugin: slapd

if running an older version. But yes, they are innocuous.

Be aware that even if you have 'pwcheck_method: saslauthd' configured, that
configuration only affects PLAIN/LOGIN. Auxprop is still used for shared
secret mechanisms such as DIGEST-MD5.

> similarly, before using saslauthd, when initially testing using
> pwcheck_method: auxprop, and setting auxprop_plugin: slapd, as per
> doc/options.html, i expected to no longer see the complaints about sql and
> ldapdd, yet they still appear.  are my expectations regarding this
> off-base?

No, that would be my expectation as well. Verify your olcSaslAuxprop
configuration. In newer versions slapd just ignores your 'auxprop_plugin'
option and uses olcSaslAuxprop instead, which defaults to slapd.

Another way to get rid of those log entries is to include dummy options for
them:

ldapdb_uri: ldapi:///
sql_select: SELECT %p FROM user_table WHERE username = '%u' and realm = '%r'

--
Dan White