Kerberos dev project for review: domain_realm mapping via KDCreferral
Tim.Alsop at CyberSafe.Com
Tue Apr 29 15:45:04 EDT 2008
I am wondering why this feature not being described in an IETF draft, so
that other non-MIT clients can be interoperable with MIT KDC and other
KDCs can have this feature added to be interoperable with MIT clients ?
Or, is the intention to decide on the features and implementation and
then write a draft later ?
I am also interested to know how this relates to the existing IETF draft
for referrals, and whether there will be a conflict if both this method
and the proposed method being described in the referrals draft are
implemented at same time ? Does one supersede the other ?
From: krbdev-bounces at MIT.EDU [mailto:krbdev-bounces at MIT.EDU] On Behalf
Of Ken Raeburn
Sent: 29 April 2008 20:33
To: John Hascall
Cc: MIT Kerberos Dev List
Subject: Re: Kerberos dev project for review: domain_realm mapping via
On Apr 29, 2008, at 14:16, John Hascall wrote:
> PLEASE, no more evilness like the compiled in krb5_524_conv_principal
> table (which we have ripped out and replaced with a config-file option
> here since 1.0.5 BTW).
I would ask for a patch, except I'm hesitant to put more realm-wide
config information into the config files that have to manually be kept
in sync across all KDCs. (Yes, some of it could be automated, if one
wanted, but with potential per-KDC config options like pw-checking
plugins in there too, it's not simply copying the file from KDC to
KDC.) This sort of info should be maintained per-realm and
distributed with the other per-realm data (principals, key, policies),
but that's another project.
Of course, the domain_realm mapping would now affect the KDC behavior
in a way where it should be kept in sync realm-wide. *sigh*
> As others have mentioned, I think it makes more sense to
> treat */looks.like.an.fqdn as a "host_based_service" unless
> there is a config-file option to turn it off. Perhaps:
> no_host_referral = host ftp
> (why you want to turn those two off escapes me, but go with it)
> and perhaps even an option to just turn it off entirely:
> host_referral = no
Yeah, I'm starting to think that defaulting to host-principal
treatment is the better way to go, unless Russ's unease turns into a
real use case with bad behavior. (I confess to a little unease
myself, but I think it's just reluctance to change the default
Is there really a need to turn this code off? It shouldn't make any
difference in returned data unless someone is actually talking to the
KDC for the wrong realm and requesting a referral. The KDC does to a
bit more work, mainly examining the domain_realm mapping data.
krbdev mailing list krbdev at mit.edu
More information about the krbdev