RE: saslauxprop and libldapdb, auxpropfunc error -7

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

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Joe Rhodes

> >>My imap.conf file is as so (per previous
> >> recommendations):
> >> configdirectory: /var/imap
> >> partition-default: /var/spool/imap
> >> admins: cyrus root
> >> sasl_pwcheck_method: auxprop
> >> sasl_auxprop_plugin: ldapdb
> >> sasl_ldapdb_uri: ldap://127.0.0.1
> >> sasl_ ldapdb_id:  admin
> >> sasl_ ldapdb_pw:  password
> >> sasl_ ldapdb_mech: PLAIN

> > This should work, I assume extra spaces is just a typo.

> Actually, no, my plugin is NOT contacting the server, running on the
> same host.  I've tried using both
> sasl_ldapdb_uri: ldapi://
> and
> sasl_ldapdb_uri: ldap://127.0.0.1
>
> As of yet, I have not been able to get the Cyrus SASL plugin to query
> the server at all.  I'm running slapd with debug of 256.
> This seems to
> splash plenty of info in the console window anytime an application
> queries it (say, Netscape Mail, for instance).
>
> Which are the extra spaces you speak of?

The extra spaces in your "sasl _ldapdb_id" etc. lines in the config you
posted above.

> Is there some way to get more error messages out of the auxprop plugin?
>   Perhaps if I could see what it thinks it has for arguments, what it's
> trying to do when it fails, etc.  Right now all I have is that it
> doesn't contact OpenLDAP and can't find the user [SASL (-13)user not
> found:  checkpass failed]
>
> Up to this point, I've applied the patches Howard Chu offered earlier
> to get rid of the "auxpropfunc error -7" messages.  I no longer get
> that message when an SASL-enabled server tries to use the auxprop
> plugin.
>
> Have others gotten this to work?  If they have, then I must be missing
> something here.  Once I do (if I do) get this working, I intend to
> document the adventure.  I'd guess that this would be pertinent to
> others that use similar software (sendmail and Cyrus IMAP) who want to
> use a more secure method of password exchange/authentication.
>
> Thanks for everyone's help thus far.

When you tried using "ldapi://" did you actually have your slapd listening
via ldapi? If not, then of course that's not going to work. Also, when you
specify "-h ldapi://" on slapd to have it listen over Unix domain sockets, it
creates the socket with permission bits 0700 by default. So unless you change
that explicitly, your clients may not have access to connect to the socket.

Use ldapsearch with the same arguments and see if it works. Assuming you
don't have any typos in your config file, and given that you've patched your
SASL library, there's no reason to suspect any more issues there.

For the example of
	sasl_ldapdb_uri: ldap://127.0.0.1
	sasl_ldapdb_id: admin
	sasl_ldapdb_pw: password
	sasl_ldapdb_mech: DIGEST-MD5

this corresponding command must work first:
	ldapsearch -H ldap://127.0.0.1 -U admin -w password -Y DIGEST-MD5

If you're using
	sasl_ldapdb_uri: ldapi://
	sasl_ldapdb_mech: EXTERNAL

this command must work:
	ldapsearch -H ldapi:// -Y EXTERNAL

If the ldapsearch commands fail, run them with debugging enabled (e.g., -d7)
to see what fails.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support