Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!ucsd!ucbvax!agate!shelby!IFS.UMICH.EDU!billdo
From: billdo@IFS.UMICH.EDU
Newsgroups: comp.protocols.kerberos
Subject: Re: Questions on Kerberos usage
Message-ID: <8909141642.AA05542@ATHENA.MIT.EDU>
Date: 14 Sep 89 16:38:59 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 50


    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.