A proposal for how to set msDS-KeyVersionNumber
mat at samba.org
Tue Jun 8 23:32:13 MDT 2010
"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 ?
>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 ?
More information about the samba-technical