s4-drs: cope with bogus empty attributes from w2k8-r2 (Re: [SCM] Samba Shared Repository - branch master updated)

Kamen Mazdrashki kamen.mazdrashki at postpath.com
Mon Nov 30 14:57:02 MST 2009

On Mon, Nov 30, 2009 at 23:42, Andrew Bartlett <abartlet at samba.org>wrote:
>On Mon, 2009-11-30 at 20:35 +0200, Kamen Mazdrashki wrote:
>>Could you please reviewed the small patch attached - this should
>>resolve the problem with strange-looking ATTIDs received from w2k8.
>>Unfortunately I couldn't think of a better test for this than
>>RPC-DSSYNC test - it works perfectly against w2k8 now.
>>I think next thing to be done is to implement w2k8 behavior in
>>Samba4 also.
>I have to say, I'm confused:  How does this change to the schema relate
>to the test?
Currently DSSYNC test fails on my box with:
  failure: DSSYNC.DC_FetchData [
torture/rpc/dssync.c:453: status was WERR_GENERAL_FAILURE, expected WERR_OK: dsdb_extended_replicated_objects_convert() failed!
It actually fails on dsdb_attribute_by_attributeID_id() as ATTID is not found
in schema cache.
According to what Metze has found, we should use ‘msDS-IntId’ in case it is set
or use dsdb_schema_pfm_make_attid() function.
In our case, ATTIDs are resolved using dsdb_schema cache – thus we just need
to have the proper ATTID in the cache.
I think functions dsdb_attribute_from_ldb() and dsdb_class_from_ldb() are exactly
where we should implement this logic – this way loading schema from Samba or WinDC
is consistent and should behave in the same way (almost).
>Also, why 0xFFFFFFFF rather than 0?  Is zero already special?
>Jut wondering,
According to the above mentioned document, values [0xFFFF0000.. 0xFFFFFFFF]
are reserved and should never appear on the wire.
Which implies that ‘msDS-IntId’ should never be equal to 0xFFFFFFFF (besides, 
Metze already used it as a special ATTID to mark ‘error ATTID’).
Kamen Mazdrashki
kamen.mazdrashki at postpath.com

More information about the samba-technical mailing list