[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sendmail + sasl + ldap
Hi Francisco,
I've been recently fighting similar problems but a bit more simple (just sendmail
and sasl without ldap). I have some good news but not a whole lot of it. First
off, I've built a port of the current Cyrus SASL v2.1.17 for OpenBSD 3.4 (it's
actually working for the most part). If you want it, contact me off list. When I
have it all polished I'll send it to the maintainer (jakob@openbsd). If you're a
kerberos site, the new port will not be much help because of changes in SASL have
broken kerberos use with OBSD -I'm still working on it.
You must realize that SASL defaults to using sasldb if no mechanisms are defined
in the configuration file. This means that
# cd /usr/local/sbin
# ./testsaslauthd -u username1 -p password1
will report success if username1 really is a system account. But the results of
this test are misleading since there are no auth mechanisms available to sendmail
to use.
On Mon, 9 Feb 2004 12:50:01 +0100, you wrote:
>I'm trying to set up a mail server that authenticates users against a
>central authenticacion host (OpenLDAP). The user's info is stored in the
>OpenLDAP server:
>
># ldapsearch -LL -H ldap://192.168.23.101 -b"dc=transportesjoti,dc=com" -x "(uid=joti)"
>version: 1
>
>dn: uid=joti,ou=People,dc=transportesjoti,dc=com
>uid: joti
>cn:: am90aSA=
>sn:: am90aSA=
>mail: joti@transportesjoti.com
>mailRoutingAddress: joti@mail.transportesjoti.com
>mailHost: mail.transportesjoti.com
>objectClass: inetLocalMailRecipient
>objectClass: person
>objectClass: organizationalPerson
>objectClass: inetOrgPerson
>objectClass: posixAccount
>objectClass: top
>objectClass: shadowAccount
>shadowLastChange: 12442
>loginShell: /bin/bash
>uidNumber: 1000
>gidNumber: 100
>homeDirectory: /home/joti
>
>
>The OpenLDAP server is a linux one, and the mail server is a OpenBSD 3.4 -stable one.
>
>I have set up sendmail to work with cyrus-sasl:
>
># sendmail -d0.1 -bv root | grep SASL
> NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SASLv2
>
One suggestion, make sure you recompile sendmail after you've got SASL installed
properly and have made a link from /usr/local/lib/libsasl2.so.2.13 to just the .so
# cd /usr/local/lib
# ln -s libsasl2.so.2.13 libsasl2.so
># cat /usr/local/lib/sasl2/Sendmail.conf pwcheck_method: saslauthd
>mech_list: plain
>
You are missing the `pwcheck_method' variable. It should be
# cat /usr/local/lib/sasl2/Sendmail.conf
pwcheck_method: saslauthd
mech_list: plain
>and i have set up saslauthd with LDAP support:
>
># cat /etc/saslauthd.conf
>ldap_servers: ldap://optimus.transportesjoti.com/
>ldap_search_base: ou=People,dc=transportesjoti,dc=com
>ldap_auth_method: userPassword
>
Did you specifically compile sasl to go looking for the saslauthd configuration
file at /etc/saslauthd.conf or is this something that ldap is using?
In general, sasl only goes looking for the following file:
/usr/local/lib/sasl2/<App Name>.conf
Where <App Name> is the name of the application using sasl.
>saslauthd works fine, or testsaslauthd say so,
testsaslauthd lies! (see above)
>but if i connect to mail
>servers' port 25:
>
># telnet localhost 25
>Trying ::1...
>Trying 127.0.0.1...
>Connected to localhost.
>Escape character is '^]'.
>220 [ ESMTP Transportes JOTI mail server ] - [ mail.transportesjoti.com ]
>Feb 9 12:40:55 snarl sm-mta[4170]: AUTH warning: no mechanisms
>
>
>and i can see in /var/log/maillog:
>
>Feb 9 12:40:55 snarl sm-mta[4170]: NOQUEUE: connect from localhost.transportesjoti.com [127.0.0.1]
>Feb 9 12:40:55 snarl sm-mta[4170]: AUTH warning: no mechanisms
>Feb 9 12:40:55 snarl sm-mta[4170]: AUTH warning: no mechanisms
>Feb 9 12:40:55 snarl sm-mta[4170]: i19BetLi004170: Milter: no active filter
>
>
>That AUTH warning: no mechanisms line show me that sasl is not working:
>
>ehlo localhost
>250-snarl.transportesjoti.com Hello localhost.transportesjoti.com [127.0.0.1], pleased to meet you
>250-ENHANCEDSTATUSCODES
>250-PIPELINING
>250-EXPN
>250-VERB
>250-8BITMIME
>250-SIZE 5242880
>250-DSN
>250-ETRN
>250-STARTTLS
>250-DELIVERBY
>250 HELP
>
>
Actually, the above EHLO output (missing AUTH) may also be a lie depending on your
sendmail configuration. For example, if you have `confAUTH_OPTIONS' turned on in
your sendmaiol.mc/cf file to prevent non-TLS secured connections from using AUTH
PLAIN or AUTH LOGIN and your real saslauthd configuration file in
/usr/local/lib/sasl2/Sendmail.conf only has "PLAIN" defined as an allowed
mechanism (mech_list: plain), then sendmail will not show "AUTH" until a TLS
session has been opened via STARTTLS... -In other words, the results of the EHLO
command line test you are doing are completely useless.
from my sendmail.mc file:
dnl# how folks can authenticate, and which methods are allowed to relay
define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')
define(`confDEF_AUTH_INFO', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')
TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')
dnl# Disables PLAIN and LOGIN over non-TLS links
define(`confAUTH_OPTIONS', `p')
If you change your saslauthd ./sasl2/Sendmail.conf file to read
mech_list: gssapi digest-md5 cram-md5 login plain
and reboot/reload your initial EHLO will now have:
250 AUTH GSSAPI DIGEST-MD5 CRAM-MD5
and your EHLO after starting a TLS session will read
250 AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
The easyest way I have found to test and debuf this stuff to set your sendmail
logging up to 22 in your .mc file
dnl# increasing the log level allows one to debug various things
define(`confLOG_LEVEL', 22)
This will put the EHLO command output into the log file as well as the saslauthd
stuff. You will also need a mail client that does SSL/TLS authentication, so you
can see the "real" EHLO output after STARTTLS has been start a session. I suggest
you download a copy of the Opera Web/Mail/News client (www.opera.com). You can
even turn on logging in Opera and it will also show you what is going on from the
client side.
>I have googled, search in cyrus mailings and so on and i could not
>find an answer, perhaps someone here have a similar problem or could
>point me in the right direction...
SASL documentation sucks, the design of the software is very complex (nearly
obfuscated) and it has taken me weeks of dinking around with it and reading the
source code to understand what the heck they are trying to do most of the time.
I hope this helps. Also, for the sake of the next person trying this stuff, let's
try to keep everything on list.
Kind Regards,
JCR