imapd + sasl + ldapdb problems

[Peter Erickson]

Dan, thanks for the response.

On Wed, Feb 05, 2014 at 09:35:49AM -0600, Dan White wrote:
> On 02/04/14?20:15?-0600, Peter Erickson wrote:
> >In hopes of requiring users login using their email address I set
> >sasl_ldapdb_canon_attr, however that resulted in the following syslog
> >messages (These same messages occur if comment out the canonuser_attr
> >options in imapd.conf as well):
> >imtest: ldapdb_canonuser_plug_init() failed in
> >sasl_canonuser_add_plugin(): invalid parameter supplied
> >imap[16385]: SQL engine 'mysql' not supported
> >imap[16385]: auxpropfunc error no mechanism available
> >imap[16385]: unable to canonify user and get auxprops
> >imap[16385]: badlogin: localhost [127.0.0.1] DIGEST-MD5 [SASL(-1):
> >generic failure: unable to canonify user and get auxprops]
> 
> You'll need to have a Cyrus SASL version > 2.1.23 installed for the ldapdb
> canonuser functionality, or you'll need to patch your existing version.

I am currently working with Cyrus SASL 2.1.26 and Cyrus imap 2.4.17
installed on FreeBSD 9-STABLE.

> Check that you have a properly installed cyrus sasl with:
> 
> ~$ cat > /tmp/pluginviewer.conf << EOF
> > ldapdb_uri: ldapi:///
> > sql_select: select please_work from the_ether
> > EOF
> ~$ SASL_CONF_PATH=/tmp /usr/sbin/saslpluginviewer -a
> Installed and properly configured auxprop mechanisms are:
> ldapdb sql sasldb
> List of auxprop plugins follows
> Plugin "ldapdb" ,       API version: 8
>          supports store: yes
> 
> Plugin "sql" ,  API version: 8
>          supports store: yes
> 
> Plugin "sasldb" ,       API version: 8
>          supports store: yes

# pluginviewer -a
Installed and properly configured auxprop mechanisms are:
ldapdb sasldb
List of auxprop plugins follows
Plugin "ldapdb" , 	API version: 8
	supports store: yes

Plugin "sasldb" , 	API version: 8
	supports store: yes

> ~$ SASL_CONF_PATH=/tmp /usr/sbin/saslpluginviewer -s | grep -i 'cram-md5\|digest-md5'
>    GSSAPI DIGEST-MD5 EXTERNAL CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS
>    GSSAPI DIGEST-MD5 CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS
>          SASL mechanism: DIGEST-MD5, best SSF: 128, supports setpass: no
>          SASL mechanism: CRAM-MD5, best SSF: 0, supports setpass: no

# pluginviewer -s | grep -i 'cram-md5\|digest-md5'
  SCRAM-SHA-1 DIGEST-MD5 EXTERNAL OTP CRAM-MD5 NTLM LOGIN PLAIN ANONYMOUS
  SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN ANONYMOUS
	SASL mechanism: DIGEST-MD5, best SSF: 128, supports setpass: no
	SASL mechanism: CRAM-MD5, best SSF: 0, supports setpass: no

> ~$ strings /usr/lib/x86_64-linux-gnu/sasl2/libldapdb.so.2 | grep canon
> ldapdb_canonuser_plug_init
> sasl_canonuser_init
> ldapdb_canon_attr

#  strings /usr/local/lib/sasl2/libldapdb.so.3 | grep canon
ldapdb_canonuser_plug_init
sasl_canonuser_init
ldapdb_canon_attr

> >imapd.conf:
> >configdirectory: /var/cyrus/config
> >partition-default: /var/cyrus/spool
> >admin: cyrusadmin
> >sasl_pwcheck_method: auxprop
> >sasl_auxprop_plugin: ldapdb
> >sasl_ldapdb_uri: ldaps://localhost
> >sasl_ldapdb_id: imapd-user
> >sasl_ldapdb_pw: password
> >sasl_canon_user_plugin: ldapdb
> >sasl_ldapdb_canon_attr: mail
> >sasl_mech_list: cram-md5 digest-md5
> >virtdomains: userid
> >defaultdomain: example.com
> 
> Consider that the certificate returned by ldaps://localhost may fail,
> unless the certificate used by localhost is named 'localhost', or is
> otherwise trusted. ldapi:/// may be a better option.

The ldap server is actually on a different system and works properly
with and without the SSL/TLS connection. I just replaced the actual
server with localhost to mask the real host.

> Other than that, your config looks reasonable. Include an 'ldapdb_mech'
> option to reduce confusion. sasl_ldapdb_canon_attr may need to be 'uid'
> instead, since example.com is the default domain. This command should
> succeed, and return the DN of the test user if your config is good:

Just to make sure that I'm understanding the options right, is there a
good explanation for what sasl_ldapdb_canon_attr does? I'm not quite
sure that I understand its purpose.

Based on the following, its possible that my problem isn't with cyrus
imapd/sasl, but a misunderstanding of the ldap proxy authorization
process and I need to recheck my ldap config. I'm more accustomed to
using ldap filters and a base instead of the proxy authorization.

# ldapwhoami -Y digest-md5 -U imapd-user -w password -X u:tuser -Z
SASL/DIGEST-MD5 authentication started
SASL username: u:tuser
SASL SSF: 128
SASL data security layer installed.
dn:cn=test user,o=hosted_domain,ou=hosting,dc=example.com

# ldapwhoami -Y digest-md5 -U imapd-user -w password -X u:tuser at example.com -Z
SASL/DIGEST-MD5 authentication started
ldap_sasl_interactive_bind_s: Insufficient access (50)
	additional info: SASL(-14): authorization failure: not authorized

> >example ldap entry:
> >dn: cn=test user,o=hosted_domain,ou=hosting,dc=example.com
> >objectclass: top
> >objectclass: inetOrgPerson
> >objectclass: authorizedServiceObject
> >cn: test user
> >sn: user
> >uid: tuser
> >mail: tuser at example.com
> >userPassword: password
> >authorizedService: mail
> >authorizedService: svn
> 
> -- 
> Dan White

-- 
Peter Erickson