Hi, just a question: I know that dovecot supports SASL authentication and supports LDAP. Which means that dovecot performs the SASL methods itself and stores the plaintext secret on LDAP. But it is also possible to have the LDAP do the SASL work and dovecot just pass SASL messages through? Even when the LDAP server uses a proprietary SASL method not supported by dovecot? regards Hadmut
Hi Hadmut,
You can keep crypted passwords in LDAP also. See man (8) slappasswd:
-h scheme
If -h is specified, one of the following RFC 2307 schemes may be
specified: {CRYPT}, {MD5}, {SMD5}, {SSHA}, and {SHA}. The
default is {SSHA}.
Note that scheme names may need to be protected, due to { and },
from expansion by the user's command interpreter.
{SHA} and {SSHA} use the SHA-1 algorithm (FIPS 160-1), the lat-
ter with a seed.
{MD5} and {SMD5} use the MD5 algorithm (RFC 1321), the latter
with a seed.
{CRYPT} uses the crypt(3).
{CLEARTEXT} indicates that the new password should be added to
userPassword as clear text.
Tuesday, August 7, 2007, 9:38:20 AM, you wrote:
> Hi,
> just a question:
> I know that dovecot supports SASL authentication and supports LDAP.
> Which means that dovecot performs the SASL methods itself and stores the
> plaintext secret on LDAP.
> But it is also possible to have the LDAP do the SASL work and dovecot just
> pass SASL messages through? Even when the LDAP server uses a proprietary
> SASL method not supported by dovecot?
> regards
> Hadmut
--
Sergey
On Tue, 2007-08-07 at 08:38 +0200, Hadmut Danisch wrote:> Hi, > > just a question: > > I know that dovecot supports SASL authentication and supports LDAP. > Which means that dovecot performs the SASL methods itself and stores the > plaintext secret on LDAP. > > But it is also possible to have the LDAP do the SASL work and dovecot just > pass SASL messages through? Even when the LDAP server uses a proprietary > SASL method not supported by dovecot?For plaintext authentication you can use authentication binds and have the password stored on LDAP side in any way you want. For non-plaintext authentication Dovecot needs the secret in plaintext or some other specific format. LDAP doesn't support "SASL forwarding". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070807/e24a8859/attachment-0002.bin>
Timo Sirainen wrote:> > For plaintext authentication you can use authentication binds and have > the password stored on LDAP side in any way you want. > > For non-plaintext authentication Dovecot needs the secret in plaintext > or some other specific format. LDAP doesn't support "SASL forwarding".Neither one doesn't help in this particular case. I need to port a proprietary, non-publish one time password authentication method (not compatible with opie/skey) from older software into SASL or LDAP, to make it available for several unix applications. The current plan is to implement a plugin for cyrus-sasl which is used by most sasl-aware applications, and thus to have the openldap server accept sasl authentication for those applications which allow to authenticate against an LDAP server, not just with plaintext passwords, but with SASL as well. As far as I know dovecot does (or version 1.1) will support SASL methods, but does implement them itself, so does not work with a cyrus-sasl plugin and does not work against an LDAP server. Since SASL authentication is implemented as a communication protocol passing opaque byte sequences between client and servers, the idea was whether dovecot could act like a SASL proxy, i.e. passing the SASL traffic between the IMAP client on one side and the LDAP server on the other side just through without touching it and waiting for the result of the authentication process. A second method intended to be implemented is to pass web authentication (e.g. if a user authenticatis with SSL client certificates over HTTPS) through webserver - webmailer - IMAP Server -Authentication database which could also be implemented as a SASL plugin. Therefore would be nice to have a SASL pass through without the need to modify dovecot or teach dovecot new authentication methods regards Hadmut