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

[Edgar Olougouna]

Hello Tim,
Thank you for reaching out.
If you do have an extended error message with “ . . . LdapErr: DSID-xxxxxxxx …” please share that whole error string with me as it can help me narrow down what you are experiencing. You would see it in the LDAP error message.
One more thing, regarding the Windows OS version you are testing against, is it server 2012 or Server 2012 R2? 

Thanks,
Edgar


-----Original Message-----
From: Bryan Burgin <bburgin at microsoft.com> 
Sent: Wednesday, July 24, 2019 12:56 AM
To: Tim Beale <timbeale at catalyst.net.nz>
Cc: cifs-protocol at lists.samba.org; support <support at mail.support.microsoft.com>
Subject: [REG:119072421000317] MS-DRSR drsuapi IDL_DRSAddEntry AttrBlock order for nTDSDSA object?

[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'