saslauthd: support several authentication methods

[Dan White]

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.

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.

-- 
Dan White