A proposal for how to set msDS-KeyVersionNumber

[Matthieu Patou]

"Andrew Bartlett" <abartlet at samba.org> wrote:

>On Tue, 2010-06-08 at 19:36 +0400, Matthieu Patou wrote:
>> Hi metze
>> > Am 07.06.2010 13:13, schrieb Andrew Bartlett:
>> >    
>> >> Attached is a proposal for how to set msDS-KeyVersionNumber
>> >>
>> >> The idea is that if the knvo is incorrect in an upgraded DB, which may
>> >> cause trouble for unix clients joined to a Samba domain (but not Samba3,
>> >> or windows), that we want to manually set the knvo.
>> >>
>> >> If this is too intrusive, then I suggest we just omit 'fixing' this, as
>> >> only a very small subset of our clients actually care about this value.
>> >>
>> >> (I've have no complaints since I changed how we calculate this value 3
>> >> months ago).
>> >>
>> >> (untested, intended to be used with a future upgradeprovision)
>> >>
>> >> Any comments?
>> >>      
>> > I think we shouldn't put such logic into the modules,
>> > the upgrade logic should be in the upgradeprovision script,
>> >    
>> > which should just rebuild the replPropertyMetaData attribute completely,
>> > and use a control to set it from above the repl_meta_data module.
>> >    
>> I'm not sure I understand the "which should just ..."
>> Because in my trails I've been able to wind the version field by 
>> changing the password of a given user but as I explained already in 
>> another email I am facing a problem when the delta between the version 
>> field and the old stored msds-keyversionnumber is 1. Also some find the 
>> idea to polute the password history not too great.
>> 
>> Can you detail how you envision the things with 1 or 2 example of synopsis ?
>> Matthieu.
>
>Metze is proposing that as replPropertyMetaData can be read and decoded,
>that instead of setting just the version in the repl_meta_data module,
>we read, decode and modify the replPropertyMetaData attribute, and then
>set it, including the new version on unicodePwd manually (using relax or
>similar to allow it to be set). 
>
>This avoids having rarely used, special case hacks in the core modules. 
>
>Otherwise, I simply don't see the need to correct the kvno as a big
>issue.  Samba3 and Windows clients don't use it, and I've heard no
>complaints that I can pin down to this error actually causing real-life
>pain.  The 'fix', if required at all, is to rejoin the affected clients,
>which isn't that bad a workaround.

Could it have an impact on signed end updates, in our current setup with bind ?
What about keytab generated by s3 or Windows, do they just have to be regenerated ?
 
Matthieu Patou
Samba team