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 > [EMAIL PROTECTED]
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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
