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
------------------------------------
... 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
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
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
<goldenberg@metalural.ru> 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://user@postfix00.zw.local: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.