Password sync plugin, and questions about plugin criticality

[Henry B. Hotz]

On Jun 26, 2006, at 4:13 AM, krbdev-request at mit.edu wrote:

> A password synch framework should just call all its plug-ins, in order
> or concurrently, who cares -- synchronization failures should be  
> logged,
> but that's it.

"Logged" means "user is notified, but the operation still succeeds",  
right?

I guess if we're polling desires, what I'd want is to make the change  
in Kerberos first (after QA), then attempt external sync.  If  
external sync fails notify user, but don't return a failure.  (The PW  
change ack msg seems to allow a message even if the operation  
succeeds, though I'm not sure how current clients react to it.)

This is just me, and I'm sure some other people don't want to change  
the Kerberos PW if the external sync fails.

I'm not concerned about "localization", but the names of the external  
PW stores used in failure notices would be local organization names.

Has anyone thought about the performance impacts of tying a password  
change to a slow, external interaction?  Make sense to fork() the  
daemon at that point?  Just asking.
------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu