[Freeipa-devel] Capturing passwords for migration at bind-time?

Dmitri Pal dpal at redhat.com
Thu Jun 26 16:15:39 UTC 2008


>>> 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?
>>>
>>>   
>>>       
>> 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.
>>     
>
> 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.

>>  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.
>
>   
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.

>> 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




More information about the Freeipa-devel mailing list