[3899] in Kerberos
Re: hierarchical realms
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Thu Sep 22 14:54:48 1994
To: kerberos@MIT.EDU
Date: 22 Sep 1994 18:39:10 GMT
From: marc@cam.ov.com (Marc Horowitz)
Sorry, Derek, but I have to agree with Tai here.
>> But this is three entries, when we really only needed two, since
>> lcs.mit.edu defaults to LCS.MIT.EDU without a krb.realms entry.
This is a weak argument. I'd rather have one extra entry in the
krb.conf file which duplicated a "default" than have many extra
entries for domains which could be handled by a longest-match-wins
algorithm. (Personally, I'd go for first-match-wins, since it gives
the admin a little more control, and it's easier to implement.)
>> For example, the lcs.mit.edu domain is administratively different than
>> Athena (which runs the mit.edu namespace). Therefore they have
>> different kerberos realms.
There are reasons an organization might want to divide up a domain
into subdomains, but continue using a single Kerberos realm. Examples
might be subdepartments within a department using a departmental
Kerberos server, or a test domain within a production domain.
>> For example, if you have ponderous.cc.your.site and
>> ponderous.xx.your.site, but cc.your.site and xx.your.site share a
>> kerberos realm, you now have a name conflict! How do you solve that?
>> By making sure all the names are in a flat namespace! But if you are
>> doing that, then why subdomain in the first place?
No, you solve the problem by going to Kv5, which uses canonical
hostnames for host-based service principal names. The Kv4 naming is
bogus, and, thankfully, it has been fixed.
>> If it requires you to have N-squared shared keys so that your N
>> subdomains work together, well, so be it. But that is a much better
>> solution, IMHO, than But that is a much better solution, IMHO, than
>> creating long long krb.realms files because you want 20 million
>> subdomains to look like they are all in the same administrative
>> domain.
There are better solutions than this. One is to improve the
krb.realms semantics so that you can have one kerberos realm for
several domains. As you said yourself:
>> My point is that just because it doesn't work in your particular
>> instance doesn't mean that it isn't a viable way to doing it. It just
>> means that it isn't _YOUR_ way of doing it.
Mapping multiple domains mapping into a single realm is a viable way
of doing things. It just isn't yours.
The right solution is to push this information into the DNS where it
belongs. Then, we wouldn't have the problem of constructing and
distributing these static files to each host. Unfortunately, this is
also the most difficult solution.
Marc
