(PLEASE don't include kerberos-announce in the recipient list on queries. It's just more work for us to go delete the messages from the moderation queue.)
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
