Bug 13476 - Modifying attributes can sometimes fail after cloning Windows 2012R2 DB
Summary: Modifying attributes can sometimes fail after cloning Windows 2012R2 DB
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.8.1
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
Depends on:
Reported: 2018-06-18 22:03 UTC by Tim Beale
Modified: 2018-11-13 08:46 UTC (History)
1 user (show)

See Also:

More debug of the object/attributes in question (8.02 KB, text/plain)
2018-06-18 22:03 UTC, Tim Beale
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Beale 2018-06-18 22:03:24 UTC
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.

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= -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
delete: msDS-MembersOfResourcePropertyList
msDS-MembersOfResourcePropertyList: <GUID=2753f709-f6ad-419d-9278-5e02e5c46c1d
 >;CN=ProtectedHealthInformation_MS,CN=Resource Properties,CN=Claims Configura
delete: msDS-MembersOfResourcePropertyList
msDS-MembersOfResourcePropertyList: <GUID=cdd76a78-de8f-4bf9-8e16-d59bdaaac023
 >;CN=RequiredClearance_MS,CN=Resource Properties,CN=Claims Configuration,CN=S
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.
Comment 1 Garming Sam 2018-11-13 04:00:04 UTC
Upon further inspection, it appears that the Windows DC does not return these linked attributes as linked attributes in the DRS messages. This can be shown by observing no replication metadata being present when querying the object during reveal.
Comment 2 Garming Sam 2018-11-13 08:46:14 UTC
(In reply to Garming Sam from comment #1)

In order to provide a proper upgrade path, we need to check whether or not we can send these attributes correctly over DRS after we have cloned them (as long as we have never touched them).

For the case where we have already touched them, a dbcheck rule to spot (and possibly fix) such issues seems to be required. This at least seems rare though, to begin with. For the 2012 R2 objects, they are claims related, which we have yet to implement in Samba.