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

[Ken Hornstein]

>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."

Your criteria for a user changing their userid is less stringent
then a password reset?  I dealt with a site like that once, but I
always thought that if someone is changing their userid, they should
have to interface with us in a way that doesn't make a password
reset a big deal.

>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.)

I understand about the atomic operation ... but the only real conceivable
failure mode that I see is leaving the old account around (presumably
you would notice if the new account wasn't created).  We never found that
was a problem ... and in Iowa State's case I doubt it is, because they
use Moira.

And I think you're being rather optimistic about the user experiencing
a service outage.  Unless you're able to change their Unix account,
any ACLs, pts entry, etc etc, all at once, the user is going to have
some kind of outage.  You could shorten it, but I don't see how you're
going to make it zero without having everything using one mega database
backend (I'm not talking about Moira ... this would have to handle
every authorization request).

I'm just trying to put some perspective on things.  I understand that
large sites probably have relatively frequent renames ... but if you
don't, I don't think doing a delete/add is so bad.  Not that I think
having a rename ability inside of kadmind is a bad idea, but I wouldn't
bust my hump over it.

--Ken