[OpenAFS] One of my users has married - what to do?

[Marcus Watts]

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

When we had kaserver, it didn't support rename either -- we had special
logic that would do a "getkey" to fetch the old key -- and hence was
essentially doing a delete/add, except without bothering the user for a
password change.  For better or worse, we trained our users early not
to expect a password change when changing loginids.

With MIT k5, doing the equivalent would have been more work than fixing
rename_princ.  Only the stubs were left of rename_princ when we
switched, so we had to re-implement it.  The main work was adding
special salt handling, consisting of looking for salt of type
"special", "normal", or "norealm", and saving it as "special".  If
there's more than one salt type matching this, the rename fails.  In
our configuration of salt types, this cannot happen without special
contrivance.

Fortunately for us, we don't have iastate's WebCT problem, so not doing
the password reset is a real win.  We push cosign heavily, so we have
relative freedom from weird vendor web authentication logic.  Most of
our rename process can be automated, so can be highly reliable with
little chance of things going wrong.  Setting a new password involves
meatware and hence extra overhead when things do go wrong.

				-Marcus Watts