On Fri, Oct 01, 2021 at 04:17:03PM +0200, Sam R wrote:
> I added two keytab in /etc/krb5.keytab
There's your problem, the /etc/krb5.keytab file, given services like SSH
with GSSAPI authentication, contains secrets sufficient to login to the
host as any user, possibly including root. It must belong to "root" and
not be readable by any other user (mode 0600).
GSSAPI libraries generally don't keep the keytab open indefinitely, and
open/read/close the file on every request.
Postfix services other than master(8) drop privileges, and by the time
smtpd(8) and the like need to access a keytab file, are no longer table
to access /etc/krb5.keytab.
If you want to provision GSSAPI (Kerberos mechanism) acceptor
credentials for Postfix, you must provision a separate keytab file owned
by the "postfix" ($mail_owner) user, not root. The name of that can
be set via something like:
# Default value from `postconf -d`:
# import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ
# XAUTHORITY DISPLAY LANG=C POSTLOG_SERVICE
# POSTLOG_HOSTNAME
#
# Unless you're running graphical X11 debuggers, you can drop
# XAUTHORITY and DISPLAY.
#
import_environment =
MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ
LANG=C POSTLOG_SERVICE POSTLOG_HOSTNAME
KRB5_KTNAME=/var/spool/postfix/etc/smtp.keytab
You can then add the "smtp/hostname@REALM" keys to that file.
> Oct 1 10:58:35 smtptest postfix/submission/smtpd[61932]:
> xsasl_cyrus_server_create: SASL service=smtp, realm=(null)
Your logging is too verbose, there's no need for that, it
just gets in the way. Especially with SASL, you're liable
to inadvertently leak secrets.
> Oct 1 10:58:35 smtptest postfix/submission/smtpd[61932]: warning:
> unknown[192.168.128.253]: request longer than 2048: AUTH GSSAPI
> YIIG8AYJKoZIhvcSAQ...
This could have been lost in the noise, if your Windows AD KDCs are
issuing bulky tickets (with a PAC containing a long list of group SIDs,
...) your servers needs to be able to accept GSSAPI requests longer
than 2048.
In Postfix 3.4 I introduced a new parameter:
http://www.postfix.org/postconf.5.html#smtpd_sasl_response_limit
smtpd_sasl_response_limit (default: 12288)
The maximum length of a SASL client's response to a server
challenge. When the client's "initial response" is longer than the
normal limit for SMTP commands, the client must omit its initial
response, and wait for an empty server challenge; it can then send
what would have been its "initial response" as a response to the
empty server challenge. RFC4954 requires the server to accept client
responses up to at least 12288 octets of base64-encoded text. The
default value is therefore also the minimum value accepted for this
parameter.
This feature is available in Postfix 3.4 and later. Prior versions
use "line_length_limit", which may need to be raised to accommodate
larger client responses, as may be needed with GSSAPI authentication
of Windows AD users who are members of many groups.
If you're using an older Postfix version, you may need to raise
"line_length_limit" as explained above. The same holds when your client
software violates RFC4954/RFC2821 by sending an overly long SASL
"initial response".
> -- basics --
> Postfix: 3.5.6
Since you're using Postfix 3.5, which by default supports long SASL
messages after the initial response, your client is in violation of the
SMTP SASL specification, and needs to have a bug filed against its SASL
GSSAPI implementation. If that client is also Postfix, file that bug
on this list. If not, reach out on the relevant forum, or bug tracking
system.
You can accommodate broken clients by raising line_length_limit even
on Postfix >= 3.4 systems where this should not otherwise be necessary
in most cases.
--
Viktor.
