[cifs-protocol] MS-DRSR drsuapi IDL_DRSAddEntry AttrBlock order for nTDSDSA object?

[Tim Beale]

Hi,

We're hitting a strange problem when using the MS-DRSR drsuapi
IDL_DRSAddEntry API to create a nTDSDSA object on a Windows AD DC (2012
server, running 2008R2 functional level). We're using the
DRS_MSG_ADDENTRYREQ_V2 message.

The problem seems to be related to the order of the attributes in the
AttrBlock. Specifically, HasMasterNCs and msDS-HasMasterNCs. If the
HasMasterNCs attribute occurs in the AttrBlock before msDS-HasMasterNCs,
then the RPC throws an ERROR_DS_NO_CROSSREF_FOR_NC error. But if the
same attributes are used in a different order (msDS-HasMasterNCs before
HasMasterNCs), then the RPC succeeds. There may be something else I'm
missing here, so I've included the attribute order from a good/working
and bad/failed case further below.

It's easy enough for us to fix the AttrBlock order. I'm just trying to
understand what the requirement here actually is. I may have missed
something, but I couldn't see any documented requirement in MS-DRSR
regarding the attribute order (i.e. section 4.1.1.3 'Server Behavior of
the IDL_DRSAddEntry Method', or in the MS-ADTS sections 6.1.1.2.1.1 or
6.1.1.2.2.1.2.1.1 that are referenced).

The only reference to ERROR_DS_NO_CROSSREF_FOR_NC I could find in
MS-DRSR was for IDL_DRSRemoveDsDomain.

Could you please clarify if there are any protocol requirements on the
order of the attributes in AttrBlock for the MS-DRSR drsuapi
IDL_DRSAddEntry API?

Thanks,
Tim

Attribute order in good/working case:
'dn',
'objectclass',
'systemFlags',
'dMDLocation',
'msDS-Behavior-Version',
'msDS-HasDomainNCs',
'objectCategory',
'msDS-HasMasterNCs',
'HasMasterNCs',
'options',
'invocationId',

Attribute order in bad/failed case:
'dn',
'objectclass',
'systemFlags',
'dMDLocation',
'msDS-Behavior-Version',
'msDS-HasDomainNCs',
'objectCategory',
'HasMasterNCs',
'msDS-HasMasterNCs',
'options',
'invocationId'