patch: KDC default referral feature

[Richard Silverman]

On Wed, 2 Jan 2013, Greg Hudson wrote:

> On 01/02/2013 11:16 AM, Richard Silverman wrote:
>> I submitted a pull request to the MIT Kerberos GitHub repository 12 days
>> ago:
>
>> https://github.com/krb5/krb5/pull/9
>
> Thanks for submitting this.  I've redirected this thread to
> krbdev at mit.edu, which is for discussing MIT krb5 development.
> kerberos at mit.edu is for discussing usage of Kerberos 5 and isn't
> specific to the MIT krb5 implementation.
>
> I did glance at this when you sent it in, but we haven't had a chance to
> discuss it as a team.  While we very much appreciate any contribution,
> we have a number of requirements for accepting new features, some of
> which are documented at:
>
>    http://k5wiki.kerberos.org/wiki/Contributing_code
>
> The most important requirement is an evaluation of whether we want the
> new feature at all, or want it with design changes.  Our process for
> this is to have a write-up of the proposal as a "project page" on the
> wiki and discuss it on this list.

Thanks for the followup. So, shall I create a wiki page (assuming that I
can), or should we just start with the discussion here?

> Personally, I have some concerns that this feature is too specific
> within the general space of producing realm referrals,

I'm not sure what you mean by this?

> and carries too great a risk of causing referral loops.

That's certainly a concern. The restriction to issuing a default referral
only if the presented TGT is not cross-realm has been entirely effective
for us so far as I can tell, though of course it's not perfect generally
speaking.

> (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, while Windows clients follow
referrals from AD. But the KDC does not examine the DNS, and it doesn't
seem easy to have it do so. You certainly don't want the KDC to block on
DNS lookups while it's servicing ticket requests, so these would have to
be done in a multi-threaded or asychronous manner, and I didn't see any
easy way to accomplish that in the current KDC code. Using the existing
domain_realm mechanism means keeping that configuration file in sync with
hosts as they come and go, which duplicates existing configuration data
and is not practical for us. I find it also doesn't work well in practice
due to caching issues. Windows appears to aggressively cache results of
ticket and realm lookups. If someone tries to use a delegated TGT as I
described to access a service on a new AD host which is not yet in the KDC
configuration, Windows caches the negative referral result, so that even
if it is added it is not usable for quite some time thereafter without
restarting the service (or sometimes the entire server) involved. I
haven't found any knobs for this behavior.

Overall, this features allows our clients to find services via discovery,
rather than maintaining more per-host configuration in more places. Our
only other option was maintaining keytabs on Unix hosts for AD principals
and using them directly (in order for delegation to work), rather than
using existing Unix-realm identities with cross-realm trust, which was
administratively awkward in various ways. I agree this feature is a bit
special-purpose, but it's been very effective for us and I imagine we're
not alone in this situation, so I thought it might be useful for
others. And of course, it would also be nice to have it accepted upstream
and not have to maintain the patch here indefinitely.

> A second requirement is that we only apply new changes to master, not to
> a release branch.  Both the KDC code and our documentation source format
> have changed significantly since 1.10.
>
> We would also require a new change like this to have automated tests.

I will be happy to make these changes and additions if the feature is
accepted in some form.

-- 
   Richard