Re: sasl/plain with hashed password not working

[btb@bitrate.net]

On Oct 8, 2013, at 09.56, Dan White <dwhite@olp.net> wrote:

> 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.

ah, i see.  a brief test here [cyrus sasl 2.1.25] seems to support your belief.  i did not test against sasldb or sql, but no success against slapd.  it's interesting though - i'll hope for maybe some further cultivation in the future :)

>> 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.

maybe i've overlooked something in my experimentation?  with 'pwcheck_method: auxprop', the behavior seems quite clear.  with olcauthzregexp, a test with ldapwhoami works:

>ldapsearch -xLLLH 'ldap://aurora.example.com/' -D 'cn=admin,dc=example,dc=com' -w 'xxxxxxxx' -b 'cn=config' -s base
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /opt/openldap/var/run/slapd.args
olcLogLevel: any
olcPidFile: /opt/openldap/var/run/slapd.pid
olcSaslSecProps: noanonymous
olcAuthzRegexp: {0}uid=([^,]*),cn=digest-md5,cn=auth uid=$1,ou=people,ou=accou
 nts,dc=example,dc=com

>ldapwhoami -H 'ldap://aurora.example.com/' -Y 'digest-md5' -U 'flash' -w 'xxxxxxxx'
SASL/DIGEST-MD5 authentication started
SASL username: flash
SASL SSF: 128
SASL data security layer installed.
dn:uid=flash,ou=people,ou=accounts,dc=example,dc=com

without olcauthzregexp, a test with ldapwhoami fails, as expected:

>ldapwhoami -H 'ldap://aurora.example.com/' -Y 'digest-md5' -U 'flash' -w 'xxxxxxxx'
SASL/DIGEST-MD5 authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
	additional info: SASL(-13): user not found: no secret in database

but when using 'pwcheck_method: saslauthd' [and 'mech_list: plain'], a test with ldapwhoami succeeds, even without olcauthzregexp:

>ldapsearch -xLLLH 'ldap://aurora.example.com/' -D 'cn=admin,dc=example,dc=com' -w 'xxxxxxxx' -b 'cn=config' -s base
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /opt/openldap/var/run/slapd.args
olcLogLevel: any
olcPidFile: /opt/openldap/var/run/slapd.pid
olcSaslSecProps: noanonymous

>ldapwhoami -H 'ldap://aurora.example.com/' -Y 'plain' -U 'flash' -w 'xxxxxxxx'
SASL/PLAIN authentication started
SASL username: flash
SASL SSF: 0
dn:uid=flash,cn=plain,cn=auth

>> 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.

at the moment, i'm using git master from about a month ago:

>./slapd -V
@(#) $OpenLDAP: slapd 2.X (Sep 11 2013 19:58:01) $
	root@aurora:/root/openldap/master/servers/slapd

> 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.

i may not be following - if i explicitly set 'pwcheck_method: saslauthd', yet offer a shared secret mech, that config directive will be ignored and act as though pwcheck_method: auxprop is set if the shared secret mech is used?  i guess that makes sense, since such a config would be contradictory?

nonetheless, in my test case, i'm using only plain ['mech_list: plain' and 'olcSaslSecProps: noanonymous'].  the rootdse corroborates this, showing only an offering of plain:

>ldapsearch -xLLLH 'ldap://aurora.example.com/' -s base -b '' 'supportedSASLMechanisms'
dn:
supportedSASLMechanisms: PLAIN

but i still see the auxprop messages being logged.

>> 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.

i've tried both with olcSaslAuxprop omitted, and explicitly specifying a value of 'slapd' - neither seems to have an impact on the log messages.

> 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'

using these dummy options does suppress the log messages, but i'd like to learn what i'm doing wrong if only the slapd plugin is supposed to be in use to begin with.

-ben