>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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
