Sendmail/Cyrus-SASL authentication mystery

[Martijn Dekker]

On my Slackware 13.37 64-bit system, I am trying to set up the stock
Sendmail 8.14.4 system with SMTP authentication using Cyrus SASL.

Apparently Cyrus SASL itself is authenticating correctly against the
shadow database, according to "testsaslauthd":

# /etc/rc.d/rc.saslauthd start
Starting SASL authentication daemon: /usr/sbin/saslauthd -a shadow
# testsaslauthd -u martijn -p (password removed)
0: OK "Success."

For Sendmail, I am using an /etc/mail/sendmail.cf built from the
unchanged /usr/share/cf/cf/sendmail-slackware-tls-sasl.mc file, as
follows (starting from the /usr/share/sendmail/cf/cf directory):

# ./Build sendmail-slackware-tls-sasl.mc
# cat sendmail-slackware-tls-sasl.cf > /etc/mail/sendmail.cf
# /etc/rc.d/rc.sendmail start
Starting sendmail MTA daemon: /usr/sbin/sendmail -L sm-mta -bd -q25m
Starting sendmail MSP queue runner: /usr/sbin/sendmail -L sm-msp-queue -Ac -q25m

Now, Sendmail starts successfully and appears to work correctly for
unauthenticated, unencrypted SMTP sessions on port 25. Encryption also
works correctly after generating the keys.

However, for authenticated SMTP sessions, whether encrypted or not, it
always rejects the password. To try to find the reason, I changed
Sendmail's logging level from the default 9 to 15 (using the -O
LogLevel=15 command line option). Using this log level, in
/var/log/maillog I find an error like the following whenever I try to
authenticate using SMTP:

Aug 2 22:21:47 vks14486 sm-mta[310]: q72KLkmt000310: AUTH failure (LOGIN): user not found (-20) SASL(-13): user not found: checkpass failed, relay=inlv.demon.nl [212.238.240.159]

or, when using CRAM-MD5 authentication:

Aug 2 22:56:55 vks14486 sm-mta[475]: q72KutuT000475: AUTH failure (CRAM-MD5): user not found (-20) SASL(-13): user not found: no secret in database, relay=inlv.demon.nl [212.238.240.159]

So apparently the user is not found. But I am definitely trying to
authenticate using the same user and password as used earlier with the
"testsaslauthd" command, which succeeded. Two different email programs
(Thunderbird and Apple Mail), using all possible password methods, give
the same results.

So now I'm out of ideas, and I figure I must be missing something. Any
pointers on what to try next?

A full debug log of one failed session is below.

TIA,

- Martijn

