[cifs-protocol] The Abstract Data Modal

[tridge at samba.org]

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