[7765] in Kerberos
Re: Mundane kerberos question: srvtab management
daemon@ATHENA.MIT.EDU (Scott Dawson)
Wed Aug 14 10:20:11 1996
In-Reply-To: Ken Hornstein's message of Wed, 14 Aug 1996 01:34:02 -0400
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: sdawson@engin.umich.edu, kerberos@MIT.EDU
Date: Wed, 14 Aug 1996 10:02:53 -0400
From: Scott Dawson <sdawson@eecs.umich.edu>
This is pretty long, sorry. I think some of it might help though.
I did some work several years ago at Computer Aided Engineering
Network at the University of Michigan. At that time, we had hundreds
of machines that at least had rcmd.machinename, and needed a way to
keep track of what services were provided by machines, and to
distribute srvtabs to these machines.
Most machines only had rcmd.machinename, but some had other services
as well.
We used the AFS kaserver for the kerberos server. In AFS, as admin,
you could set keys to anything you want, and they had a method of
asking the server for random keys. In AFS, you couldn't extract
srvtabs without going into some weird mode where there was no
protection, so instead, you simply set keys to something you knew
(that was random), and remembered (by writing them in a srvtab file)
what they were set to. I think kerberos servers let you extract
srvtabs if you're admin, so instead of getting random keys and setting
service keys to them and remembering, you can just do 'ark' or 'crk',
and 'xst'. Of course, you want to do these from a program, and not
from the database user interface. Maybe you can use perl or something
to trick the database interface into thinking it's talking to a real
user by using a tty/pty pair or something.
I wrote a program, which given a srvtab and a list of adds/deletes,
would create new entries and add them to the srvtab, delete other
entries, and optionally, could change keys of everything in the
srvtab. It authenticated as admin (on a secure machine), and obtained
an encrypted connection in order to do the adds/deletes/key changes.
For key changes, the program generated a random key (by asking the
kaserver for one over the encrypted admin connection), and then set
the service key to that. This way, there's never any real extraction
from the database. Again, if the kerberos server supports extracts,
then you could just add or change with random keys, and then extract.
At CAEN, we used an oracle database to keep track of things like
machine type (lab machines, faculty machines, etc.), IP address, etc.
So we simply created another table called the kerberos table and added
in all service entries for each machine. Of course, oracle could be
replaced by dbm or something else. We just used it because we used it
for other stuff. Mainly, what you need is a way to store what
services each machine needs, and a way to recall that. When I started
doing the work, we just used the file system, with a directory for
each machine's srvtabs and list of services. Later, there was a push
for oracle everything, so I moved the data about the services into
oracle. Of course, none of the keys or actual srvtabs were in oracle.
In order to update the services for a machine, you simply ran a
database client that adds/removes the services from the databases.
This thing was command line driven, so if you had a batch of new
machines, you simply did a:
foreach i (`cat machinelist`)
database_command -add rcmd.$i -add otherstandardservices.$i
end
Each night, all machines with srvtabs connected up to the srvtab
server using an authenticated, encrypted (under rcmd.machine)
connection, and requested a new srvtab. This caused a check of oracle
to get any changes to the srvtab. The srvtab server knew what
services already existed, because it had a copy of the srvtab for each
machine. It just needed to reconcile this with what Oracle said the
machine needed. The server ran the program which adds/deletes
services from the copy of the machine's srvtab in order to do this.
Then, the srvtab was sent to the machine over the encrypted
connection. The keys in the srvtab were not changed nightly, because
we found that it caused everyone's tickets for rcmd.whatever to go bad
(some people had long lifetimes because AFS lets you). Instead,
machines only requested srvtabs with new keys on reboot.
As far as getting the initial srvtab down to the machine, one way to
use it is to write a client that authenticates as a specific srvtab
user. This user is trusted to get srvtabs. Someone simply goes to
the machine, runs the client, types the password for the srvtab user,
and the srvtab can be sent to the machine over an encrypted
connection. The main problem is finding people who don't mind walking
out to machines in the field, and that you can trust with the srvtab
passwd. If that's you, then it's no problem. Also, it is definitely
easier than a floppy. At the time, we were lame and just copied them
down in the clear. Other ideas include diffie-hellman or something to
encrypt them. You don't get authentication out of it, but you could
use some lame r-command style auth or something. It'd still probably
be better than rcp or ftp since it'd be encrypted.
The main thing that would be different in your case is the program
which makes changes to copies of srvtabs. Since you're using the
kerberos database, you would probably need to hack up a client that
lets you use command line options to do 'ark', 'crk', and 'xst' type
stuff. You would just call this instead of calling my program that
talked to the AFS kaserver. The main idea is just to keep track
somewhere of what each machine needs in the srvtab, and also what it
currently has. Then, you automate the generation/distribution so that
all you have to do to change a srvtab is to change the "needs" part,
and have something else do the rest of the work.
Another thing that I did was to write a simple program that simply ran
the srvtab getting script. This program was run out of inetd on a
port called 'srvnotify'. The program only ran the srvtab getting
script if the connection was from the srvtab server. Basically, this
allowed us to still use a client pull model for getting srvtabs, but
to signal to a machine that it should do a pull and get a new srvtab.
From our srvtab server, if you had to change a machine's srvtabs
immediately, you simply did:
database_command -add newservice.machine -delete oldservice.machine
telnet machine srvnotify
-Scott
