bug: krb5_get_host_realm() no longer uses DNS

Greg Hudson ghudson at MIT.EDU
Wed May 19 17:58:41 EDT 2010


On Wed, 2010-05-19 at 16:15 -0400, Richard Silverman wrote:
> From krb5.conf(5): [...]

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

The documentation is certainly vague, in that it doesn't indicate when
DNS lookups will be used (for instance, it doesn't say that explicit
local configuration takes precedence).  I'm not sure it's inaccurate.

> I don't understand how this will break referrals.

The design of referrals support assumes that referrals from the local
realm are less reliable than explicit local configuration, and more
reliable than DNS-based or heuristic mechanisms.  Per that design, the
following changes are intentional:

* krb5_get_host_realm() returns the referral (empty) realm if there is
no explicit local configuration.

* krb5_sname_to_principal() uses the referral realm if there is no
explicit location configuration for the host.

* krb5_get_credentials() queries the local realm if asked to obtain
tickets in the referral realm.  If the local realm can't provide a
successful response, krb5_get_fallback_host_realm() is invoked and that
is tried.

If krb5_get_host_realm() continued to use DNS-based and heuristic
methods for determining the service realm, then they would take
precedence over the local realm's referral information.

Although the acceptor case was apparently not considered in the
referrals design, the issue was raised prior to the 1.6 release; see:

http://mailman.mit.edu/pipermail/krbdev/2006-December/005351.html
http://krbdev.mit.edu/rt/Ticket/Display.html?id=5121&user=guest&pass=guest

The resolution was to match against the default realm in this case, and
that code was placed in krb5_kt_get_entry() in ktfns.c.

I won't unconditionally defend the design decisions made for krb5 1.6
referrals support, as I wasn't present to help make them, but the
inconvenient answer is that this behavior change was not simply a bug.

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

You appear to know your options reasonably well; for what it's worth, I
would recommend either:

1. Setting GSSAPIStrictAcceptorCheck false on your servers, and not
worrying too much about the potential for a client to use the "wrong"
service to authenticate to sshd.

2. Configuring each server to know what realm it's in (via the default
realm setting in krb5.conf).  Based on your statements, this is more
configuration complexity than you want in your environment, but it's
more secure than having your servers perform a spoofable DNS TXT query
to find out where the live.





More information about the Kerberos mailing list