A proposal for how to set msDS-KeyVersionNumber

[Andrew Bartlett]

On Wed, 2010-06-09 at 09:32 +0400, Matthieu Patou wrote:
> 
> "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 ?

For the 'dns' account, we need to fix that anyway - it should not exist.
It would be best if, just as with the machine account, we reset the
password and recreated the keytab. 

> What about keytab generated by s3 or Windows, do they just have to be regenerated ?

Yes, if a keytab was generated, then it may have the wrong kvno.  It
would just need to be regenerated.  However, when I was examining the
kerberos code for s3compat, I could not find where the knvo was read,
when the machine account password was changed (perhaps it's in the
export code somewhere).

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/20100610/30368fd4/attachment.pgp>