Re: sasl/plain with hashed password not working

[btb@bitrate.net]

On Oct 10, 2013, at 09.49, Dan White <dwhite@olp.net> wrote:
> 
> slapd internally assigns an identity after SASL authentication is
> successful. ldapwhoami will still succeed without an olcauthzregexp, but
> will simply point to the generated "pseudo" dn, rather than an actual entry
> in your tree (unless you have actually created a cn=auth database).

apologies.  i somehow became blind to the dn: string being returned from ldapwhoami in my comparisons.

>>> 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.
> 
> I'm not sure that you are. I suppose a better solution is to remove the
> ldapdb and sql (and sasldb) shared libraries from your system, in which
> case they'll never be loaded in to memory.

i did consider this, but that prohibits other programs from using those plugins.  i know this is largely an academic exercise at this point, but i'm curious about the theory.  based on your insight, and my testing, would it be accurate to say that the nuance is that "load" and "use" are not the same thing?  e.g. sasl "loads" [or maybe there's a better term?] all of the auxprop plugins it can find, but then only "uses" the plugins defined by auxprop_plugin?

-ben