[exim-dev] [Bug 1498] New: AUTH GSSAPI does not work with cr…

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Andreas Metzler
日付:  
To: exim-dev
題目: [exim-dev] [Bug 1498] New: AUTH GSSAPI does not work with cross-realm
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1498
           Summary: AUTH GSSAPI does not work with cross-realm
           Product: Exim
           Version: 4.80.1
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: SMTP Authentication
        AssignedTo: pdp@???
        ReportedBy: eximusers@???
                CC: exim-dev@???



Hello,

this is <http://bugs.debian.org/752853> submitted by Jaap Winius:
--------------------
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@???
7280 Cyrus SASL GSSAPI negotiated SSF: 0
7280 sasl_gssapi authenticator server_condition:
7280 $auth1 = jwinius@???
7280 $1 = jwinius@???
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@???, while in the second
case it's a Debian wheezy machine running Iceweasel 24.6.0 with a
jwinius@??? 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.
--------------------


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email