Simple bind will reveal the password in clear. I do not think we want to do this for the same reasons we do not want to store them on the client machine.Would it be useful to also intercept the password used when a simple or SASL/PLAIN bind requests succeed, and take the opportunity to generate the hashes so that we can avoid forcing password changes?I don't see why we should store them.
I did not say we should store them. I said we do not want to use simple bind.
Yes I agree. But we will have to provision certificate for this. We plan to provision certs for other things so I agree not a very big deal just acknowledging that yet more complexity. Can it be done in the PAM module we are planing to build or it has to be a separate one? Does not seem to make sense to have a separate one.It will force us to use SSL. It is currently turned off for performance reasons.SSL is configured in DS, we use it for replication, we do not use it in the default nss_ldap configuration, but nothing prevents us to use SSL for an eventual special bind done explicitly as a way to perform a password-change-on-good-auth operation. We would need a special pam module to do that though.
SASL will not give us the password in clear on the server side so we won't be able to generate the hashes.A plain text bind gives us (and I mean DS) the password in the clear, so all we need is a bind plugin that intercepts it, checks that the account is in "upgrade" mode, perform a password change operation to generate all the hashes, and put the user account in "upgraded" mode (eventually turning off plain text auth at the same time). Simo.
Yes.But for the bind to be successful some credential should be stored in the IPA's back end. It is the one that came from the previous DS in the form of UNIX hash of the password, right? We should delete it after we "upgrade". I think the presence of the hash and absence of kerberos hashes indicates that the account needs upgrade.
Dmitri