On Mon, 2010-05-17 at 16:32 -0400, Richard Silverman wrote: > To me it seems simpler: krb5_get_host_realm() should, well... return the > realm of the host. :) If Kerberos is configured to do this via > [libdefaults] dns_lookup_realm = yes, then it should do so > consistently.
krb5_get_host_realm() cannot return "the realm of the host" if that realm is best determined via referrals. The configuration parameter applies (post-1.6) to the behavior of krb5_get_credentials() if configuration and referrals fail to produce an answer as to the realm of the host. It would be consistent with pre-1.6 behavior to make that variable also apply to krb5_get_host_realm() if configuration produces no answer, but not consistent with the value used by post-1.6 krb5_get_credentials(). > Well, often this is not possible; many servers have determination of their > service principal hard-wired. [...] So... the practical concern here is that without GSSAPIStrictAcceptorCheck false (or with stock OpenSSH), sshd fails if the local hostname's realm cannot be determined through hardcoded configuration, because gss_acquire_cred can't find "host/localhostname@" in the keytab? If so, there are a variety of ways to address that--but that problem is only indirectly related to the behavior of krb5_get_host_realm(). The responsibility chain here is gss_import_name -> krb5_sname_to_principal -> krb5_get_host_realm. If krb5_get_host_realm were reverted to the pre-1.6 behavior, then krb5_sname_to_principal's behavior would revert, causing gss_acquire_cred to succeed when it (I assume) currently fails--but that would also have the effect of breaking client referrals support. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
