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-kerberos-and-samba >>> >>> (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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature