attid fixes (Re: [SCM] Samba Shared Repository - branch master updated)

Andrew Bartlett abartlet at
Thu Mar 10 18:40:49 UTC 2016

On Thu, 2016-03-10 at 13:10 +0100, Stefan Metzmacher wrote:

> This explains a lot! Do we have dbcheck code to fix this?

Not to fix it - as you know we find the attid that isn't in the schema,
but I chickened out of fixing it, because we would have to guess
(intuit) which attribute it was meant to point to, which might actually
be an empty attribute and so not present. 

I was going to say we are saved by using msDS-IntID in the non-schema
partitions, but of course that has been its own disaster.  Given that
extra factor, I really don't know if we will hit this in the wild, and
would rather see a genuine customer/user situation with it before
embarking on a dbcheck fix.  I would first advise re-replication in any

> I'm also wondering if it really correct that the prefix map will
> differ in a pure Windows domain. Shouldn't the destination dc
> import the prefix map from the source dc when replicating schema
> changes?
> But the fact that [MS-DRSR] has a LocalAttidFromRemoteAttid()
> function,
> it might also be possible the prefixMap will be different on Windows
> too.
> Are you able to verify this?

I haven't yet, and in any case by now we have in-the-wild Samba domains
with differing prefixMap values.

It would depend on what order we saw the OIDs in, which is why this is
a flapping test.  The majority of custom schema users add only the sudo
schema, and that uses only one OID prefix, so is 'safe'.

That a whole new class of attributeID values for msDS-IntID was created
indicates to me that this was a problem for MS too. 

> For I created for
> this
> and this can be pushed with the bug url and my review.


Andrew Bartlett

Andrew Bartlett             
Authentication Developer, Samba Team
Samba Developer, Catalyst IT

More information about the samba-technical mailing list