[cifs-protocol] The Abstract Data Modal

[Andrew Bartlett]

On Sun, 2008-08-31 at 22:06 -0700, Ron Schnell wrote:
> The Technical Committee was formed to help enforce the Microsoft anti-trust Final Judgment entered by the
> US Courts in 2002 (see http://www.thetc.org).  The TC has been involved in reviewing and commenting on
> much of the recently posted technical documentation and is interested in hearing about your experiences using
> these documents for product development or enhancement, either by posting your feedback to this mailing list,
> or by contacting the TC on a strictly confidential basis by sending e-mail to docfeedback at thetc.org

The biggest issue I have with the documents is the poor choice of
abstract data modal, imposed on part (but not all) of the active
Directory protocols.

These protocols (LSA, SAMR, NETLOGON, DRSUAPI, LDAP-as-found-in-AD) are
interdependent - none can sensibly be deployed in the fashion required
for a domain controller without all the others, and they must share the
same backing store.

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.

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.  This 'implementation detail' (critical to
interoperability) is instead documented incompletely (in my experience)
in Microsoft behaviour notes, mapping the per-document Abstract Data
Modal onto LDAP and DRS attributes.  

There is a consistent abstract data modal that could have been chosen -
the X.500-derived LDAP schema, and described in the AD schema documents.
This encapsulates almost all the elements of the data modal - and is
abstract, not tied to an implementation (I deploy it on OpenLDAP and
Fedora DS). 

If this were the target abstract data modal, it would provide the
cross-document clarity to many of the problems I encounter on a
day-to-day process.  

I would appreciate any assistance you can bring to bear on the
documentation process to assist in this. 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20081104/3898e573/attachment.bin