cole@CS.WISC.EDU (Bruce Cole) (09/08/89)
I would like to replace Unix authentication with Kerberos authentication
on the Unix machines in our department. Unfortunately, I have run into
some technical problems:
Our department has an existing user community of thousands of users. How
can I get all of these users added to the Kerberos master database? The Athena
Technical Plan mentions a hack whereby users set their passwords using a
public account. This does not seem practical for an existing user community
(with existing files to be compromised).
We sometimes run software in unattended modes which distribute files
to remote machines. How can I use kerberos to authenticate such file
distributions?
Can something like rkinit be written that does not require a user to
retype their password? It seems to me that possessing Kerberos credentials
to login to a remote host as some user should be sufficient to obtain a ticket
granting ticket for that user on the remote host.jis@ATHENA.MIT.EDU (Jeffrey I. Schiller) (09/10/89)
When we first started converting existing users here at MIT from Unix password authentication to Kerberos authentication we did so over a transition period. In this period we installed a hacked up version of the "passwd" command that would change your password in the local password file *and* register you with the kerberos database. A special server was run on the kerberos database server system that accepted requests on a privileged port (barf ech!). There were two interesting cases: 1) User changing his password for which no kerberos entry existed. 2) User changing his password for which a kerberos entry already existed. Case [2] was handled by getting tickets for the user using the "old password." The request sent to kerberos with the new password was of course encrypted. This use of the passwd program is secure (provided the old password isn't compromised). This is essentially the password changing program in use today. Case [1] was handled by the password program, upon failing to get tickets for the user in question, would get tickets for the user named "default.changepw." This user had a constant password hardcoded into the password changing program. Default.changepw had access (via the special hacked server) to add new people to the database, but could not change the password of an existing user. We made noise publicly asking people to change their passwords (even if they only changed it to the same string!) so that our database would get populated. At some point (more then a year) we cutover our environment to depend on Kerberos authentication. At that point people who didn't change their password were not able to login until they saw a system administrator and got their Kerberos password established. Note: People in this category still surface! -Jeff
billdo@IFS.UMICH.EDU (09/14/89)
Assuming you have access to the login (and xdm for you X window folk)
source, an alternative to what Jeff mentioned is to modify login instead.
Login would have to handle the two cases that Jeff mentioned:
1. Users logging in who are valid users but don't yet have a
Kerberos entry.
2. Users logging in who are both valid users and have a
Kerberos entry.
and of course, it must also correctly handle that other case,
3. Users logging in who are not valid users. Forcibly eject.
so you'd expect the code to read something like (this code assumes
that Kerberos will be replacing your current authentication method,
otherwise you'd always check the password by both methods...):
if Kerberos Entry doesn't already exist for foo
if current mechanism says invalid password
sorry. go away. exit.
else
add new user to Kerberos database with given password
(using Jeff's "default.changepw" principal)
if Kerberos says invalid password
sorry. go away. exit.
login, authenticating via Kerberos
The disadvantage is that you'd have to modify the login program
(a setuid root program at that). The advantage is that users would
automatically be converted over to the new system the next time they
logged in and from then on would be authenticated via Kerberos. No
mess, no fuss, no change in procedure. After doing this for a couple
of months or so, you could replace the "add new user" portion with
"sorry. see system administrator for Kerberos password".
Another problem of course is that someone could suck the hard-coded
"password" out of the login program and use it to add their own account.
Depending on what other protections exist, this may or may not be a
problem. You could put it in a file that was only readable by root,
but then again, that wouldn't stop to many users these days...
Bill Doster billdo@ifs.umich.edu
IFS Project (313) 763-0587
Univ. of Mich.