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