[OpenAFS] renaming principals

[Christopher D. Clausen]

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

On forced id changes, yes.  UIUC forced a large number of users with a 
hyphen in their netid to change to one that did not have the hyphen. 
(Usually dropping the hyphen if that id was available.)  They also forcd 
netid changes where there were conflicts between the 3 campuses (UIC, 
UIS, UIUC.)

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

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

I can change PTS, ACLs, and Unix account for the systems I maintain at 
nearly the same time.  The user would be able to login to these systems 
and work using either the old or the new principal.  Persumably, this 
would be the case at just about every departmental lab.

Students often need to get things done after the normal 5pm closing time 
or just about every University office.  Not being able to use a lab for 
an entire evening because of a forced password change is a serious 
problem.  No lab access often means no homework gets done.  And 
generally you find out about the forced change AFTER it occurs and you 
can't access anything anymore.

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

The user would be able to try either their old account or their new one 
and get into the system.  And even if the systems aren't all changed at 
once, being able to login using the old principal or the new principal 
for a period of time would be ideal.

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

Oh, I understand.  But being forced to go to a specific location on 
campus during specific times (which just happen to be the exact same 
hours that I am busy) for a password reset is REALLY annoying.  Even if 
it only happens once in many years.

And its really bad when it happens on a Friday afternoon and you are 
locked out all weekend.

<<CDC