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
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
