Authenticating with DIGEST-MD5 against an LDAP directory
Igor Brezac
igor at ipass.net
Fri Oct 22 13:22:30 EDT 2004
See https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2406
-Igor
On Fri, 22 Oct 2004, Kevin wrote:
> 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.
>
>
--
Igor
---
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