[ Please respect the "Reply-To" header] On Sat, May 28, 2022 at 12:47:24PM -0700, Jim Garrison wrote:
> On 5/27/2022 8:31 PM, Viktor Dukhovni wrote: > > Why not just read the SASL_README that comes with Postfix, e.g. at: > > > > https://www.postfix.org/SASL_README.html > > OK, I did just that, with exactly the same results. Clearly I'm missing > something simple but critical, and the lack of good documentation on > the underlying pieces (pam, saslauthd, etc) is frustrating :-( When using Cyrus SASL for authentication of submission users (if you're not using "dovecot", which is generally easier to set up) indeed "saslauthd -a pam" is the saner option. > Here's what I've got: > > smtpd_sasl_type = cyrus > smtpd_sasl_auth_enable = yes May as well set it to "no" in main.cf, and only enable in master.cf on the submission ports (as you appear to have done). > smtpd_sasl_authenticated_header = yes > smtpd_sasl_path = smtpd > smtpd_sasl_response_limit = 12288 > smtpd_sasl_security_options = noanonymous > smtpd_sasl_service = smtp > smtpd_sasl_tls_security_options = $smtpd_sasl_security_options Don't forget: http://www.postfix.org/postconf.5.html#smtpd_tls_auth_only > I assume smtpd_sasl_service is passed through saslauthd when using pam > and provides what pam calls "service name". I tried a search for > "list of pam service names" and nothing I found mentioned "smtp" or > "smtpd". See: http://www.postfix.org/postconf.5.html#smtpd_sasl_service the default value is "smtp" and should rarely if ever be changed, this is used in e.g. GSSAPI to infer the correct service name to construct the server principal name for keytab lookups, ... It is the first argument to sasl_server_new(3): ... int sasl_server_new(const char *service, const char *serverFQDN, const char *user_realm, const char *iplocalport, const char *ipremoteport, const sasl_callback_t *callbacks, unsigned flags, sasl_conn_t ** pconn); DESCRIPTION sasl_server_new() creates a new SASL context. This context will be used for all SASL calls for one connection. It handles both authentication and integrity/encryption layers after authentication. service is the registered name of the service (usually the protocol name) using SASL (e.g. "imap"). ... This is then passed to "saslauthd", which in turn passes it to pam_start(3): int pam_start(const char *service, const char *user, const struct pam_conv *pam_conv, pam_handle_t **pamh); DESCRIPTION The pam_start function creates and initializes a PAM context. The service argument specifies the name of the policy to apply, and is stored in the PAM_SERVICE item in the created context. So indeed the pam.d configuration file name needs to match the configured service name (in this case "smtp"). > $ cat /etc/sasl2/smtpd.conf > pwcheck_method: saslauthd > mech_list: PLAIN LOGIN > log_level: 7 This looks reasonable, ... > (log_level doesn't seem to affect any logging that I can see) I'm not familiar with the details of "log_level", perhaps it is not expected to have any effect. > $ cat /etc/default/saslauthd > START=yes > DESC="SASL Authentication Daemon" > NAME="saslauthd" > MECHANISMS="pam" > MECH_OPTIONS="" > THREADS=5 > OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" Is "saslauthd" actually running? Do the process arguments include "-a pam"? Is the "mux" socket in place? ... > Testing saslauthd (after deleting /etc/sasldb2 and restarting > the saslauthd service) > > $ sudo testsaslauthd -u myuser -p [password] > 0: OK "Success." This suggests yes... > $ cat /etc/pam.d/smtp > auth required pam_unix.so no_warn > (I'll do the group thing later) Looks fine. > And finally, I disabled chroot in master.cf: > > smtp inet n - n - - smtpd > submission inet n - n - - smtpd > -o syslog_name=postfix/submission > -o smtpd_tls_security_level=encrypt > -o smtpd_sasl_auth_enable=yes See above re defaulting "auth_enable" to "no". > The error is still consistently > > 535 5.7.8 Error: authentication failed: bad protocol / cancel This particular error is unexpected, it generally indicates that the SASL server believes the "AUTH" command from the client to be malformed or otherwise invalid. To debug that, you may want to create a temporary test user with a password you're willing to leak to this list (after disabling the account). You can then report the SMTP dialogue between client and server by running the submission service with a "-v" option. Do make sure that you've installed all the requisite Cyrus libraries and mechanism plugins, that file permissions are correct, that you've restarted Postfix (just in case master(8) is running with stale service definitions, ...). You should also post the output of "saslfinger". -- Viktor.
