When Exim4 is configured to support AUTH GSSAPI, this does not work
when cross-realm authentication is used -- only when clients have a
Kerberos ticket for the same realm. Cross-realm authentication will
work properly with other services on the same machine, such as SSH and
Dovecot IMAP, but not with Exim4.

To illustrate, I've included two sets of Exim4 debug output, some
lines of which have been shortened: one set with a successful
authentication and the other with a failure.

The first involves a client using a Kerberos ticket from the same
realm and results in a successful authentication:

  7280 ...
  7280 SMTP>> 250-hello.ebdeep.nl Hello bitis.umrk.nl [82.95.126.201]
  7280 250-SIZE 268435456
  7280 250-8BITMIME
  7280 250-AUTH GSSAPI
  7280 250 HELP
  7280 Calling gnutls_record_recv(0x7f45d639b5f0, 0x7f45d639fa30, 4096)
  7280 Calling gnutls_record_recv(0x7f45d639b5f0, 0x7f45d639fa30, 4096)
  7280 SMTP<< AUTH GSSAPI YIICggYJKoZIhvcSAQICAQ ... a7dywKw9uSiRsrIqRvPA0g==
  7280 Initialised Cyrus SASL server connection; service="smtp"
fqdn="hello.ebdeep.nl" realm="DAPADAM.NL"
  7280 Cyrus SASL set EXTERNAL SSF to 128
  7280 Calling sasl_server_start(GSSAPI,"YIICggY ... dywKw9uSiRsrIqRvPA0g==")
  7280 SMTP>> 334 YIGZBgkqhkiG9xIBAgICAG+BiTCBhq ... X/45CnWuLqKO6mxQL36Uzofe
  7280 tls_do_write(0x7f45d6358730, 214)
  7280 gnutls_record_send(SSL, 0x7f45d6358730, 214)
  7280 outbytes=214
  7280 Calling gnutls_record_recv(0x7f45d639b5f0, 0x7f45d639fa30, 4096)
  7280 Calling gnutls_record_recv(0x7f45d639b5f0, 0x7f45d639fa30, 4096)
  7280 SMTP<<
  7280 Calling sasl_server_step("")
  7280 SMTP>> 334 BQQF/wAMAAAAAAAAIgiYcgEAAABoYMqAQcSMI6LY2Ws=
  7280 tls_do_write(0x7f45d6358730, 50)
  7280 gnutls_record_send(SSL, 0x7f45d6358730, 50)
  7280 outbytes=50
  7280 Calling gnutls_record_recv(0x7f45d639b5f0, 0x7f45d639fa30, 4096)
  7280 Calling gnutls_record_recv(0x7f45d639b5f0, 0x7f45d639fa30, 4096)
  7280 SMTP<< BQQE/wAMAAAAAAAAIEXR/QEAAABqd2luaXVzeGET6yg4i7WxWq8G
  7280 Calling sasl_server_step("BQQE/wAMAAAAAAA ... luaXVzeGET6yg4i7WxWq8G")
  7280 Cyrus SASL GSSAPI authentication succeeded for jwinius@DAPADAM.NL
  7280 Cyrus SASL GSSAPI negotiated SSF: 0
  7280 sasl_gssapi authenticator server_condition:
  7280   $auth1 = jwinius@DAPADAM.NL
  7280   $1 = jwinius@DAPADAM.NL
  7280 SMTP>> 235 Authentication succeeded
  7280 ...

This second example is of an authentication failure involving a client
with Kerberos ticket from a foreign, albeit trusted realm:

