Resync of msDs-KeyVersionNumber

[Matthieu Patou]

On 07/06/2010 03:24, Andrew Bartlett wrote:
> On Mon, 2010-06-07 at 00:23 +0400, Matthieu Patou wrote:
>    
>> Hello Stefan and Andrew,
>>
>> I've been doing some tests and writting some code for doing this.
>> So far It's quite ok (although I have to trick the password_hash module
>> to let it me set hash passwords while waiting for a control exposed to
>> ldb to appear), but I discovered this small problem: modifying the samdb
>> with the same hash didn't cause an update of the version.
>> So I have to set another password then the password the user/computer
>> has before.
>>
>> But doing so means that I'm not able to fix version where the delta
>> between the stored version of msDs-KeyVersionNumber and the version
>> field of the unicodePwd attribute in replPropertyMetaData is 1.
>>
>> Any suggestion, maybe the change old password control ?
>>      
> So, I see two possible situations:
>   - when the msDS-KeyVersionNumber we generate is higher with the new
> provision than the old
>    
We do not copy the replPropertyMetaData from the reference provision to 
the current provision.
So we can't have really this case right now. In the future it will 
happen because only the version field is updated in the replPropertyMetaData
and not anymore the msDS-KeyVersionNumber. But this case is not a real 
problem, we can just ignore it


>   - when the msDS-KeyVersionNumber we generate is lower with the new
> provision than the old
>
> We can't send the replMetaData version backwards - that's not legal
> (unless we have no replication peers).
I'm not sure it is possible also to modify directly the version field.

>    But we can wind it forwards, and
> we can do this for this specific object/attribute.  I suggest we don't
> try games with changing the password, but if we must 'fix' this, we do
> so by reading the replMetaData, adjusting the version, and writing it
> (or at least the version) again, either with the over-used relax, or a
> control for exactly this purpose.
>    
That's exacly what I tried and what I described in my email, that is to 
say we read with the new managedsait the "raw value" of the 
msDs-KeyVersionNumber, then we look at the version field for unicodePwd 
in replPropertyMetaData. At this moment we calculate the delta.
If the delta >1 we can achieve to resync the password, by modifiying 
delta-1 time the password with a random one and then at the reputing the 
unicodePwd as it was.
But the problem is that if delta=1 just reputing the same password 
didn't work for incrementing the field value.
Also Simo suggested on IRC to directly modify the version field of 
unicodePwd in replPropertyMetaData,  I'm really not pleased with this 
idea as
it will no be good and most probably broke replication as we do not 
increment dates and usn.

So I have 1 question 1 problem, the question is do we go with the 
password trick to update the keyversionnumber ?
And the problem is how can I force the incrementation of version 
unicodePwd when modifying a value by something equivalent ?

Matthieu.

-- 
Matthieu Patou
Samba Team        http://samba.org