Ken Hornstein <[EMAIL PROTECTED]> wrote: >> Password history is a moot point for us. Should we care >> about that at some point, we'll worry about it then. > > So ... why DO you implement rename_principal, anyway? I had looked at > doing that a bunch of years ago, but I came to the conclusion that > it was basically equivalent to a delete/add, and since I'm lazy I > figured "why bother?". > > (To everyone else out there: does doing a delete and an add not > suffice for you? If so, why not?)
The point would be to allow users who may not be able to physically come in to the help desk and reset a password be able to change their user id. (Or in some cases, have their user id forcably change by "powers that be." A rename would also be an atomic operation. Delete / Add isn't atomic b/c there is a point at which the user cannot authenticate b/c a password is not yet set (at least not one that is known to the user.) Ideally, a copy principal operation would be available so that users can temporarily have two accounts to make sure everything is working on their new account before the old one is deleted. (Renaming a principal doesn't change the authorization lists everywhere all at once.) Again, avoiding a period of time when the user cannot authenticate at all would be ideal. <<CDC _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
