[cifs-protocol] Status: SRX080811600226 ([MS-NRPC] 2.2.1.3.12 Trust Account Details) superceded by SRX081013600536: [MS-NRPC] operation backing store linkages

Bill Wesse billwe at microsoft.com
Mon Oct 13 17:32:01 GMT 2008


Good morning Andrew. Since the original comments and questions you raised in SRX080811600226 about backup store linkages did not result in any material updates to the documents, I have created SRX081013600536 for continuance (and have closed SRX080811600226).

I am currently beginning a study of the MS-NRPC operation parameters, in order to compile a cross reference list, which I will submit to development as a well-annotated table, with back references to the operations sections. I am not sure at this time which of the columns should be the independent column (parameter or AD attribute). I would appreciate your input on this point, as you undoubtedly have a better insight than I into document usage.

Sorry it took me this long to get to this point.

======================================================================
> ========
> Question:
>
> The MS-NRPC document does not specify the linkage to the backing store
> for any of it's operations.
>
> For example, the NetServerAuthenticate3 query talks only about client
> computer accounts, but in 2.2.1.3.12 NETLOGON_SECURE_CHANNEL_TYPE,
> interdomain trust accounts are described.
>
> ======================================================================
> ========
> Response:
>
> Some of this data is already described in the document. Section 3.1.1.
> Abstract Data Model has entry for SharedSecret along with description
> of where the data is stored.

Only as an obscure 'microsoft behaviour note'.  This is not a minor detail of protocol behaviour, and deserves to be referenced in a major table matching protocol elements with their underlying backing store.

This table is what I want to see across all the protocols - as the double-mapping between protocol structure elements, abstract data modals and the occasional Microsoft behaviour notes detailing the backing store is a big problem.

Similarly, because it is do dispersed, it is not possible for you to show completeness in the mapping either.

> Computer accounts are stored in AD under the CN=Computers and trusts
> are stored in Trusted Domain Objects described in section 7.1.6.2 of
> [MS-ADTS].
>
> Please refer to our response (currently incomplete) concerning trust
> backing store information against the other case we are working on for
> you: SRX080731600024 [MS-ADTS] 7.1.6 Relationship between trusted
> domain objects
>
> ======================================================================
> ========
> Question:
>
> It makes sense that these both refer to computer and domain trust
> accounts found under cn=users, but this is not specified, nor are the
> attributes used specified.
>
> Similarly, the NetrSetPassword2 call sets a trust account password,
> but the operation of this call - what LDAP/DRS visible attribute it
> changes - are not specified.
>
> ======================================================================
> ========
> Response:
>
> This data is already described in the document. Section 3.1.1.
> Abstract Data Model has entry for SharedSecret along with description
> of where the data is stored.

Except changing a password does far more than simply change the value of unicodePwd.  This is the problem with the proxy via the abstract data modal - it misses details.

> ======================================================================
> ========
> Question:
>
> Please start with these, but to also note that, the 3.5.4.5.2
> NetrDatabaseSync{,2} calls need the same level of specification.
>
> These are just examples - like in my request regarding LSA, can you
> please clarify for the whole document which protocol buffers line up
> with which objects and attributes in the underlying database.
>
> ======================================================================
> ========
> Response:
>
> Since this is RPC based protocol, there are no buffers to be
> described. The only exception is the Netlogon SSP documentation, but
> those are covered by the above two responses.

Please could you re-read and re-answer the question in a more broad light, taking buffers as a synonym for perhaps RPC protocol structure elements?  Thanks



Regards,
Bill Wesse
MCSE, MCTS / Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  +1(980) 776-8200
CELL: +1(704) 661-5438
FAX:  +1(704) 665-9606

-------------- next part --------------
HTML attachment scrubbed and removed


More information about the cifs-protocol mailing list