[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Very quick pointer

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