[7773] in Kerberos
Re: Mundane kerberos question: srvtab management
daemon@ATHENA.MIT.EDU (Sam Hartman)
Wed Aug 14 21:07:31 1996
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: kerberos@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 14 Aug 1996 20:26:47 -0400
In-Reply-To: Ken Hornstein's message of Wed, 14 Aug 1996 01:34:02 -0400
>>>>> "Ken" == Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:
Ken> Now that we are increasing the number of hosts that are in
Ken> our Kerberos realm, one thought comes to mind: the current
Ken> method for managing srvtabs really bites.
Ken> Specifically, the thought of doing "ark host/foo", "xst foo
Ken> host", etc etc, a billion times is giving me screaming
Ken> nightmares.
Well, the next release of Kerberos will help with this some.
It will include the OV admin system, which has a kadmin client that
can easily add a key to the srvtab and to the database. This client
can be run from the remote host.
Ken> I am wondering what larger sites do w.r.t. srvtab management.
Ken> Are there any custom scripts that people use? Do people
Ken> actually change the keys in the srvtabs, or do they leave
Ken> them at the initial value?
I don't change things if I got the srvtab securely, but if I
didn't, then I do a ksrvutil change. (That's Kerberos V4, and there
currently isn't a good way of doing that until the next beta comes
out.)
At MIT, there are two different mechanisms used to distribute
srvtabs. If an interesting machine is getting a new srvtab, someone
from operations logs in at the console, and runs the srvtab generation
program. The program adds the principal to the database and creates
a srvtab. If it's inconvenient to get to the machine, someone in
operations places a copy of the srvtab on a local disk and makes it
readable by someone near the machine. This person logs into the
console and uses encrypted rcp to get the srvtab.
However, for machines in student dorm rooms, machines in
departments, etc, this procedure isn't really practical. Then,
someone in operations creates the srvtab, copies it into an AFS
directory readable by the owner of the machine, and sends mail. The
machine owner is expected to copy the srvtab and run ksrvutil change.
I have seen the second procedure used for servers when finding
a convenient ops person proved difficult. In other words, it's not
unheard of for a server key to travel once in cleartext to/from AFS.
I would be shocked to find this was the case for one of the really
important keys such as rcmd.kerberos or afs.ATHENA.MIT.EDU.
I know of one company that has an automatic process to
generate srvtabs during the installation process for a machine. It
may require a minimal bit of human interaction to approve the key for
addition to the database. I don't believe this code is publically
available.
Ken> --Ken
