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

[Garming Sam]

Hi Edgar,

As far as I know, the DRS API is the authoritative way to add this
particular record. Windows should be using this same procedure during
its joins. It didn't seem like there's any detail about the order of
DRSAddEntry having any implications (and even against LDAP, attributes
shouldn't have any implicit ordering). If there is some additional
semantic in this procedure, it does seem to belong here.

Cheers,

Garming

On 26/07/19 11:34 AM, Tim Beale via cifs-protocol wrote:
> Hi Edgar,
>
> I don't think I can add a nTDSDSA object over LDAP. I get:
> LDAP error 53 LDAP_UNWILLING_TO_PERFORM -  <000020A6: SvcErr:
> DSID-0305051B, problem 5003 (WILL_NOT_PERFORM)
>
> I think there might be a LDAP_SERVER_RODC_DCPROMO_OID control to
> override this, but I couldn't figure out how to make that work.
>
> I'm using a 2012 R2 Server.
>
> Let me know if there's anything else you want me to try.
>
> Thanks,
> Tim
>
> On 26/07/19 9:03 AM, Edgar Olougouna wrote:
>> Sorry, I misread this at the beginning. It's DRS API. Is it something you can reproduce with LDAP? 
>> I am assuming there must a proper logic on how to create a nTDSDSA object, independently of the interface.
>>
>> Thanks,
>> Edgar
>>
>> -----Original Message-----
>> From: Edgar Olougouna 
>> Sent: Wednesday, July 24, 2019 9:57 AM
>> To: Tim Beale <timbeale at catalyst.net.nz>
>> Cc: cifs-protocol at lists.samba.org; support <support at mail.support.microsoft.com>
>> Subject: RE: [REG:119072421000317] MS-DRSR drsuapi IDL_DRSAddEntry AttrBlock order for nTDSDSA object?
>>
>> 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'
>>
>>
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at lists.samba.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol