[OpenAFS] renaming principals (Was: One of my users has married - what to do? )

[Christopher D. Clausen]

Ken Hornstein <kenh@cmf.nrl.navy.mil> 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