Hi Andrew, > The format of this backing store is determined (to a great degree) by > the way these attributes are visible in LDAP (as almost all changes via > the other protocols are visible over LDAP), and by the replicated data > stream a peer DC would provide/accept over DRSUAPI.
yep, thats true of many of them, especially the protocols we tend to deal with. > However, the Microsoft documents have been written so as to frustrate > the implementer at every turn. At no time in the main section of the > documents do they clearly link the wire elements to the elements in the > backend store. I think you have a valid point, but I don't think it is at all a deliberate attempt to frustrate us! It just comes from the approach of treating the protocols (to a large degree) in an isolated manner when writing the documents. Let's look at a specific example. In the [MS-LSAD].pdf document a lot of the protocol elements describe an 'account' and how it can be manipulated (created, removed etc). The [MS-SAMR].pdf also talks about what you can do with an 'account', as does [MS-NRPC].pdf. So how are these three 'account' concepts related? It turns out that the 'account' in LSA is quite separate from the 'account' in SAMR. Even though they both have a SID associated with them which you might think would uniquely identify the same object, they actually need to be handled separately. If an account in LSA has the same SID and name as an account in SAMR, and you delete the one in LSA then that has no effect on the one in SAMR. The same is not true between NRPC and SAMR. In the case of those two protocols the accounts and SIDs are the same and need to be associated with the same backend storage, and an implementor needs to know they are the same or the protocols just won't work. This is the type of linkage information that should be made clear by the abstract data model, but isn't, and the problem isn't isolated to just LSA, it seems to be a problem with lots of the fields in lots of the protocols. I think your suggestion that the documents should use the LDAP schema names for the objects where possible is a very good one. Many of the interconnected protocols are bound together by LDAP, and there are tools (such as mmc) that rely heavily on the exposure of these concepts directly in LDAP. So the LDAP schema provides a very natural way to connect these current disconnected protocols elements within a common framework. Cheers, Tridge _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol