Created attachment 14242 [details]
More debug of the object/attributes in question

I noticed a problem when taking a clone of a Windows 2012 DC - modifying multiple attributes in the same operation can fail on the resulting DB. I initially noticed this running dbcheck after a rename, however, the problem is unrelated to the rename work.

Cloning a Samba DC appeared to be OK. The problem seems that the attributes are stored in the DB in the wrong order - this may potentially be a Samba-Windows interop issue during the DRS. The attribute in question is also specific to the 2012 schema, although I'm not sure if that is relevant.

Reproduction:
1. Take a clone of a Windows 2012R2 DC (presumably this problem could occur for joins as well). E.g.

bin/samba-tool drs clone-dc-database blah --server=192.168.122.197 -UAdministrator%penguin12#  --targetdir=/tmp/clone

2. Check the msDS-MembersOfResourcePropertyList attributes for the 'Global Resource Property List' object. I'm not 100% certain, but it looks like the attributes might appear in the incorrect GUID order (you might want to double-check the MS AD specs to confirm the expected sort order). E.g.

bin/ldbsearch -H /tmp/clone/private/sam.ldb --cross-ncs '(CN=Global Resource Property List)' --extended-dn

3. Try to modify multiple attributes for the CN=Global Resource Property List object in one operation. Trying to delete the first 3 attributes seems to work for me. E.g.

sudo bin/ldbmodify -H /tmp/clone/private/sam.ldb 
dn: <GUID=03c21b08-a06f-4c22-9be4-7a19cd324e1c>;CN=Global Resource Property List,CN=Resource Property Lists,CN=Claims Configuration,CN=Services,CN=Configuration,DC=WINDOWS2012R2,DC=WIN,DC=TIM,DC=WGTN,DC=CAT-IT,DC=CO,DC=NZ
changetype: modify
delete: msDS-MembersOfResourcePropertyList
msDS-MembersOfResourcePropertyList: <GUID=78321038-e254-4050-b421-989c18601f09
 >;CN=PII_MS,CN=Resource Properties,CN=Claims Configuration,CN=Services,CN=Con
 figuration,DC=WINDOWS2012R2,DC=WIN,DC=TIM,DC=WGTN,DC=CAT-IT,DC=CO,DC=NZ
-
delete: msDS-MembersOfResourcePropertyList
msDS-MembersOfResourcePropertyList: <GUID=2753f709-f6ad-419d-9278-5e02e5c46c1d
 >;CN=ProtectedHealthInformation_MS,CN=Resource Properties,CN=Claims Configura
 tion,CN=Services,CN=Configuration,DC=WINDOWS2012R2,DC=WIN,DC=TIM,DC=WGTN,DC=C
 AT-IT,DC=CO,DC=NZ
-
delete: msDS-MembersOfResourcePropertyList
msDS-MembersOfResourcePropertyList: <GUID=cdd76a78-de8f-4bf9-8e16-d59bdaaac023
 >;CN=RequiredClearance_MS,CN=Resource Properties,CN=Claims Configuration,CN=S
 ervices,CN=Configuration,DC=WINDOWS2012R2,DC=WIN,DC=TIM,DC=WGTN,DC=CAT-IT,DC=
 CO,DC=NZ
-
ERR: (No such attribute) "Attribute msDS-MembersOfResourcePropertyList doesn't exist for target GUID cdd76a78-de8f-4bf9-8e16-d59bdaaac023" on DN CN=Global Resource Property List,CN=Resource Property Lists,CN=Claims Configuration,CN=Services,CN=Configuration,DC=WINDOWS2012R2,DC=WIN,DC=TIM,DC=WGTN,DC=CAT-IT,DC=CO,DC=NZ at block before line 19
Modify failed after processing 0 records

When the problem occurs, I get the above error complaining that it can't find one of the attributes. However, ldbsearch shows that the attribute exists. And doing the same modify operations one at a time works.

In the code the failure is the parsed_dn_find() lookup in replmd_modify_la_delete(). The lookup is doing a binary search, and although the attribute is present, the attributes don't appear to be in the correct order, so it doesn't find the attribute. We think the incorrect ordering means the binary search traverses the attributes in a somewhat unpredictable order. Presumably modifying a single attribute could also fail, if you picked the right attribute.

Tested against master HEAD 5d4f2294c9eeec31f9d0.