[32371] in Kerberos
Re: bug: krb5_get_host_realm() no longer uses DNS
daemon@ATHENA.MIT.EDU (Richard Silverman)
Wed May 19 16:19:20 2010
Date: Wed, 19 May 2010 16:15:01 -0400 (EDT)
From: Richard Silverman <res@qoxp.net>
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <1274131561.2419.246.camel@ray>
Message-ID: <Pine.LNX.4.64.1005191503430.9389@seraph.oankali.net>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
