[2204] in Kerberos
Re: Setting up a slave server under Kerb V4
daemon@ATHENA.MIT.EDU (Icarus Sparry)
Wed Sep 16 05:55:23 1992
Date: 16 Sep 92 09:16:58 GMT
From: ccsis@sunlab1.bath.ac.uk (Icarus Sparry)
To: kerberos@shelby.Stanford.EDU
In article <1992Sep16.015100.10859@ee.gatech.edu> flur@asia.eecom.gatech.edu (Peter W. Flur) writes:
>Can someone give me pointers as to what needs to be done in order to do
>the following things:
>1
>1) Translate an existing passwor database (straight Unix passwd file) into
>a kerberos principal so that we can put the passwords straight into the
>kdc without having to distribute new passwords.
Can't be done! At least in a sensible time scale, unless you know more
about DES than most people. Unix does not know what your password is,
only what an encrypted version of it looks like. When you type in your
password it encrypts it in the same way, and compares the result.
Kerberos needs to know what the password is, so it can encrypt things
and send them to you for de-cryption.
However, the folks at Imperial College London (England) had a modified
version of login, which we used to ease the transition. It would ask
you for your password, and attempt to use that to get you a
ticket-granting-ticket. If it failed to do so, then it would see if
your password encrypted to the value held in the local /etc/passwd
file. If so it would request Kerberos to change your password to the
one you had just given it. Otherwise it would tell you that you had
given it an invalid password.
So all we had to do was to run this version of login for a couple of
months, and all our frequent users were entered into the Kerberos
database.
>3) How does one handle something like the operator account which does
>incremental backups across the network in the middle of the night in
>unattended mode? There is no one to respond to a password prompt.
One way is to use 'ksrvtgt' to get a ticket, using a password stored
in a file. Of course this means that you have to trust your filesystem.
>4) What is the "standard mode" for installing krb4 with respect to the
>rlogin.ucb, rsh.ucb, etc.? By this, I mean to most people remove the ucb
>versions and require a kerberized session? Do you turn off the rlogind,
>rshd, etc. ports? Do you modify the krb logins not to even run the ucb
>versions upon failure?
We keep the rlogin.ucb etc programs, as we may wish to talk to hosts
outside our control. We remove the rlogind, rshd etc ports, as we want
the security that Kerberos gives us. We continue to run telnetd, to
provide a way in from hosts which we do not control. If we didn't have
to live in the real world, I would disable that as well, as it means
passwords are being passed in clear across the network.
