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
_______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol