A bit of an explanation of where things fit in the 'new SAM' code: We have 3 layers:
Application =========== This is where smbd, samtest and whatever end-user replacement we have for pdbedit sits. They use only the SAM interface, and do not get 'special knowledge' of what is below them. SAM Interface ============= This level 'owns' the various handle structures, the get/set routines on those structures and provides the public interface. The application layer may initialize a 'context' to be passed to all interface routines, else a default, self-initialising context will be supplied. This layser finds the appropriate backend module for the task, and tries very hard not to need to much 'knowledge'. It should just provide the required abstraction to the modules below, and arrange for their initial loading. We could possibly add ACL checking at this layer, to avoid discrepancies in implementation modules. SAM Modules =========== These do not communicate with the application directly, only by setting values in the handles, and receiving requests from the interface. These modules are responsible for translating values from the handle's .private into (say) an LDAP modification list. The module is expected to 'know' things like it's own domain SID, domain name, and any other state attached to the SAM. Simpler modules may call back to some helper routine. Special Module: sam_passdb --------------------------- In order for there to be a smooth transition, kai is writing a module that reads existing passdb backends, and translates them into SAM replies. (Also pulling data from the account policy DB etc). We also intend to write a module that does the reverse - gives the SAM a passdb interface. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net