A proposal for how to set msDS-KeyVersionNumber

[Andrew Bartlett]

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. 

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/20100609/b32a371f/attachment.pgp>