On Fri, 25 Mar 2005, Sergey Shepshelevich wrote:
I have a digest auth helper querying LDAP for the hash, but as you noted above this requires either Digest MD5 hashes or plain text passwords in the directory..
Do you store MD5(username:realm:password) in ldap directory ?
Yes, this is the Digest MD5 hash.
If using MD5(username:realm:password) as userPassword other programs can't work.
Each scheme using hashed passwords need their own password hash in the directory, or plain text passwords.
When storing hashed passwords in the directory and needing to interoperate with various authentication systems you may end up needing to store several of the following, maybe more:
- Unix Crypt - Unix MD5 - Apache MD5 - Digest MD5, one per realm supported - Windows NT MD4 (aka NT#) - Windows LANMAN DES (aka LM#)
as each uses their own hashing method..
Is it possible use 'sasl2 + squid + openldap' and one attibute 'userPassword' contains MD5(username:realm:password) ?
I read 'Using Digest Authentication as a SASL Mechanism' http://www.faqs.org/rfcs/rfc2831.html
//3.10 Storing passwords //Digest authentication requires that the authenticating agent (usually //the server) store some data derived from the user's name and password //in a "password file" associated with a given realm. Normally this //might contain pairs consisting of username and H({ username-value, // ":", realm-value, ":", passwd }), which is adequate to compute H(A1) //as described above without directly exposing the user's password.
and can't say may be becouse inteface's digest helper and squid is not clearly for me.
If you make both Squid and SASL use the same realm and the LDAP userPassword attribute then it should be possible to make this work. But I would probably store this in another field, preserving the userPassword field for it's normal LDAP BIND verification use.
I am not very familiar SASL and LDAP integration, but there is no technical reasons why it can not be done like described above provided the realm is the same.
Regards Henrik
