Patrick, Thanks a lot for your help. I will test the mentioned configuration and will post the results to the list. I hope it works. Unfortunately, I do not have so much knowledge about LDAP, but I do know that it is possible to store Kerberos principals in an LDAP structure. Well, I don't know whether that is useful or not. Thanks again.
Kind Regards Ali Majdzadeh Kohbanani 2009/11/11, Patrick Ben Koetter <p...@state-of-mind.de>: > > * Ali Majdzadeh <ali.majdza...@gmail.com>: > > Patrick, > > > Thanks for your reply. So if I have concluded correctly, the following > > configuration is the one which should bring together gssapi, plain and > > cram-md5 authentication mechanisms: > > > It should. I have never done this myself. > > > > pwcheck_method: saslauthd auxprop > > mech_list: gssapi plain cram-md5 > > saslauthd_path: /var/run/saslauthd/mux > > keytab: /etc/krb5.keytab > > auxprop_plugin: sasldb > > > > But, you say that currently this does not work. True? > > > It does not work, if you use saslauthd alone. You need an auxprop_plugin to > get access to shared-secret mechs. > > > > What about ldapdb? I mean, is there actually anyway to achieve such a > setup? > > > ldapdb gives access to OpenLDAP. If (!) you store the userpassword values > in > plaintext, then you can use shared-secret mechanisms, such as CRAM-MD5 (and > also DIGEST-MD5 and NTLM). > > > > Is it possible to use ldapdb in a way that eliminates the need to > duplicate > > the credentials? > > > AFAIK you still need to run ldapdb -> OpenLDAP and Kerberos in parallel. > Single entry password maintainance should be possible using an OpenLDAP > overlay, which IIRC changes passwords in OpenLDAP and kerberos at the same > time. I don't remember the overlays name, though. Maybe its best to ask the > openldap mailing list how you can use kerberos and LDAP at the same time > and > then see how that goes together with SMTP AUTH. > > > p...@rick > > > > > > > Kind Regards > > Ali Majdzadeh Kohbanani > > > > 2009/11/11 Patrick Ben Koetter <p...@state-of-mind.de> > > > > > * Ali Majdzadeh <ali.majdza...@gmail.com>: > > > > Patrick, > > > > Hi > > > > Thanks for your mail. I use the following options in smtpd.conf: > > > > > > > > mech_list: gssapi plain > > > > pwcheck_method: saslauthd > > > > saslauthd_path: /var/run/saslauthd/mux > > > > keytab: /etc/krb5.keytab > > > > > > > > and I am able to use GSSAPI and PLAIN (Over PAM using pam_krb5.so) > > > > mechanisms. How is it possible to add cram-md5 mechanism? > > > > > > Sorry, but no. saslauthd is unable to handle shared-secret mechanisms. > You > > > could, theoretically, tell libsasl to query different pwcheck_methods > like > > > this: > > > > > > pwcheck_method: saslauthd auxprop > > > mech_list: gssapi plain cram-md5 > > > saslauthd_path: /var/run/saslauthd/mux > > > keytab: /etc/krb5.keytab > > > auxprop_plugin: sasldb > > > > > > libsasl would first try verification using saslauthd and if that fails > it > > > would turn to auxprop "sasldb". This backend COULD provide cram-md5, > but > > > you > > > would have to provide credentials in your kerberos backend AND in > sasldb, > > > which IMHO is a pain to support and somehow renders all the security > > > efforts > > > for GSSAPI and kerberos useless, because you store the same credentials > in > > > plaintext in a local database file. > > > > > > > By the way, I do know about sasldb and auxprop, but what I plan to > > > achieve > > > > is to have cram-md5 mechanism while supporting plain mechanism using > > > > saslauthd, PAM and pam_krb5.so. I have got no problems using native > > > GSSAPI > > > > support. > > > > > > AFAIK this in not possible at the moment. > > > > > > p...@rick > > > > > > > > > > > > > > > > > Kind Regards > > > > Ali Majdzadeh Kohbanani > > > > > > > > 2009/11/11 Patrick Ben Koetter <p...@state-of-mind.de> > > > > > > > > > * Ali Majdzadeh <ali.majdza...@gmail.com>: > > > > > > Hello All > > > > > > Is it possible to have both PLAIN and CRAM-MD5 authentication > > > > > > mechanisms using SASL? > > > > > > > > > > Yes. The password must be stored as plaintext. Then plaintext and > > > > > shared-secret mechanisms will work. > > > > > > > > > > p...@rick > > > > > > > > > > -- > > > > > All technical questions asked privately will be automatically > answered > > > on > > > > > the > > > > > list and archived for public access unless privacy is explicitely > > > required > > > > > and > > > > > justified. > > > > > > > > > > saslfinger (debugging SMTP AUTH): > > > > > <http://postfix.state-of-mind.de/patrick.koetter/saslfinger/> > > > > > > > > > > > -- > > > All technical questions asked privately will be automatically answered > on > > > the > > > list and archived for public access unless privacy is explicitely > required > > > and > > > justified. > > > > > > saslfinger (debugging SMTP AUTH): > > > <http://postfix.state-of-mind.de/patrick.koetter/saslfinger/> > > > > > > -- > > All technical questions asked privately will be automatically answered on > the > list and archived for public access unless privacy is explicitely required > and > justified. > > saslfinger (debugging SMTP AUTH): > <http://postfix.state-of-mind.de/patrick.koetter/saslfinger/> >