Aug 2 23:02:57 vks14486 sm-mta[502]: NOQUEUE: connect from inlv.demon.nl [212.238.240.159]
Aug 2 23:02:57 vks14486 sm-mta[502]: AUTH: available mech=DIGEST-MD5 OTP CRAM-MD5, allowed mech=LOGIN PLAIN DIGEST-MD5 CRAM-MD5
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: Milter: no active filter
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 220 vks14486.ip-37-59-109.eu ESMTP Sendmail 8.14.4/8.14.4; Thu, 2 Aug 2012 23:02:57 +0200
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: <-- EHLO [192.168.1.124]
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 250-vks14486.ip-37-59-109.eu Hello inlv.demon.nl [212.238.240.159], pleased to meet you
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 250-ENHANCEDSTATUSCODES
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 250-PIPELINING
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 250-8BITMIME
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 250-SIZE
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 250-DSN
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 250-ETRN
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 250-AUTH DIGEST-MD5 CRAM-MD5
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 250-STARTTLS
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 250-DELIVERBY
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 250 HELP
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: <-- AUTH CRAM-MD5
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 334 RemovedRemovedRemovedRemovedRemovedRemovedRemovedRemovedRe==
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 535 5.7.0 authentication failed
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: AUTH failure (CRAM-MD5): user not found (-20) SASL(-13): user not found: no secret in database, relay=inlv.demon.nl [212.238.240.159]
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: --- 421 4.4.1 vks14486.ip-37-59-109.eu Lost input channel from inlv.demon.nl [212.238.240.159]
Aug 2 23:02:57 vks14486 sm-mta[502]: q72L2vFs000502: inlv.demon.nl [212.238.240.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

[Ken P]

Do you have a Sendmail.conf file located at /etc/sasl2/ ?

cat /etc/sasl2/Sendmail.conf
pwcheck_method: saslauthd
mech_list: EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN

This is where and what I had in mine in order to get it to work. Not
sure you need the second line on Sendmail.conf.

--
Ken P

[Martijn Dekker]

In article <a80d49...@mid.individual.net>,

Ken P <K...@invalid.invalid> wrote:

> Do you have a Sendmail.conf file located at /etc/sasl2/ ?
>
> cat /etc/sasl2/Sendmail.conf
> pwcheck_method: saslauthd
> mech_list: EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
>
> This is where and what I had in mine in order to get it to work. Not
> sure you need the second line on Sendmail.conf.

Yes, I neglected to mention I did create that file, and put one line in
it: "pwcheck_method: shadow". Your file seems to make more sense, so I
used it, but there is no change - still the same "user not found", "no
secret in database" in the log. :(

It also appears to make no difference if I use the "mech_list" line or
not, or if I reduce it to only the mechanisms advertised by Sendmail
(DIGEST-MD5 and CRAM-MD5).

Thanks for the response.

- Martijn

[Martijn Dekker]

In article <martijn-E8FEAB...@news.individual.net>,

Martijn Dekker <mar...@inlv.demon.nl> wrote:

> It also appears to make no difference if I use the "mech_list" line or
> not, or if I reduce it to only the mechanisms advertised by Sendmail
> (DIGEST-MD5 and CRAM-MD5).

OK, so now I'm getting somewhere... after finding this crucial bit of
information, buried in some forum thread from 2005:

http://web.archiveorange.com/archive/v/MGqEsnWcNx0TRNi5AKEB
| Alexander Dalloz -- Mon Feb 14 16:57:01 2005
| You can't use "shadow" and MD5 mechanisms. If you want to use
| DIGEST-MD5 or CRAM-MD5 you will have to use auxprop plugin instead.

Now, this is Slackware, so I want to authenticate against the standard
/etc/shadow database because I want to keep it straightforward and avoid
storing user passwords in multiple places.

Also, I thought I'd sort out the TLS encryption later and just use plain
SMTP on port 25 until I have this authentication thing worked out.

However, the default configuration in sendmail.mc restricts me from
using plain text password authentication, leaving only DIGEST-MD5 and
CRAM-MD5 available -- precisely the two methods that are apparently
incompatible with /etc/shadow based authentication!!!

Why is that, and how was I supposed to know that? The sysadmin guide in
/usr/doc/cyrus-sasl-2.1.23/doc/sysadmin.html doesn't even mention shadow
passwords. No wonder I wasn't getting anywhere. If anyone has background
information on the reasons behind this limitation, I'd be interested.

Anyway, I temporarily fixed my problem by allowing plain-text password
authentication over unencrypted links (very insecure), by changing this
line in sendmail.mc:
define(`confAUTH_OPTIONS', `A p y')dnl
to
define(`confAUTH_OPTIONS', `A y')dnl
and rebuilding /etc/mail/sendmail.cf and restarting sendmail. And sure
enough, now I have authenticated SMTP working.

Now I can move on to getting TLS encryption sorted out. Once there is an
encrypted link, being restricted to plain-text password authentication
will not be a problem.

- Martijn

[Kees Theunissen]

Did you create a file /etc/sasl2/Sendmail.conf (mind the upper case "S"
in "Sendmail.conf")?

----- /etc/sasl2/Sendmail.conf ------------
pwcheck_method:saslauthd
mech_list:login plain
-------------------------------------------

This worked for me to authenticate against the shadow file when I was
playing with it two years ago. The timestamp of that file is
Mar 31 2010. I used the 32 bits slackware "stable" release, and I'm
too lazy to look up what version that was at that time. :-)
I used the supplied sendmail-slackware-tls-sasl.mc with only the
names of the certificate files modified.

Regards,

Kees.

--
Kees Theunissen.

[Kees Theunissen]

Martijn Dekker wrote:
> In article <501b9433$0$6858$e4fe...@news2.news.xs4all.nl>,

> Kees Theunissen <theu...@rijnh.nl> wrote:
>
>> Did you create a file /etc/sasl2/Sendmail.conf (mind the upper case "S"
>> in "Sendmail.conf")?
>>
>> ----- /etc/sasl2/Sendmail.conf ------------
>> pwcheck_method:saslauthd
>> mech_list:login plain
>> -------------------------------------------
>

> Yes, I did and now it contains the same as yours.
>
> Another responder took the thread out of comp.mail.sendmail and it
> continued in alt.os.linux.slackware only. See
> <URL:news:martijn-C2FD3D...@news.individual.net>

Yes, I saw that after I posted my message. I'm bringing the thread
back to both newsgroups.

> To summarize, the problem turned out to be that, for some reason,
> DIGEST-MD5 or CRAM-MD5 authentication cannot be used over unencrypted
> SMTP connections if authenticating against the system /etc/shadow
> database (saslauthd -a shadow).

No. DIGEST-MD5 or CRAM-MD5 cannot be used at all to authenticate
against /etc/shadow. The shadow file stores a one-way hash of your
password. The only way to authenticate against /etc/shadow is to
accept a plain-text password, recompute the hash using the "salt"
that is also stored in /etc/shadow, and compare the result with
the stored hash. This leaves only LOGIN and PLAIN as useable
authentication mechanisms.

> As far as I can tell, this crucial bit of information is nowhere to be
> found in the documentation. I dug it up from an obscure forum thread
> from 2005.
>
> I think this limitation is really weird, because unencrypted connections
> are precisely the situation where you would most want to use encrypted
> authentication. Sendmail even enforces its use by default over
> unencrypted connections, in this case leaving me with no working
> authentication method.

In your original message you wrote:

> # ./Build sendmail-slackware-tls-sasl.mc
> # cat sendmail-slackware-tls-sasl.cf > /etc/mail/sendmail.cf
> # /etc/rc.d/rc.sendmail start
> Starting sendmail MTA daemon: /usr/sbin/sendmail -L sm-mta -bd -q25m
> Starting sendmail MSP queue runner: /usr/sbin/sendmail -L
> sm-msp-queue -Ac -q25m
>
> Now, Sendmail starts successfully and appears to work correctly for
> unauthenticated, unencrypted SMTP sessions on port 25. Encryption also
> works correctly after generating the keys.

So start testing this first before you try to connect with a
mail-client. See http://qmail.jms1.net/test-auth.shtml for a procedure
to test "PLAIN" authentication over an encrypted connection.
I did those tests on a 32-bits slackware 13.37 with sendmail.cf
generated from a stock sendmail-slackware-tls-sasl.mc .
Authentication succeeded on port 25 as well as on port 465 (with
different ways to connect of course as described on the above link).

Once this is working you can start testing with email-clients.