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

Bryan Burgin bburgin at microsoft.com
Wed Jul 24 05:56:23 UTC 2019


[dochelp to bcc]
[+support]

Hi Tim,

Thank you for your question.  We created SR 119072421000317 to track your issue.  An engineer will contact you soon.

Bryan

-----Original Message-----
From: Tim Beale <timbeale at catalyst.net.nz> 
Sent: Tuesday, July 23, 2019 3:31 PM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: MS-DRSR drsuapi IDL_DRSAddEntry AttrBlock order for nTDSDSA object?

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'



More information about the cifs-protocol mailing list