[3943] in Kerberos
Re: getting all those initial principals
daemon@ATHENA.MIT.EDU (Shawn Mamros)
Wed Sep 28 10:04:17 1994
Date: Wed, 28 Sep 94 09:55:04 EDT
To: hobbit@elf.com
Cc: kerberos@MIT.EDU
From: mamros@ftp.com (Shawn Mamros)
Reply-To: mamros@ftp.com
hobbit@elf.com (*Hobbit*) writes:
>Maybe I'm missing something really basic here, but is there a list of the
>principals one needs to create just to get a kerberos environment started?
>Creation gives me K/M and krbtgt and such, but then one needs kadmin.host
>[or kadmin/host in v5 lingo], me.admin to talk to it, telnet.godknowswhat...
>So far I have to grub through the sources to *maybe* figure out what each
>client and server needs, but this takes more of my time than should be
>necessary.
I don't think you're missing anything... It's hard to come up with any
definitive list of what principals to create, because it really depends
on what "Kerberized" applications you plan on running in your environment.
After all, Kerberos by itself is pretty much useless unless you have
applications or system software that actually use it. And it's the
applications that determine what principals are needed.
That being said, I'll try to cover a few of the ones you mention above.
V4 kadmin/kpasswd require a principal named changepw.kerberos for the
kadmind server, though with most modern V4 kadmind implementations you
don't need to add it to the srvtab file, since kadmind reads the key right
from the KDC database. If you're using a "straight" V4 server created
by the V4 kdb_init, this principal should be created automatically.
With a V5 server containing V4 backward compatibility, though, you have
to manually add it with kdb5_edit. For those who plan on administering
the database with kadmin, you need to create a username.admin principal
and add it to the appropriate ACL files for the kadmind.
For V5 kadmind, you need kadmin/YOUR.REALM.NAME as the server principal
and however many username/admin principals as you have administrators as
the clients. None of these are created automatically.
For a telnetd which supports the authentication option and Kerberos V4
as an authentication mechanism, rcmd.hostname is the server principal,
which does have to be in place in the srvtab file on every host where
incoming authenticated telnets are to be supported. (Interesting to note
that, to date, this is the *only* "Kerberized" application which is
"officially" codified in any way - it's in RFC 1411, which relies on the
generic Telnet Authentication option in RFC 1416. There are a few
others in Internet Draft stage, but those are rather volatile - the draft
for telnet authentication using V5, for example, has been *removed* from
the InterNIC repository of drafts! Guess it expired, or something...)
For V4 telnet client users, it's usually easiest to have a principal name
corresponding to their username, with no instance, although many telnetds
support the use of the ~/.klogin file for "alternate" principal names or
proxies if desired.
The "Kerberized" versions of the BSD "r-commands" (rlogin, rsh, rcp)
using V4 require the same set of principals as does telnet with V4.
For V5, the server side requires host/full.canonical.hostname (where
"host" is literally the word "host"), which has to go into the v5srvtab
file. V5 user principals remain the same.
As for other applications - well, it would be really nice if application
writers were to write documentation outlining prerequisites for their
software to run. Maybe someday they will...
-Shawn Mamros
E-mail to: mamros@ftp.com
