Re: Dovecot SASL GSSAPI regression with krb5 1.18

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/[email protected]" 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             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev