Explaining the new SAM

[Andrew Bartlett]

Gerald Carter wrote:
> 
> On Wed, 2 Oct 2002, Andrew Bartlett wrote:
> 
> > The access checking is done by the SAM module.  The reason it is not
> > done 'above' the interface is to ensure a 'choke point'.  I put a lot of
> > effort into the auth subsystem to ensure we never 'accidentally' forgot
> > to check for null passwords, missed a restriction etc.  I intend the SAM
> > to be written with the same caution.
> 
> This seems like a lot of duplication of code and can lead to
> "There's a bug in SAM1 but not SAM2".  If the access checks
> will always be the same, why push them into the SAM module and
> force each write to cut-n-paste security descriptor code.

Yes, I am worried about that a bit.  The main issue is that I would like
a single read from LDAP - so we don't get a race there.  But we could do
it 'after the fact', and get each module to pass up the security
descriptor to the SAM interface layer.

> > The reason the access checking is not handled by the interface itself is
> > due to the different implementations it make take on.  For example, on
> > ADS, you cannot set a password over a non-SSL connection.  Other
> > backends may have similar requirements - we need to leave this policy up
> > to the modules.  They will naturally have access to 'helper' procedures
> > and good examples to avoid mishaps.
> 
> This still doesn't make sense.  The SSL requirement is separate from the
> security descriptor check (if that is really what you are talking of
> using).  Push the sec_desc check above the SAM and just let the
> SAM module fail if it has extra requirements.  Group common code together.

Yes, it could well belong in the interface layer.

> > (Furthermore, some backends my actually chose to push the whole ACL
> > issue to the remote server, and - assuming ldap for this example - bind
> > as the user directly)
> 
> I see this but I think it tends to muddy the water a little.
> What exactly are you calling a SAM?
> 
> > Each returned handle has an internal 'access permitted', which allows
> > the 'get' and 'set' routines to return 'ACCESS_DENIED' for things that
> > were not able to be retrieved from the backend.  This removes the need
> > to specify the NT_TOKEN on every operation, and allows for 'object not
> > present' to be easily distinguished from 'access denied'.
> >
> > When you 'set' an object (calling sam_update_account) the internal
> > details are again used.  Each change that has been made to the object
> > has been flagged, so as to avoid race conditions (on unmodified
> > components) and to avoid violating any extra ACL requirements on the
> > actual data store (like the LDAP server).
> >
> > Finally, we have generic get_sec_desc() and set_sec_desc() routines to
> > allow external ACL manipulation.  These do lookups based on SID.
> 
> So a SAM is a passdb with ACL's.  What else?

Groups and policies thown in, but it's not really meant to be that
massive.  One step at a time and such things.  Also a move to NTTIME in
the interfaces, and an attempt to cope with a wider scope of problems.

Mostly it's a rework so we could move further forward then passdb could
reasonably be streached.  It sounds big, but it really isn't...

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net