Subject: /usr/lib/postfix/sbin/smtpd: Sometimes smtpd unable to authenticate a client via SASL GSSAPI
Date: Tue, 11 Dec 2018 10:28:39 +0500
Package: postfix
Version: 3.1.8-0+deb9u1
Severity: important
File: /usr/lib/postfix/sbin/smtpd
Dear Maintainer,
after upgrading Debian from 8/jessie to 9/stretch I've started to
receive periodical errors while client tries to send an email with
authentication via Kerberos/GSSAPI via Postfix.
The MUA is a Thunderbird 60.2.1 on Windows Server 2016 in AD ___domain.
Thunderbird setted up to use STARTTLS with Kerberos / GSSAPI
authentication method. Sometimes client got Kerberos error (ticket
Kerberos/GSSAPI was not received by SMTP server) in the MUA and in the
log I can see:
Dec 11 09:40:00 mx1 postfix/smtpd[9857]: warning: SASL authentication failure: Requested identity not authenticated identity
Dec 11 09:40:00 mx1 postfix/smtpd[9857]: warning: unknown[192.168.1.3]: SASL GSSAPI authentication failed: authentication failure
About 4-5% of total authenticaions has such error (~20 of total ~500 in
a day). If user in the Thunderbird close error window and try to send
an email again it usually sends successfully. It's non needed to relog on
the windows server or restart a mail client, just do another try.
Kerberos authentication also used in the Cyrus IMAP server on the same
Debian host and there are no any errors with Kerberos at all. So I think
something wrong on the Postfix side.
Here is the SASL source code where this error ("Requested identity not
authenticated identity") rises.
File lib/common.c, begining from line 2625:
static int
_sasl_proxy_policy(sasl_conn_t *conn,
void *context __attribute__((unused)),
const char *requested_user, unsigned rlen,
const char *auth_identity, unsigned alen,
const char *def_realm __attribute__((unused)),
unsigned urlen __attribute__((unused)),
struct propctx *propctx __attribute__((unused)))
{
if (!conn)
return SASL_BADPARAM;
if (!requested_user || *requested_user == '\0')
return SASL_OK;
if (!auth_identity || !requested_user || rlen != alen ||
(memcmp(auth_identity, requested_user, rlen) != 0)) {
sasl_seterror(conn, 0,
"Requested identity not authenticated identity");
RETURN(conn, SASL_BADAUTH);
}
return SASL_OK;
}
I think Postfix incorrectly use or 'auth_identity' or 'requested_user'
sometimes when calls SASL auth checking.
I was unable to find SASL call with identity and user arguments while
debug (at level 5) SMTP session between client and server.
Some settings related to Kerberos:
mailbox:~# postconf -n | grep sasl
------------------------------------
broken_sasl_auth_clients = yes
smtpd_client_restrictions = check_client_access regexp:/etc/postfix/lists/filter_as_originating.re permit_mynetworks permit_sasl_authenticated check_client_access regexp:/etc/postfix/lists/filter_as_foreign.re check_client_access hash:/etc/postfix/lists/client_access check_client_access regexp:/etc/postfix/lists/dsl_stoplist.re reject_rbl_client zombie.dnsbl.sorbs.net reject_rbl_client sbl.spamhaus.org permit
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_sender_access hash:/etc/postfix/lists/sender_access reject_invalid_hostname reject_non_fqdn_hostname reject_non_fqdn_sender reject_non_fqdn_recipient reject_unknown_sender_domain reject_unknown_recipient_domain reject_unauth_pipelining check_recipient_access hash:/etc/postfix/lists/recipient_before_grey check_policy_service inet:127.0.0.1:10023 permit
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = METALURAL.LOC
smtpd_sasl_security_options = noanonymous
------------------------------------
/etc/krb5.conf:
------------------------------------
[libdefaults]
default_realm = METALURAL.LOC
dns_lookup_realm = false
dns_lookup_kdc = false
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
[realms]
METALURAL.LOC = {
kdc = 192.168.1.9
kdc = 192.168.1.10
admin_server = 192.168.1.9
default_domain = metalural.loc
}
[domain_realm]
.metalural.loc = METALURAL.LOC
metalural.loc = METALURAL.LOC
metalural.ru = METALURAL.LOC
.metalural.ru = METALURAL.LOC
[logging]
kdc = FILE:/var/log/kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb.log
------------------------------------
-- System Information:
Debian Release: 9.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages postfix depends on:
ii adduser 3.115
ii cpio 2.11+dfsg-6
ii debconf [debconf-2.0] 1.5.61
ii dpkg 1.18.25
ii init-system-helpers 1.48
ii libc6 2.24-11+deb9u3
ii libdb5.3 5.3.28-12+deb9u1
ii libicu57 57.1-6+deb9u2
ii libsasl2-2 2.1.27~101-g0780600+dfsg-3
ii libssl1.1 1.1.0j-1~deb9u1
ii lsb-base 9.20161125
ii netbase 5.4
ii postfix-sqlite 3.1.8-0+deb9u1
ii ssl-cert 1.0.39
Versions of packages postfix recommends:
ii python3 3.5.3-1
Versions of packages postfix suggests:
ii bsd-mailx [mail-reader] 8.1.2-0.20160123cvs-4
pn dovecot-common <none>
ii libsasl2-modules 2.1.27~101-g0780600+dfsg-3
pn postfix-cdb <none>
ii postfix-doc 3.1.8-0+deb9u1
ii postfix-ldap 3.1.8-0+deb9u1
pn postfix-lmdb <none>
pn postfix-mysql <none>
ii postfix-pcre 3.1.8-0+deb9u1
pn postfix-pgsql <none>
pn procmail <none>
pn resolvconf <none>
ii s-nail [mail-reader] 14.8.16-1
ii sasl2-bin 2.1.27~101-g0780600+dfsg-3
pn ufw <none>
-- debconf information excluded
Subject: Re: Bug#916191: /usr/lib/postfix/sbin/smtpd: Sometimes smtpd unable to authenticate a client via SASL GSSAPI
Date: Tue, 11 Dec 2018 02:46:04 -0500
On Tuesday, December 11, 2018 10:28:39 AM Igor Goldenberg wrote:
> Package: postfix
> Version: 3.1.8-0+deb9u1
> Severity: important
> File: /usr/lib/postfix/sbin/smtpd
>
> Dear Maintainer,
>
> after upgrading Debian from 8/jessie to 9/stretch I've started to
> receive periodical errors while client tries to send an email with
> authentication via Kerberos/GSSAPI via Postfix.
>
> The MUA is a Thunderbird 60.2.1 on Windows Server 2016 in AD ___domain.
> Thunderbird setted up to use STARTTLS with Kerberos / GSSAPI
> authentication method. Sometimes client got Kerberos error (ticket
> Kerberos/GSSAPI was not received by SMTP server) in the MUA and in the
> log I can see:
>
> Dec 11 09:40:00 mx1 postfix/smtpd[9857]: warning: SASL authentication
> failure: Requested identity not authenticated identity Dec 11 09:40:00 mx1
> postfix/smtpd[9857]: warning: unknown[192.168.1.3]: SASL GSSAPI
> authentication failed: authentication failure
>
> About 4-5% of total authenticaions has such error (~20 of total ~500 in
> a day). If user in the Thunderbird close error window and try to send
> an email again it usually sends successfully. It's non needed to relog on
> the windows server or restart a mail client, just do another try.
>
> Kerberos authentication also used in the Cyrus IMAP server on the same
> Debian host and there are no any errors with Kerberos at all. So I think
> something wrong on the Postfix side.
...
> I think Postfix incorrectly use or 'auth_identity' or 'requested_user'
> sometimes when calls SASL auth checking.
>
> I was unable to find SASL call with identity and user arguments while
> debug (at level 5) SMTP session between client and server.
Typically high debug levels are so verbose it's hard to find anything.
I reviewed the Cyrus SASL related code changes in the versions between and
there are virtually no changes between Jessie and Stretch postfix versions.
The postfix 2.11.3-1+deb8u2 from Jessie should work on Stretch. Can you try
downgrading your postfix to the Jessie version? It will also need the Jessie
libssl1.0.0. Additionally, depending on how much modernization of your
postfix configuration you've done, you may have to adjust it to work with the
older postfix version.
If authentication is problematic with postfix 2.11.3-1+deb8u2 also, then that
points either to a problem in Cyrus or a change that was made there that needs
some adjustment on the postfix side. If authentication works fine with the
older postfix, then that points to a regression in postfix.
Scott K
Acknowledgement sent
to Игорь Гольденберг <[email protected]>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <[email protected]>.
(Tue, 11 Dec 2018 09:03:03 GMT) (full text, mbox, link).
Subject: Re: Bug#916191: /usr/lib/postfix/sbin/smtpd: Sometimes smtpd unable
to authenticate a client via SASL GSSAPI
Date: Tue, 11 Dec 2018 13:50:47 +0500
> Can you try downgrading your postfix to the Jessie version?
I’m afraid it’s too hard to downgrade working production server for the experiment.
As it’s possible to ignore an error and send mail again this problem is annoying but not so critical for mail server users. But downtime for the testing will be a problem, sorry.
Subject: Re: Bug#916191: /usr/lib/postfix/sbin/smtpd: Sometimes smtpd unable to authenticate a client via SASL GSSAPI
Date: Tue, 11 Dec 2018 07:07:28 -0500
On Tuesday, December 11, 2018 01:50:47 PM Игорь Гольденберг wrote:
> > Can you try downgrading your postfix to the Jessie version?
>
> I’m afraid it’s too hard to downgrade working production server for the
> experiment.
>
> As it’s possible to ignore an error and send mail again this problem is
> annoying but not so critical for mail server users. But downtime for the
> testing will be a problem, sorry.
OK. I can certainly understand that.
Scott K
Acknowledgement sent
to Lucas Castro <[email protected]>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <[email protected]>.
(Sat, 19 Jun 2021 00:06:03 GMT) (full text, mbox, link).
Subject: Re: /usr/lib/postfix/sbin/smtpd: Sometimes smtpd unable to
authenticate a client via SASL GSSAPI
Date: Fri, 18 Jun 2021 20:55:32 -0300
Hello, I was trying this bug,
I guess there is no bug right here.
On Tue, 11 Dec 2018 10:28:39 +0500 Igor Goldenberg
<[email protected]> wrote:> Package: postfix
> Version: 3.1.8-0+deb9u1
> Severity: important
> File: /usr/lib/postfix/sbin/smtpd
>
> Dear Maintainer,
>
> after upgrading Debian from 8/jessie to 9/stretch I've started to
> receive periodical errors while client tries to send an email with
> authentication via Kerberos/GSSAPI via Postfix.
>
> The MUA is a Thunderbird 60.2.1 on Windows Server 2016 in AD ___domain.
> Thunderbird setted up to use STARTTLS with Kerberos / GSSAPI
> authentication method. Sometimes client got Kerberos error (ticket
> Kerberos/GSSAPI was not received by SMTP server) in the MUA and in the
> log I can see:
>
> Dec 11 09:40:00 mx1 postfix/smtpd[9857]: warning: SASL authentication
failure: Requested identity not authenticated identity
> Dec 11 09:40:00 mx1 postfix/smtpd[9857]: warning:
unknown[192.168.1.3]: SASL GSSAPI authentication failed: authentication
failure
>
> About 4-5% of total authenticaions has such error (~20 of total ~500 in
> a day). If user in the Thunderbird close error window and try to send
> an email again it usually sends successfully. It's non needed to relog on
> the windows server or restart a mail client, just do another try.
>
> Kerberos authentication also used in the Cyrus IMAP server on the same
> Debian host and there are no any errors with Kerberos at all. So I think
> something wrong on the Postfix side.
>
> Here is the SASL source code where this error ("Requested identity not
> authenticated identity") rises.
>
> File lib/common.c, begining from line 2625:
>
> static int
> _sasl_proxy_policy(sasl_conn_t *conn,
> void *context __attribute__((unused)),
> const char *requested_user, unsigned rlen,
> const char *auth_identity, unsigned alen,
> const char *def_realm __attribute__((unused)),
> unsigned urlen __attribute__((unused)),
> struct propctx *propctx __attribute__((unused)))
> {
> if (!conn)
> return SASL_BADPARAM;
>
> if (!requested_user || *requested_user == '\0')
> return SASL_OK;
Over here you can check if the client (MUA) not send a user
(request_user), it just return SASL_OK.
mutt as example,
set smtp_url = 'smtp://postfix00.zw.local:25/'
if set just as above, no request_user exist.
but instead of that it is set
set smtp_url = 'smtp://[email protected]:25/'
so the authentication will get into next step.
>
> if (!auth_identity || !requested_user || rlen != alen ||
> (memcmp(auth_identity, requested_user, rlen) != 0)) {
> sasl_seterror(conn, 0,
> "Requested identity not authenticated identity");
> RETURN(conn, SASL_BADAUTH);
> }
>
> return SASL_OK;
> }
So if the request user at smtp_url differ from sasl authenticated user
it stops and return error.
>
> I think Postfix incorrectly use or 'auth_identity' or 'requested_user'
I really make up this setup and test both situation.
I think it's good to set this "bug" as not a bug.
--
Lucas Castro
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.