[5624] in Kerberos
Re: Importing accounts from passwd file?
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Aug 8 08:37:52 1995
To: brian@nothing.ucsd.edu (Brian Kantor)
Cc: kerberos@MIT.EDU
In-Reply-To: Your message of "Mon, 07 Aug 1995 20:53:43 PDT."
<199508080353.UAA07101@nothing.ucsd.edu>
Date: Tue, 08 Aug 1995 08:27:46 EDT
From: Sam Hartman <hartmans@MIT.EDU>
> Date: Mon, 7 Aug 1995 20:53:43 -0700
> From: brian@nothing.ucsd.edu (Brian Kantor)
> Message-Id: <199508080353.UAA07101@nothing.ucsd.edu>
> To: kerberos@MIT.EDU
> Subject: Re: Importing accounts from passwd file?
>
> The way we did this was to 'trojan-horse' the login program on our most
> popular host so that over a period of several months, it shoved most of
> the relevant people into the kerberos database. This was done by
> invoking the krb5_edit program during login. It was a crude hack but
> it did the job.
>
> No, I can't provide the source, because it's a hack to login.c, which
> is different on nearly every platform. Sorry.
> - Brian
If you're using Kerberos for security, this is a rather bad
idea in general. First, it means that your Kerberos database must
physically be located on one of your most insecure hosts. Secondly,
The point of Kerberos is to avoid having passwords travel clear-text
over the network. If I can sniff during the installation phase, who
cares if you use Kerberos later.
On the other hand, Kerberos makes a nice centralized password
database. If this is what you want it for, then the proposed solution
is an acceptable option. You could probably hack login.krb (which
will use /etc/passwd if Kerberos fails) if it will do the right thing
on your system.
After doing this, when you move your database to a secure
server, change the master key. In addition, change the key for
krbtgt.REALM-NAME and change any interesting (administrators, rcmd.*,
etc) keys that might be nice for a cracker to know.
--Sam
