[Dovecot] ldap SMD5 vs. CRYPT
Hello,
am I right, that dovecot can't cope with ldap so authentification is handled by ldap itself? And, for that I have to use {CRYPT} and cannot use other mechanisms as {SMD5}
Are there any other possibilities?
A
--
Adam Pordzik wrote:
Hello,
am I right, that dovecot can't cope with ldap so authentification is handled by ldap itself? And, for that I have to use {CRYPT} and cannot use other mechanisms as {SMD5}
Are there any other possibilities?
A
Adam
I rely on pam_ldap to do authentication with dovecot. This allows you to use any permitted authentication scheme from the following:
CRYPT UNIX SHA SSHA MD5 SMD5
Hope this helps!
-- Chris Hills IT Services North East Worcestershire College
On Tue, Oct 05, 2004 at 03:14:58PM +0200, Adam Pordzik wrote:
Hello,
am I right, that dovecot can't cope with ldap so authentification is handled by ldap itself? And, for that I have to use {CRYPT} and cannot use other mechanisms as {SMD5}
Dovecot doesn't support handing off authentication to LDAP, unless you use PAM (which eliminates the possibility of CRAM-MD5 or DIGEST-MD5 authentication).
Dovecot supports the RFC2307 userPassword LDAP attribute and through that the following schemes:
{CRYPT} {MD5} (note: Dovecot's {MD5} differs from LDAP's {MD5}) {PLAIN} {DIGEST-MD5} {SHA1} {PLAIN-MD5}
You can fix the MD5 issue and gain support for {SMD5} with my patch at http://www.roughtrade.net/dovecot/dovecot-ldap-md5-quirk-0.99.10.6.diff although I haven't tested this recently. Let me know if it works for you.
NB The 1.0-test series also adds support for more password hashes:
{SHA} / {SHA1} / {SMD5} / {SSHA} / {CLEARTEXT} / {HMAC-MD5} / {LDAP-MD5} {LANMAN} / {NTLM} / {RPA}
AFAIK, all the above are either directly compatible with OpenLDAP's authentication behaviour or can at least be stored in userPassword.
J
-- Joshua Goodall "as modern as tomorrow afternoon" joshua@roughtrade.net - FW109
Joshua Goodall wrote:
On Tue, Oct 05, 2004 at 03:14:58PM +0200, Adam Pordzik wrote:
Hello,
am I right, that dovecot can't cope with ldap so authentification is handled by ldap itself? And, for that I have to use {CRYPT} and cannot use other mechanisms as {SMD5}
Dovecot doesn't support handing off authentication to LDAP, unless you use PAM (which eliminates the possibility of CRAM-MD5 or DIGEST-MD5 authentication).
Thank you. I've now also read Timo's posts on that.
Dovecot supports the RFC2307 userPassword LDAP attribute and through that the following schemes:
Anyway, I've recompiled OpenLDAP with crypt support, since in addition it also offers a more simple way to migrate existing posix acocunts.
Although I appreciate your work I doubt that this is the right way: Everytime a new encryption comes to any ldap-server, dovecot has to follow. I'm really, really no Unix/C programer, so I can't appraise what makes more work: To (re-)implement a new hash algorithm or to support auth. ldap binds.
So, might it be better to abandon ldap entirely, to advantage of pam? Or, maintaining a separate attribute "dovecotUserPasswort" or something like that, with an algorithm dovedot can handle.
{MD5} (note: Dovecot's {MD5} differs from LDAP's {MD5})
Does that means that dovecot can't authenticate users with an OpenLDAP MD5 hash?
You can fix the MD5 issue and gain support for {SMD5} with my patch at http://www.roughtrade.net/dovecot/dovecot-ldap-md5-quirk-0.99.10.6.diff although I haven't tested this recently. Let me know if it works for you.
Aha. But patching sources isn't my thing. After doing such, more things will be broken as before... :-(
A
--
On Fri, Oct 08, 2004 at 03:35:36AM +0200, Adam Pordzik wrote:
So, might it be better to abandon ldap entirely, to advantage of pam? Or, maintaining a separate attribute "dovecotUserPasswort" or something like that, with an algorithm dovedot can handle.
If you use PAM, you *have* to use a plaintext authentication mechanism. This means for security you have to do IMAP over SSL, which may be a hassle for some environments (especially those without a certificate from a commonly trusted CA). I like to make DIGEST-MD5 and CRAM-MD5 available, and they support the use of non-plaintext secrets.
Secondly, the code that handles all the hashes is not LDAP-specific. Many of Dovecot's other password databases backends can store a {STRING}data format secret.
Thirdly, Dovecot 1.0-test handles all of the OpenLDAP forms for userPassword, so why bother inventing a non-standard schema?
{MD5} (note: Dovecot's {MD5} differs from LDAP's {MD5})
Does that means that dovecot can't authenticate users with an OpenLDAP MD5 hash?
Not at all. It just means that the code works around the difference.
You can fix the MD5 issue and gain support for {SMD5} with my patch at http://www.roughtrade.net/dovecot/dovecot-ldap-md5-quirk-0.99.10.6.diff although I haven't tested this recently. Let me know if it works for you.
Aha. But patching sources isn't my thing. After doing such, more things will be broken as before... :-(
Well, I wrote that patch and I've used it, and a variant is now in 1.0-test.
J
-- Joshua Goodall "as modern as tomorrow afternoon" joshua@roughtrade.net - FW109
On 8.10.2004, at 04:35, Adam Pordzik wrote:
Although I appreciate your work I doubt that this is the right way: Everytime a new encryption comes to any ldap-server, dovecot has to follow. I'm really, really no Unix/C programer, so I can't appraise what makes more work: To (re-)implement a new hash algorithm or to support auth. ldap binds.
Originally when I implemented LDAP support I didn't even know there existed such things as authentication binds. And later I just haven't cared myself enough about that issue, I don't need it and there are more important things for me to do. The annoying thing with it is that it'd have to be implemented asynchronously, which may not be simple.
participants (5)
-
Adam Pordzik
-
Adam Pordzik
-
Joshua Goodall
-
news.gmane.org
-
Timo Sirainen