patch: KDC default referral feature

[Richard Silverman]

On Wed, 2 Jan 2013, Richard Silverman wrote:

> On Wed, 2 Jan 2013, Greg Hudson wrote:
>
>> On 01/02/2013 12:56 PM, Richard Silverman wrote:
>>>> (I'm also not sure why you can't get almost all of the desired behavior
>>>> with the existing [domain_realm] referral support.)
>> 
>>> As I mentioned in the initial writeup, our host/realm mapping is not lined
>>> up with host domain names, and Unix clients normally find realms using
>>> _kerberos DNS TXT records for this reason [...]
>> 
>> I'm not suggesting you keep the complete map in the KDC configuration.
>> I'm suggesting that a single [domain_realm] entry for ".domain = AD"
>> would have basically the same effect as "default_referral_realm = AD".
>
> That's true as far as the referral target is concerned; the real point of
> the feature, though, is the option to refuse to issue a referral for a
> cross-realm TGT in order to avoid loops -- and as I think about it,
> perhaps it's better to just implement that, if you can you have a true
> catch-all in [domain_realm] with "* = AD" or ". = AD", or some such.

Some further thoughts on this: I think it didn't occur to me to do this
initially because my KDC uses the same krb5.conf as everyone else, and I
can't put this mapping where clients can see it: there are hosts in this
DNS domain which are not in the AD realm. It wouldn't only cause extra
referral hops; it would break some clients completely: a Unix client with
a Unix-realm TGT which misidentifies a Unix-realm service as being in AD
loses due to the MIT KDC lineage check. Now, I could certainly give this
realm mapping to the KDC alone in kdc.conf, as long as it wouldn't mess up
anything else.

Btw, as a separate issue think the lineage check should have an off
button. I think I understand the purpose: there's no good reason why a
principal should present a cross-realm TGT for a service in its own realm,
and it suggests a possible compromise of a trusted realm. However in a
world of referrals there are understandable (if perhaps not exactly
*good*) reasons for this to happen. If I had truly foreign trusted realms,
I would want this check on. However, all my realms are under my direct
control (I have multiple realms for technical rather than administrative
reasons), so I'm not concerned about that, and am more concerned about
allowing these legitimate (though non-optimal) TGS requests to succeed.

I did in fact disable this check for a while for this very reason. Until
we got our Unix-based Java clients to use the MIT Kerberos libraries
instead of the (limited and buggy) native Java GSSAPI/Kerberos
implementation in the JDK, this happened to us because Java clients did
not use the DNS realm records. As it happens now I have no legitimate
cases of this, so I prefer to have such requests fail to reveal whatever
configuration problem is at hand, but I would disable the lineage check
again if I needed to for similar reasons.

-- 
   Richard