Tim Watts wrote:
On 29/05/12 17:42, Michael Ströder wrote:
Tim Watts wrote:
http://www.opinsys.fi/en/smbkrb5pwd-password-syncing-for-openldap-mit-kerber...
(Line wrap warning) - some nice person has already done the job for MIT Kerberos :->>>
The system described above is a bit fragile. Because if one of the systems fail the password might only be changed in LDAP or Kerberos.
True.
In this case, the correct scenario for my environment is to fail the password change completely if the backends are not all contactable.
So if the password change succeeded one system you would have to roll-back in case it fails on the second system. This can get tricky even if you have the old password at hand (e.g. because of pwdHistory).
One of the points of using kerberos is not to have cleartext (or decryptable) passwords lying around (the other being very secure methods of challenging the password), which you'd have to do to put the password change in a queue for delayed changing - and I cannot see[1] any other way to safely queue a Kerberos hash in a documented way - unlike an LDAP userPassword where you could possibly precompute a SSHA1 hash and queue that.
Well, you can first make the non-queueable password change and if that succeeds send the queueable password change. But I'd consider queueing a rather bad user experience which causes work in the first level support.
Ciao, Michael.