saslauthd: support several authentication methods

[Dmitry Katsubo]

Hi Dan!

Thank you again for detailed info.
I simply can't replace user's passwords with plaintext, as I don't know 
them. That will be also a potential security hole (if somebody breaks 
into LDAP). I use LDAP to authenticate Samba, FTP, PAM and IMAP users 
and also as address book, so I wouldn't risk a lot and leave saslauthd 
in place.

Of course, my intention is to drop the daemon (which is running with 
root privileges) and switch to ldapdb module, which will be run in the 
context of program that uses SASL, which is potentially better. But 
ldapdb is really tricky to setup. I understand the idea of LDAP 
proxying, but is it possible to introduce 'cmusaslsecretDIGEST-MD5' and 
'cmusaslsecretCRAM-MD5' attributes for my users and tell ldapdb to use 
MD5 mechanism (not plain text)? Is it what these attributes are aimed for?

Maybe there is some initiative to implement ldapdb in more simple manner 
(1-stage binding)? ... some alternative, which does not go togather with 
SASL package? Or there are some stopping factors, that do not allow such 
module to be implemented (API or security restrictions)?

Thanks!

Dan White wrote on 14/12/2009 06:21:
> On 12/12/09 22:26 +0100, Dmitry Katsubo wrote:
>> Thanks for the reply. The idea of using sasldb is really interesting,
>> as I don't need to run saslauthd anymore. But the configuration is
>> absolutely crazy. First of all I do not understand, why sasldb needs
>> sasl_ldapdb_id and sasl_ldapdb_pw to complete authorization. Does it
>> use 2-stage binding (first with supplied user/password pair and then
>> using the pair from service?). There is no way to specify the search
>> filter, as saslauthd configuration allows. Pity!
>
> To clarify, using sasldb does not require any configuration options (other
> than pwcheck_method). ldapdb does require a lot of setup.
>
> You don't need to dump your saslauthd ldap config if it works for you.
>> - I can use
>> sasl_ldapdb_uri: ldap://127.0.0.1/
>> and provide id/ps pair. Should id be a complete DN? What mechanizms
>> are then applicable, if LDAP stores password as SHA1 (no plain
>> passwords)?
>
> Your passwords will need to be clear text to work with ldapdb. SHA1/Hashed
> passwords will not work.
>
>> - I can use
>> sasl_ldapdb_uri: ldapi://
>> sasl_ldapdb_mech: EXTERNAL
>> but then I need to put cyrus account into LDAP and also create a
>> mapping for DNs like this:
>> gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
>>
>> Why such a complication? Why it cannot be done as simple as in
>> saslauthd? Can you share your configuration? I have found this message:
>
> ldapdb was designed to work without knowledge of your ldap DIT or layout.
> It works by performing a sasl authc/authz bind, where the authc credentials
> are specified by your ldapdb_* configration, and the authz identity is the
> username currently attempting to authenticate.
>
> I need to clarify. What ldapdb does is that it binds as the user attempting
> to authenticate, then performs an LDAPWHOAMI extended operation against the
> ldap server to find out what that user's DN is, and then does a search
> using that DN as the base and using a scope of 1 for the user's
> userPassword (typically).
>
> This allows you to have a complicated tree where you might not have a
> common base.
>
> This was done by design and makes a lot of sense once you have everything
> configured, but it's a bit of work.
>
> I'd start by reading about OpenLDAP Proxy Authorization:
>
> http://www.openldap.org/doc/admin24/sasl.html#SASL%20Proxy%20Authorization
>
> ldapdb probably won't work with very many LDAP servers. It might be
> OpenLDAP specific.
>
> Here are a couple of imapd.conf configs that I've used:
>
> sasl_auxprop_plugin: ldapdb
> sasl_ldapdb_uri: ldap://ldap1.example.net ldap://ldap2.example.net
> sasl_ldapdb_mech: GSSAPI
>
> and
>
> sasl_auxprop_plugin: ldapdb
> sasl_ldapdb_uri: ldapi:///
> sasl_ldapdb_mech: EXTERNAL
>
> However, in your Postfix smtpd.conf line, you should not include the sasl_
> prefix (which is an imapd.conf curiosity):
>
> auxprop_plugin: ldapdb
> ldapdb_uri: ldapi:///
> ldapdb_mech: EXTERNAL
>
> Assuming that your OpenLDAP server is running on the same machine, you
> might have a slapd.conf that includes:
>
> rootdn "cn=admin,dc=example,dc=net"
>
> authz-regexp
> "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth"
> cn=admin,dc=example,dc=net
>
> Although not necessary, you might consider including the following ldap
> schema, which was taken from an RFC draft titled
> draft-melnikov-sasl-auxprop-attrs-00.txt:
>
> attributetype ( 1.3.6.1.4.1.3.8.1.1.1
> NAME 'cmusaslsecretCRAM-MD5'
> DESC 'Prehashed password as described in CRAM-MD5'
> EQUALITY octetStringMatch
> SINGLE-VALUE
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32} )
>
> attributetype ( 1.3.6.1.4.1.3.8.1.1.2
> NAME 'cmusaslsecretDIGEST-MD5'
> DESC 'Shared secret for DIGEST-MD5'
> EQUALITY octetStringMatch
> SINGLE-VALUE
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{16} )
>
> attributetype ( 1.3.6.1.4.1.3.8.1.1.3
> NAME 'cmusaslsecretOTP'
> DESC 'OTP secret'
> EQUALITY octetStringMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
>
> attributetype ( 1.3.6.1.4.1.3.8.1.1.4
> NAME 'cmusaslsecretSRP'
> DESC 'base64 encoded SRP secret'
> EQUALITY octetStringMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
>
> attributetype ( 1.3.6.1.4.1.3.8.1.1.5
> NAME 'cmusaslsecretPLAIN'
> DESC 'PLAIN secret'
> EQUALITY octetStringMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
>
> objectclass ( 1.3.6.1.4.1.3.8.1.2.1
> NAME 'cmuSaslUser'
> SUP top
> AUXILIARY
> MAY ( userPassword $ cmusaslsecretCRAM-MD5 $
> cmusaslsecretDIGEST-MD5 $
> cmusaslsecretOTP $ cmusaslsecretSRP) )
>
>
> I throw this into /etc/ldap/schema/cmusasl.schema and then include an:
>
> objectClass: cmuSaslUser
>
> into my user entries. All entries have a cleartext password in
> userPassword.
>


-- 
With best regards,
Dmitry