SAM Layers

Andrew Bartlett abartlet at
Wed Oct 2 03:20:00 GMT 2002

A bit of an explanation of where things fit in the 'new SAM' code:

We have 3 layers:


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

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

Andrew Bartlett

Andrew Bartlett                                 abartlet at
Manager, Authentication Subsystems, Samba Team  abartlet at
Student Network Administrator, Hawker College   abartlet at

More information about the samba-technical mailing list