Password sync plugin, and questions about plugin criticality

[Russ Allbery]

Nicolas Williams <Nicolas.Williams at sun.com> writes:
> On Mon, Jun 26, 2006 at 09:15:08AM -0400, Ken Hornstein wrote:

>> I don't think I can; some people absolutely want external password sync
>> to happen before the password gets written locally; other people want
>> the exact opposite.

> Why?  Do they expect atomicity?

It's a question of best effort more than atomicity.  Yes, with distributed
password changes, you probably can't get full-blown commit/rollback
semantics.  However, in our case, there are some common failure modes that
we want to protect against.  If, for instance, AD is down entirely, we'd
rather fail the user's password changes rather than change them only in
MIT and then have to resync AD when it comes back up.

Our feeling on this is that it's highly unlikely for the local password
change on the MIT KDC that kadmind is running on to fail, but it's more
likely that something will fail about the remote password change over the
network.  Therefore, we want to try the remote one first, and only commit
the local one if the remote succeeded, which will catch 99% of our
failures by rejecting the change entirely.  The remaining 1% of the time
when the commit to local disk fails will just result in a discrepancy that
we'll have to deal with -- oh well, life isn't perfect.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>