bug: krb5_get_host_realm() no longer uses DNS

[Richard Silverman]

On Mon, 17 May 2010, Greg Hudson wrote:

> 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.

OK, but that's totally undocumented.  From krb5.conf(5):

      dns_lookup_realm

           Indicate  whether  DNS  TXT  records  should be used to
           determine the Kerberos realm of a host.  The default is
           not to use these records.

It says nothing about varying behavior depending on the context of the
realm lookup attempt.  The documented behavior used to work; now it
doesn't.  This is a regression.

> 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?

Yes, exactly.

> If so, there are a variety of ways to address that...

Suggestions are welcome... :)

> --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.

I don't understand how this will break referrals.  Referral support means
recognizing and following referrals when you get them.  In the case of
acquiring a ticket, the client first determines a realm to which to send
the TGS_REQ, based on administrative configuration -- which includes
static configuration such as krb5.conf, *and* DNS TXT rrs (if turned on).
If the KDC it then talks to happens to know better, good; we'll follow the
referral.  But the two issues are separate.  And obeying configuration is
critical in the case of a host determining a realm without issuing an
ticket request (as when a server comes up); the sysadmin must be able to
indicate the realms of his hosts, and it shouldn't require a few thousand
entries in [domain_realm], or completely redoing his DNS and renaming many
or all of his hosts.

To be clear: I have thousands of hosts in a single DNS domain, which are
in varying realms.  I do not have the option of renaming all the hosts to
align with their realm membership, and static configuration is
impractical; the DNS is necessary.

- Richard