Resync of msDs-KeyVersionNumber
mat at samba.org
Sun Jun 6 22:52:40 MDT 2010
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
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 ?
Samba Team http://samba.org
More information about the samba-technical