[2144] in Kerberos
Re: New User Accounts
daemon@ATHENA.MIT.EDU (Alan Crosswell)
Wed Sep 2 13:51:28 1992
Date: Wed, 2 Sep 1992 16:20:20 GMT
From: alan@curta.cc.columbia.edu (Alan Crosswell)
To: kerberos@shelby.Stanford.EDU
In article <9209020104.AA25528@windsail.nersc.gov> ramus@nersc.gov (Joe
Ramus) writes:
>
> I do not see a good way to handle new user accounts in MIT Kerberos 4.
>
> On some of our systems now, we have the concept of an expired password.
> When we add a new user, the assigned password is expired and can only
> be used to get a new password. We then use some off-line method to
inform
> the new user of the assigned password. The user must then get a new
> password which is known only to that user.
>
> Kerberos 4 has the concept of an expiration date for a principal.
> When that date is reached, the principal is no longer able to get a
> ticket and cannot change the password.
>
> How do other sites manage new accounts and assigned passwords?
>
> Joe Ramus NERSC Livermore (510) 423-8917 ramus@nersc.gov
We preload our KDC with potential user's entries with an instance
ID of "foobar" and a pre-assigned password (which for us is a not
so-well known secret but good enough given the headache of administering
15,000 new accounts each September). For new user's we have a special
program which they run and give their pre-assigned password to. If
they succeed in authenticating with it, then this program (which
has a srvtab instance of frobitz.admin and appears in the admin_acl.add
file ONLY) then does a kadm_ank to add the user with a null instance
and a good password that the program enforces.
Our nightly kerberos log audit script then generates a form letter
for these people which is snail-mailed to them the next day as a
confirmation that it was really them who did it. Not perfect, but
does the job for us.
MIT Athena's Moira Userreg server is pretty much the same thing.
/a
