Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Postfix SASL Authentication in Debian without sasldb

0 views
Skip to first unread message

Wesley Hertlein

unread,
Feb 27, 2003, 11:54:57 PM2/27/03
to
Well, I'm at my wits end here... I've read through FAQs, trying all
kinds of debugging, gone through the archives on this list... here's
to hoping that someone here can help.

I'm running Debian Woody 3.0r1 with all the standard postfix-tls and
sasl packages that I should need. I'd like to get sasl authentication
going over a tls connection but not available otherwise.

I'm 90% of the way there, I think. SASL is disabled in the standard
chroot'd postfix instance running on port 25. SASL is enabled on my
TLS postfix running not chroot'd on port 465.

I can authenticate successfully over this TLS connection with sasldb.
(That's /etc/sasldb, incidently... this instance isn't chroot'd.)
However, I want to be using either shadow or pam. (Probably pam, as
I don't see any reason to allow postfix to read /etc/shadow, but I'm
willing to allow that if it's the only way.)

Here's the kicker... no matter what /etc/postfix/sasl/smtpd.conf and
/usr/lib/sasl/smtpd.conf say, it always uses /etc/sasldb! My auth
log and the -v option for postfix arn't very helpful here... in a
nutshell, if /etc/sasldb is present (with the correct entry set up,
of course) I get authenticated successfully. If it's not there, I
get a pleasant error message in /var/log/auth.log:

Feb 27 23:46:21 max postfix/smtpd[665]: unable to open Berkeley db
/etc/sasldb: No such file or directory

I'd be happy to send dpkg listings, more detailed log files, whatever,
but I've been all over my system. If anyone suggests something I
havn't looked at, they're probably a winner.

Currently my /etc/postfix/sasl/smtpd.conf reads:

pwcheck_method: pam

I've also tried shadow, with the same results.

Any suggestions would be very appreciated!

--
Wes Hertlein
wes-p...@tothepain.net

Markus Schabel

unread,
Feb 28, 2003, 4:13:52 AM2/28/03
to
Wesley Hertlein wrote:
<snip/>

> Feb 27 23:46:21 max postfix/smtpd[665]: unable to open Berkeley db
> /etc/sasldb: No such file or directory
>
> I'd be happy to send dpkg listings, more detailed log files, whatever,
> but I've been all over my system. If anyone suggests something I
> havn't looked at, they're probably a winner.
<snip/>

The libsasl-modules-plain package contains usr/lib/sasl/libcrammd5.so,
and this module always checks sasldb - ingoring the smtpd.conf. If you
don't use crammd5 you should delete this lib and you will not see this
error again. If you're using cram-md5 you better forget to use pam,
because cram-md5 only works with sasldb.

Except for this error in the log authentication *should* work - except
for cram-md5 authentication. If it doesn't something else is wrong.

regards
--
\\\ ||| /// _\=/_
( @ @ ) (o o)
+--------oOOo-(_)-oOOo--------------------------oOOo-(_)-oOOo------+
| Markus Schabel TGM - Die Schule der Technik www.tgm.ac.at |
| IT-Service A-1200 Wien, Wexstrasse 19-23 net.tgm.ac.at |
| markus....@tgm.ac.at Tel.: +43(1)33126/316 |
| markus....@members.fsf.org Fax.: +43(1)33126/154 |
| FSF Associate Member #597, Linux User #259595 (counter.li.org) |
| oOOo Yet Another Spam Trap: oOOo |
| ( ) oOOo ya...@tgm.ac.at ( ) oOOo |
+--------\ (----( )--------------------------\ ( -----( )-----+
\_) ) / \_) ) /
(_/ (_/

Computers are like airconditioners:
They stop working properly if you open windows.

Wesley Hertlein

unread,
Feb 28, 2003, 7:44:59 AM2/28/03
to
On Fri, Feb 28, 2003 at 10:13:02AM +0100, Markus Schabel wrote:
> Wesley Hertlein wrote:
> <snip/>
> >Feb 27 23:46:21 max postfix/smtpd[665]: unable to open Berkeley db
> >/etc/sasldb: No such file or directory
> >
> >I'd be happy to send dpkg listings, more detailed log files, whatever,
> >but I've been all over my system. If anyone suggests something I
> >havn't looked at, they're probably a winner.
> <snip/>
>
> The libsasl-modules-plain package contains usr/lib/sasl/libcrammd5.so,
> and this module always checks sasldb - ingoring the smtpd.conf. If you
> don't use crammd5 you should delete this lib and you will not see this
> error again. If you're using cram-md5 you better forget to use pam,
> because cram-md5 only works with sasldb.
>
> Except for this error in the log authentication *should* work - except
> for cram-md5 authentication. If it doesn't something else is wrong.

Alright, I'm *slighty* happy, this seems to be something I havn't
explored. However, in 20 minutes of playing with things I can't seem
to get it happy, and I need to go get ready for work. :)

I'll have a chance to debug this later.

In the meantime, do you think you could take a guess at the minimum
packages I'd need? Of the libsasl* packages at the second I only
left installed libsasl-digestmd5-des and libsasl7, and I had a "No
authentication modules found" error. I'm willing to use AUTH PLAIN
as the only sasl connections I'm allowing are over TLS, if that
helps simplify things.

Anyway, I may very well owe you a beverage of your choosing, sir.
Thanks for the hint.

--
Wes Hertlein
wes-p...@tothepain.net

No One in Particular

unread,
Mar 3, 2003, 2:40:23 PM3/3/03
to
On Fri, 28 Feb 2003 09:13:52 +0000, Markus Schabel wrote:

> Wesley Hertlein wrote:
> <snip/>
>> Feb 27 23:46:21 max postfix/smtpd[665]: unable to open Berkeley db
>> /etc/sasldb: No such file or directory
>>
>> I'd be happy to send dpkg listings, more detailed log files, whatever,
>> but I've been all over my system. If anyone suggests something I
>> havn't looked at, they're probably a winner.
> <snip/>
>
> The libsasl-modules-plain package contains usr/lib/sasl/libcrammd5.so,
> and this module always checks sasldb - ingoring the smtpd.conf. If you
> don't use crammd5 you should delete this lib and you will not see this
> error again. If you're using cram-md5 you better forget to use pam,
> because cram-md5 only works with sasldb.

That's really terrible. I've been working with these types of problems
for quite a while now, and one discovery I've made is that Eudora
always uses CRAM-MD5 whenever it's available. I spent a few days beating
my head against the wall as to why every other auth mechanism would work
except the one that Eudora wanted to use for some reason.

FWIW, I've dropped those libraries and Eudora falls back to AUTH LOGIN
and seems to do fine.

0 new messages