13448 ...
13448 SMTP>> 250-hello.ebdeep.nl Hello bitis.umrk.nl [82.95.126.201]
13448 250-SIZE 268435456
13448 250-8BITMIME
13448 250-AUTH GSSAPI
13448 250 HELP
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 SMTP<< AUTH GSSAPI YIICUAYJKoZIhvcSAQICAQ ... k3bEkmKVJoPJo/84ZQIN/pc=
13448 Initialised Cyrus SASL server connection; service="smtp"
fqdn="hello.ebdeep.nl" realm="DAPADAM.NL"
13448 Cyrus SASL set EXTERNAL SSF to 128
13448 Calling sasl_server_start(GSSAPI,"YIICUAY ... bEkmKVJoPJo/84ZQIN/pc=")
13448 SMTP>> 334 YIGZBgkqhkiG9xIBAgICAG+BiTCBhq ... JMUoa345XJ4rV9J7g8Q7l5Br
13448 tls_do_write(0x7f3eca23c730, 214)
13448 gnutls_record_send(SSL, 0x7f3eca23c730, 214)
13448 outbytes=214
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 SMTP<<
13448 Calling sasl_server_step("")
13448 SMTP>> 334 BQQF/wAMAAAAAAAAHB6hYwEAAAA8eyFNZeXq5Fs4j7w=
13448 tls_do_write(0x7f3eca23c730, 50)
13448 gnutls_record_send(SSL, 0x7f3eca23c730, 50)
13448 outbytes=50
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 SMTP<< BQQE/wAMAAAAAAAAJF/wrAEAAABqd2luaXVzCUv6EURTgAGEo6yT
13448 Calling sasl_server_step("BQQE/wAMAAAAAAA ... luaXVzCUv6EURTgAGEo6yT")
13448 Cyrus SASL permanent failure -13 (authentication failure)
13448 LOG: REJECT
13448   sasl_gssapi authenticator (GSSAPI):
13448   Cyrus SASL permanent failure: authentication failure
13448 SMTP>> 535 Incorrect authentication data
13448 tls_do_write(0x7f3eca23c730, 35)
13448 gnutls_record_send(SSL, 0x7f3eca23c730, 35)
13448 outbytes=35
13448 LOG: MAIN REJECT
13448   sasl_gssapi authenticator failed for bitis.umrk.nl
([192.168.2.20]) [82.95.126.201]: 535 Incorrect authentication data
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 SMTP<< QUIT
13448 SMTP>> 221 hello.ebdeep.nl closing connection
13448 tls_do_write(0x7f3eca23c730, 40)
13448 gnutls_record_send(SSL, 0x7f3eca23c730, 40)
13448 outbytes=40
13448 tls_close(): shutting down TLS
13448 LOG: smtp_connection MAIN
13448   SMTP connection from bitis.umrk.nl ([192.168.2.20])
[82.95.126.201] closed by QUIT
13448 search_tidyup called

Perhaps it's worth mentioning that, despite this failure, the client
received a Kerberos service ticket anyway.

Some background. In both cases the client connection is initiated from
the umrk.nl network at 82.95.126.201 and connects to hello.ebdeep.nl
at 80.101.160.10, which is part of the DAPADAM.NL realm. In the first
case, the client is an OS X machine running Mozilla Thunderbird 24.6.0
and has a Kerberos ticket for jwinius@DAPADAM.NL, while in the second
case it's a Debian wheezy machine running Iceweasel 24.6.0 with a
jwinius@UMRK.NL ticket. The UMRK.NL realm is trusted by DAPADAM.NL and
cross-realm authentication works for other Kerberized services in use.
The wheezy client has no trouble using AUTH GSSAPI to submit mail via
the local Exim4 server, bitis.umrk.nl with realm UMRK.NL.

Control: forwarded 752853 http://bugs.exim.org/show_bug.cgi?id=1498
[...]

Hello,

I have forwarded this upstream (URL at top of mail) and would appreciate if
you could subcribe to the bugreport followup there if necessary.

Would it possible for you to check whether this is still present in 4.83_rc2?

Thanks, cu Andreas

Quoting Andreas Metzler <ametzler@bebt.de>:

Sure.

Yes, it would. I obtained a copy of the source code from Debian
experimental, but since compiling it on wheezy requires that various
critical packages also be upgraded, I decided to run this test on a
virtual machine. Nevertheless, I set up this machine up as a member of
the DAPADAM.NL realm so that same-realm Kerberos authentication worked
for SSH, Dovecot IMAP and Exim. More importantly, cross-realm
authentication worked for SSH and Dovecot IMAP. Sadly, though, Exim
4.83_rc2 refused to accept cross-realm authentication result just as
it does with 4.80-7, so the bug is still present.

