On 12-03-26 01:39 AM, Patrick Ben Koetter wrote:
* brian<[email protected]>:
$ sudo testsaslauthd -u test -p test
0: OK "Success."
Your test is misleading, because it tests a different SASL setup.
testsaslauthd tests saslauthd authentication while you have configured Cyrus
SASL to have libsasl access sasldb using the sasldb auxprop plugin.
And saslauthd uses the mechaism you tell it to.
/etc/default/saslauthd:
MECHANISMS="sasldb"
How else would I get "success" response? Here's a line from the log
(where it failed, in this case):
demeter saslauthd[9701]: do_auth : auth failure:
[[email protected]] [service=imap] [realm=] [mech=sasldb]
[reason=Unknown]
You see that it is using sasldb.
You seem to be running Postfix on a debianized machine. Is Postfix in group
sasl as the documentation requires it? Is the sasl group owner of /etc/sasldb2
so Postfix may access it?
Yes to both.
master.cf:
smtp inet n - n - - smtpd
submission inet n - n - - smtpd
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_mynetworks,
permit_sasl_authenticated,reject
Unless you are planning to let clients from $mynetworks send from 587 you
should switch smtpd_client_restrictions back to this:
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
Good point. Removed.
What's the current setting for smtpd_delay_reject? Is it at its default?
With your current setup it must be set to 'yes' or AUTH will fail.
It's set to "yes".
You don't have to add $smtpd_sasl_local_domain unless you have clients that
send their identity without the domainpart. Only in that case Postfix would
append $smtpd_sasl_local_domain.
I included it because I was having trouble figuring out if the domain
needed to be included with the username.
You don't have to add smtpd_sasl_path=smtpd; it is the default.
I did some more looking around later and found that what is in main.cf
applies to all ports. And that the reason for including
smtpd_client_restrictions in master.cf is so that one can override all
of the stages. Thanks for confirming.
Virtual domains and SASL have nothing in common.
My point was that I'm having trouble authenticating, and it seems to be
because of the way I've created the accounts. I decided not to use
sasldb, as I've always done, and instead use the shadow mechanism and
created unix accounts with an empty shell. All is working fine now.
