Authenticating with DIGEST-MD5 against an LDAP directory

Kevin cyrus at gnosys.biz
Fri Oct 22 12:24:12 EDT 2004


Hi List-

I'm using cyrus-imapd-2.2.8 and cyrus-sasl-2.1.19 on an x86 Gentoo Linux
system.

I just finished implementing DIGEST-MD5 authentication by LDAP clients
to an OpenLDAP server with the shared secrets stored in the userPassword
attribute of a directory entry's record.  Unless I'm way off base,
cyrus-sasl is involved in this process (though I'm not sure if it's done
with Cyrus SASL Library calls or saslauthd, I think it is the former).

Thinking that if the above works (and it does), then it should also be
possible to implement DIGEST-MD5 authentication by IMAP clients to a
Cyrus IMAPd server with the shared secrets stored in the same place (the
LDAP directory).

I've been struggling for a long time to do this, and after researching
and reading and experimenting (and reading some more), it's just dawned
on me that it may not be possible with the present code.  Can someone
confirm or deny this notion for me?  Is it possible to have
cyrus-imapd-2.2.8 do DIGEST-MD5 authentication with the shared secrets
stored in an LDAP directory?

I read the file in the cyrus-sasl package named LDAP_SASLAUTHD and it
describes how to do saslauthd authentication against an LDAP directory
(where is the code that does this, BTW?  The file mentions the auth_ldap
module but I don't see it in my sasl package---is it built directly into
saslauthd?), but after working on this for awhile and reading and
re-reading, it suddenly clicked with me that saslauthd is for doing
plaintext authentication only.  Someone on the SASL list confirmed this
for me.

So, if my understanding is correct, and if I want to use DIGEST-MD5 (or
the other shared secret mechanism: CRAM-MD5) as an authentication
mechanism, then I cannot use saslauthd (for that is for the PLAIN or
LOGIN authentication mechanisms only) for this at all.  True?

And if all that's true, then all that is left for me to ask about is
options for storing the shared secret (when using one of the shared
secret mechanisms) such that Cyrus IMAPd can read them.  Looks like an
SQL database or SASLdb are the only options unless I write new code.
True?  I'm reading in the Cyrus SASL html docs that:
================
  Plugins (Auxiliary Property)

   Auxiliary Property (or auxprop) plugins provide a database service
   for the glue layer (and through it, to the mechanisms and
   application).  Cyrus SASL ships with two auxprop plugins: SASLdb and
   SQL. Though they can be use in much more generic ways, auxprop
   plugins are mostly only used by shared secret mechanisms (or by the
   auxprop password verify) to access the "userPassword" attribute. This
   provides a plaintext copy of the password that allows for
   authentication to take place.

   Like the mechanism plugins, these are named similarly to the
   databases that they implement an interface for.

================

If someone can confirm my understanding here that would be most helpful
to me and I'd really appreciate it.  I have thought many times that I
understood all of the subtle interplays between Cyrus IMAPd, the Cyrus
SASL Library, the Cyrus saslauthd, and related issues, but it seems to
keep escaping from me.  If I know I have it right this time, then it's
easy for me to choose other authentication alternatives (knowing that
they should work) such as TLS+PLAIN authentication to an LDAP directory,
but I just need to get my understanding verified first.

TIA.

-- 
Kevin
http://www.gnosys.us

---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html




More information about the Info-cyrus mailing list