Except for a few extra Cyrus SASL lines, the Exim debug output for
this kind of failure with 4.83_rc2 is identical to what it is with
4.80-7:

  6199 ...
  6199 SMTP>> 250-cerastes.dapadam.nl Hello atheris.umrk.nl [192.168.2.20]
  6199 250-SIZE 268435456
  6199 250-8BITMIME
  6199 250-AUTH GSSAPI
  6199 250 HELP
  6199 Calling gnutls_record_recv(0xb88a9780, 0xb8ba1580, 4096)
  6199 Calling gnutls_record_recv(0xb88a9780, 0xb8ba1580, 4096)
  6199 SMTP<< AUTH GSSAPI YIICUgYJKoZIhvcSAQ ... b/3Y1sJ80PWDcR9prw==
  6199 Initialised Cyrus SASL server connection; service="smtp"
fqdn="cerastes.dapadam.nl" realm="DAPADAM.NL"
  6199 Cyrus SASL set EXTERNAL SSF to 128
  6199 Cyrus SASL set local hostport to: 192.168.2.13;25
  6199 Cyrus SASL set peer hostport to: 192.168.2.20;54405
  6199 Calling sasl_server_start(GSSAPI,"YII ... 3Y1sJ80PWDcR9prw==")
  6199 SMTP>> 334 YIGZBgkqhkiG9xIBAgICAG+BiT ... i98ChosvjBmbz8kJHOXj
  6199 tls_do_write(0xb8878870, 214)
  6199 gnutls_record_send(SSL, 0xb8878870, 214)
  6199 outbytes=214
  6199 Calling gnutls_record_recv(0xb88a9780, 0xb8ba1580, 4096)
  6199 Calling gnutls_record_recv(0xb88a9780, 0xb8ba1580, 4096)
  6199 SMTP<<
  6199 Calling sasl_server_step("")
  6199 SMTP>> 334 BQQF/wAMAAAAAAAAFdqCVwEAAABJ3AG88l8KrJHuSWA=
  6199 tls_do_write(0xb8878870, 50)
  6199 gnutls_record_send(SSL, 0xb8878870, 50)
  6199 outbytes=50
  6199 Calling gnutls_record_recv(0xb88a9780, 0xb8ba1580, 4096)
  6199 Calling gnutls_record_recv(0xb88a9780, 0xb8ba1580, 4096)
  6199 SMTP<< BQQE/wAMAAAAAAAAK2wCCQEAAABqd2luaXVz31NvoPPqHuoDQ3Qo
  6199 Calling sasl_server_step("BQQE/wAMAAA ... Vz31NvoPPqHuoDQ3Qo")
  6199 Cyrus SASL permanent failure -13 (authentication failure)
  6199 LOG: REJECT
  6199   sasl_gssapi authenticator (GSSAPI):
  6199   Cyrus SASL permanent failure: authentication failure
  6199 SMTP>> 535 Incorrect authentication data
  6199 tls_do_write(0xb8878870, 35)
  6199 gnutls_record_send(SSL, 0xb8878870, 35)
  6199 outbytes=35
  6199 LOG: MAIN REJECT
  6199   sasl_gssapi authenticator failed for atheris.umrk.nl
[192.168.2.20]: 535 Incorrect authentication data
  6199 Calling gnutls_record_recv(0xb88a9780, 0xb8ba1580, 4096)
  6199 Calling gnutls_record_recv(0xb88a9780, 0xb8ba1580, 4096)
  6199 SMTP<< QUIT
  6199 SMTP>> 221 cerastes.dapadam.nl closing connection
  6199 tls_do_write(0xb8878870, 44)
  6199 gnutls_record_send(SSL, 0xb8878870, 44)
  6199 outbytes=44
  6199 tls_close(): shutting down TLS
  6199 LOG: smtp_connection MAIN
  6199   SMTP connection from atheris.umrk.nl [192.168.2.20] closed by QUIT
  6199 search_tidyup called

Cheers,

Jaap