[2090] in Kerberos-V5-bugs
Canonical host names in a NIS/DNS network
daemon@ATHENA.MIT.EDU (David Slack)
Thu Jul 11 13:24:59 1996
Date: Thu, 11 Jul 1996 11:24:36 -0600
From: David Slack <slack@elendil.cc.utah.edu>
To: krb5-bugs@MIT.EDU
Reply-To: slack@cc.utah.edu
I am running a test kerberos project using Kerberos v5 beta 6.
So far, most everything has gone quite well. Our network consists of
mostly Suns running Solaris 2.5 (or rarely, 2.4) but also includes a
few Linux boxes, some PCs running DOS/WIN, and Macs. The Suns are
running NIS+.
The problem arises in deciding what the name of a machines
ticket should be. If we contact a machine from a host not on nis, the
canonical name is machine_name.cc.utah.edu. If we contact a machine
from a host within the nis network, the canonical name is simply
machine_name. This problem is complicated by the fact that a
significant number of our Suns running nis exist on multiple networks
and have multiple interfaces. A machine might be called any number of
different names depending on who is calling from where.
A few solutions have suggested themselves. One is to
completely ignore NIS and only query DNS to find the canonical name of
the host. This is not something we want to do, since it would require
that we completely change our networking environment to fit Kerberos,
where changing Kerberos a small amount would allow it to work within
our environment, as I will illustrate.
Aliases seem to be the best solution, since a machine would be
able to respond to a ticket under any of its known names. This could
be implemented in two ways. In one, the kdc would return the correct
canonicaly named ticket when asked for any of a machines aliases.
This would keep the kdc database and the v5srvtabs smaller.
Another approach would be to have a ticket for each machine
alias in the kerberos database. Although this is possible now, it
does not seem possible to extract a srvtab that includes references to
each of the machines alias tickets. I have tried concatenating
multiple srvtabs together, but the host only recognizes the first
instance.
I may work on the third approach with the source code I have.
I would rather not deal with the second myself, since it would require
a great deal of mucking around with the kerberos database. If I come
across anything else, I will let you know. Please let me know if you
have any solutions to the problem.
-- David Slack <slack@cc.utah.edu>
University of Utah Computer Center - Network Operations
