Resync of msDs-KeyVersionNumber

[Andrew Bartlett]

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

What do you think?

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100607/ea3dec2c/attachment.pgp>