[3900] in Kerberos

home help back first fref pref prev next nref lref last post

Re: hierarchical realms

daemon@ATHENA.MIT.EDU (Paul Pomes)
Thu Sep 22 16:44:08 1994

To: kerberos@MIT.EDU
Date: 22 Sep 1994 16:44:04 GMT
From: p-pomes@mirage.cso.uiuc.edu (Paul Pomes)
Reply-To: P-Pomes@uiuc.edu

warlord@MIT.EDU (Derek Atkins) writes:

>I think the point was that administrative domains should require their
>own kerberos realms, just for naming purposes if nothing else.  What
>is the purpose of creating subdomains?  Normally it is because there
>is an administrative difference between the domains.  For example, the
>lcs.mit.edu domain is administratively different than Athena (which
>runs the mit.edu namespace).  Therefore they have different kerberos
>realms.

It delegates the problem of managing the namespace to the responsible
departments.  At UIUC, about 10 departments manage their own DNS
servers.  The other 190 rely on the central services organization
to do so.  Mixing and matching KDC servers and realms would be an even
larger administrative problem.

The UIUC.EDU realm was set up to provide a common authentication 
mechanism for central campus services such as registration and access
to our central service hosts.  Other departments are free to run their
own realms, but we don't encourage it.  

>If you subdivide a namespace just for the sake of subdividing the
>namespace, you are doing yourself a disservice.  First, you have this
>type of problem.  Second, you have to make sure that all your hosts
>are using different names.  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?

There's a name conflict only under V4.  V5 uses FQDNs.  It's simply
impossible for us to have a flat namespace.  At last count there were
21,000+ hosts under the *.uiuc.edu domain (on a single class B!).

>If you are going to subdomain, then you should have different
>administrative control, and different administrative control means you
>should have different kerberos realms/servers.  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
>creating long long krb.realms files because you want 20 million
>subdomains to look like they are all in the same administrative
>domain.

For some things people want to do, they do exist in two different
realms.  There is no necessity to tie DNS realms to an authentication
realm since they often serve different purposes.

/pbp
--
Hard work is damn near as overrated as monogamy.	--Huey P. Long

home help back first fref pref prev next nref lref last post