[20070] in Kerberos_V5_Development
Re: Dovecot SASL GSSAPI regression with krb5 1.18
daemon@ATHENA.MIT.EDU (=?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F)
Mon Mar 30 09:16:46 2020
Message-ID: <310fa6435721f38aaf5f830432a785486fc25ed9.camel@aegee.org>
From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?=
=?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?=
<dilyan.palauzov@aegee.org>
To: krbdev@mit.edu
Date: Mon, 30 Mar 2020 13:16:15 +0000
In-Reply-To: <r5sng6$ivf$1@ciao.gmane.io>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Hello,
I also got had a GSSAPI SASL regression back in Fall 2019 (Krb 1.17) which was fixed by revering
https://github.com/cyrusimap/cyrus-sasl/commit/238380260fe623212c0f21d63e . As on git/cyrus-sasl several things were
changed and reverted recenlty, try with the newest cyrus-SASL (I do not understand low-lever GSSAPI, the c-interface, or
the protocol details, but I got it working for me and now I do not want to change anything).
Greetings
Dilyan
On Mon, 2020-03-30 at 15:08 +0300, Mantas Mikulėnas wrote:
> Hello,
>
> I have a mostly normal Dovecot 2.3.10 configuration with SASL GSSAPI:
>
> auth_mechanisms = anonymous plain gssapi
> # auth_gssapi_hostname is unset
> auth_krb5_keytab = /etc/dovecot/dovecot.keytab
> auth_verbose = true
>
> This used to work with MIT Kerberos version 1.17.1, and Dovecot would
> automatically determine the system's FQDN and would find the principal
> "imap/wolke.nullroute.eu.org@NULLROUTE.EU.ORG" in its keytab.
>
> However, the principal search broke after upgrading to 1.18 -- now, each
> authentication attempt reports:
>
> dovecot[1367034]: auth: gssapi(...): While acquiring service
> credentials: Unspecified GSS failure. Minor code may provide more
> information
> dovecot[1367034]: auth: gssapi(...): While acquiring service
> credentials: No key table entry found matching imap/.nullroute.eu.org@
>
> I have tracked this down to commit 99635376 "Qualify short hostnames
> when not using DNS". I'm still not entirely sure what is happening here,
> but it seems to me that Dovecot tries to pass an empty hostname to
> GSSAPI -- despite its docs saying that auth_gssapi_hostname should
> default to gethostname() -- and Krb5 canonicalizes that empty string
> resulting in a garbage domain name.
>
> For now I can work around the issue in various ways: I could set
> 'qualify_shortname = ""' in krb5.conf to revert to old 1.17 behavior, or
> I could set 'auth_gssapi_hostname' in Dovecot to *actually* hold the
> system hostname or even the correct FQDN.
>
> However, I'd much rather have everything work "by default" -- it did
> work in previous versions, after all -- and it seems to me that the
> check in k5_expand_hostname() should avoid canonicalization when `host`
> is an empty string, too.
>
> So would this be considered a bug in krb5, or is it an expected change
> in behavior? (In addition to what I assume is a bug in Dovecot itself)
>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
