Investigate if it is possible to register an action after a successful remote LDAP update so, in case of a local DB failure happens, the remote LDAP modification could be rolled back.
Possible problems: This was brought to the table in the change password flow. If there are strict password policies on the LDAP server, such as users can't use recent past passwords again, it might be impossible to rollback the last change because the LDAP server will mistake it with an attempt to reuse an old password.
We might need to turn this whole "distributed transaction simulation" upside down in order to implement it properly:
- Get the current user password hash
- Modify the user password locally
- If the modification succeeds proceed to update LDAP server
- If the update of the LDAP server fails at this point we can restore the hash locally that we saved at the first point
We would probably need to have methods that work on hashes directly and do not enforce policies of any kind.