Not sure if this is still the case, but if it is, AuthManager will make it easy to handle this cleanly: all auth providers will be able handle, ignore or prevent a password change, and the local-password provider will simply ignore (but not prevent) when the local account does not exist. IIRC password resets will be implemented as a special kind of data change and the same principle will apply.

AuthManager doesn't really fix this, since TemporaryPasswordPrimaryAuthenticationProvider needs a local user so it can store the temporary password. We'd have to replace that with something CentralAuth-y (along with other changes) to make it be able to work, or change core to move the user_newpassword field out of the user table and into a table indexed by not-necessarily-existing usernames instead.

OTOH, for WMF wikis we have Meta in $wgCentralAuthAutoCreateWikis so https://meta.wikimedia.org/wiki/Special:PasswordReset should generally be usable.

Also, I note that the default error message for this situation has linked to [[Special:CentralAuth/username]] since August 2013 when T39219 was fixed (although it's currently broken, see https://gerrit.wikimedia.org/r/294732 for the fix), so it's just a matter of clicking the link to find a wiki where it will work.

Thanks for the reminder @Bugreporter, I didn't think of this but it's definitely a blocker for SUL3 (although for the MVP we can leave it on the local wiki).

We have gu_password_reset_key and gu_password_reset_expiration in globaluser (added way back in rECAU7ab0b090d77d: fiddle a bunch of stuff around to be more robust to global user renames in…) but nothing uses them, so we'll need to reimplement TemporaryPasswordPrimaryAuthenticationProvider in CentralAuth. (They don't match the core column names, user_newpassword and user_newpass_time, which is annoying, but true for a number of globaluser columns, and in general the CA names make more sense.)

The nicer approach, but probably too big to attempt in the middle of another project, would be to do T183420: Authentication data should not be available through the normal DB abstraction layer so core and CentralAuth can use the same authentication provider and just a different password access service.