digest-md5 problems with imapd, saslauthd and openldap

[Jon Wilson]

Some delving into the tangled mess that is documentation, the mailing
lists, and the Cyrus wiki, has taught me the following:

 * saslauthd can't do digest type authentications. OK, this seems
   to be a genuine design restriction

 * imapd falls back to using sasldb access if digest authentication
   is tried

 * Getting sasl to use an auxprop method that calls an LDAP server is
   possible, but tricky. Various patches exist, but are non trivial
   to install and configure.

Some other things the developers might wish to consider:

 * More debugging output IN THE LOGS when an unconfigured authetication
   mechanism is attempted, rather than falling back to sasldb.

 * Overhauling the docs, to make sure everything in the code is in the
   docs, and everything in the docs is still in the code.

 * Making saslpasswd2 work properly. I get error logs full of
   "Nov  6 09:32:54 <4.5> fermat saslpasswd2: Couldn't update db"
   and
   "Nov  6 09:32:15 <4.5> fermat imapd[15755]: no user in db"

 * Integrating the current LDAP auxprop patches into the core code

My options seem to be:

 * Not bother with digest authentication at all for now

 * Struggle with patches, and get a "auxprop" method configured that looks
   up plain text passwords from my LDAP server, and uses these in digest
   authentication

 * Write a perl script that takes my LDAP plaintext password data and
   creates sasldb entries as needed. Hack hack hackity-hack.

Advice and opinions welcome.

Jon

On Wed, 5 Nov 2003, Jon Wilson wrote:
>
> I am having trouble getting Cyrus Imapd to authenticate properly against
> an OpenLDAP database when using digest-md5 authentication.
>
> I have the following software installed on FreeBSD 4.8 (from the ports
> collection):
>
>   openldap-server-2.1.22
>   cyrus-imapd-2.1.15
>   cyrus-sasl-2.1.15
>   cyrus-sasl-saslauthd-2.1.15 (compiled with LDAP support)
>
> My imapd.conf file has the following:
>
>    sasl_pwcheck_method: saslauthd
>
> My saslauthd.conf file has:
>
>   ldap_servers: ldap://127.0.0.1/
>   ldap_bind_dn: cn=Manager,dc=mydomain,dc=com
>   ldap_bind_pw: XXXXXX
>   ldap_auth_method: custom
>   ldap_password_attr: mailPassword
>   ldap_filter: mailLocalAddress=%u
>   ldap_search_base: dc=mydomain,dc=com
>
> I start the saslauthd daemon with flags "-a ldap".
>
> A sample LDAP record looks like this:
>
> dn: cn=Jon Wilson,dc=mydomain,dc=com
> ou: employees
> cn: Jon Wilson
> mail: Jon.Wilson at mydomain.com
> givenname: Jon
> sn: Wilson
> objectClass: top
> objectClass: inetOrgPerson
> objectClass: inetLocalMailRecipient
> objectClass: mydomainPerson
> mailLocalAddress: itjpw
> mailPassword: test
>
> Essentially "mailLocalAddress" and "mailPassword" are the tokens used
> for any mail authentication. I am using them succesfully to allow
> relaying for remote authenticated users on our Exim SMTP server.
>
> Now, here's where it gets interesting. Firstly, I start both the
> saslauthd and OpenLdap's slapd in debugging mode, so I can see what is
> going on. Then I try the following:
>
>   imtest -a itjpw -m login localhost
>
> This logs me in successfully with the password 'test'. Using the
> "plain" login mechanism also works. During these tests I can see the
> saslauthd and openldap happily doing the right thing.
>
> Now I try:
>
> [itjpw at fermat itjpw]$ imtest -s -a itjpw -m digest-md5 localhost
> verify error:num=19:self signed certificate in certificate chain
> TLS connection established: TLSv1 with cipher AES256-SHA (256/256 bits)
> S: * OK mailtest.mydomain.com Cyrus IMAP4 v2.1.15 server ready
> C: C01 CAPABILITY
> S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE AUTH=NTLM AUTH=LOGIN AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5
> S: C01 OK Completed
> C: A01 AUTHENTICATE DIGEST-MD5
> S: + bm9uY2U9IlFSV3c2RUJyN0RDbHF6VUpBQ0wyT05TVjltV2dYVnh4MDF2enUzclZSNWM9IixyZWFsbT0ibWFpbHRlc3QudWsuYXNwZXh0ZWNobm9sb2d5LmNvbSIscW9wPSJhdXRoIixtYXhidWY9NDA5NixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2Vzcw==
> Please enter your password:
> C: dXNlcm5hbWU9Iml0anB3IixyZWFsbT0ibWFpbHRlc3QudWsuYXNwZXh0ZWNobm9sb2d5LmNvbSIsbm9uY2U9IlFSV3c2RUJyN0RDbHF6VUpBQ0wyT05TVjltV2dYVnh4MDF2enUzclZSNWM9Iixjbm9uY2U9Ild3dnJpWUREc1pFK0hHODVWZFEvTlhnZm1pQlh4VmJJamhqdWZGN1BuWUk9IixuYz0wMDAwMDAwMSxxb3A9YXV0aCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJpbWFwL2xvY2FsaG9zdCIscmVzcG9uc2U9N2E1NzA3OWM1MzgxYWU5ZDkxNDExYzE0MzQxZWUzYmI=
> S: A01 NO user not found
> Authentication failed. generic failure
> Security strength factor: 256
>
> The same thing happens when I try to use cram-md5 as the mechanism.
> During both these tests, the saslauthd and openldap daemons appear to
> be doing nothing at all. Zilch, nothing, nada.
>
> Questions:
>
> (1) How can I get saslauthd to correctly process digest-md5 IMAP
>     logins?
>
> (2) Do I need a different format for the "mailPassord" LDAP entry
>     (e.g. something like mailPassword: {MD5}ad23d23d2d2= ). If so,
>     what format?
>
> (3) Is there a better way of doing this? I have to use Cyrus Imapd,
>     and I have to store authentication information in LDAP, but I'm
>     not forced to stick with anything else. I know Cyrus will talk to
>     PAM which will talk to LDAP, but thats just yet another mystery to
>     me ...
>
> Thanks,
>
> Jon
>
>

-- 
Jon Wilson <jon at phuq.co.uk>                     http://www.phuq.co.uk
UK                                            Tel. +44 (0)7776 137939
              Hand me my nosering! Show me the mosh pit!
                     We can be happy underground!