Creation of principal without password

Fariba fariba at usc.edu
Thu Aug 17 12:20:36 EDT 2006


Thank you and others for replying.  If we use the randkey option to 
create the principal and do not transfer it to the keytab (if you 
transfer it to the keytab, I assume anyone typing the username is 
authenticated, so it is nor secure), is there a way to set the real 
password? Using  k_chpass  requires the knowledge of the old password, 
which when it is random we do not know it . Unless we can set the 
password to known string (even null) for the users, I do not see an 
alternative. I think I am answering myself. Seems like you cannot use 
kerberos just to store the users and later add their passwords. Any 
thoughts?
Ken Raeburn wrote:
>
>
> On Aug 17, 2006, at 06:07, ronnie sahlberg wrote:
>> a principal witout its associated password would be pointless for
>> kerberos since that account would not be able to use tickets that by
>> definition are encrypted with a key based on said accounts password.
>
> Not at all... a keytab file could be generated to store the key 
> directly, without using a password.  In fact, in the MIT 
> implementation, this is the normal case for server principals.
>
> Theoretically, if you separated the "create principal" and "set 
> password" privileges into different groups of admins, you could create 
> a new account for a new hire, or an incoming group of students, or 
> whatever (assuming your local policy dictates how principal names are 
> formed, and doesn't give the users the option), with a random key, and 
> then let a less-privileged administrator set the password for the user 
> later.  Offhand I don't know of anyone who does it this way, but you 
> *could*...
>
> Ken




More information about the Kerberos mailing list