Explaining the new SAM

[Stefan (metze) Metzmacher]

At 23:21 02.10.2002 +1000, Andrew Bartlett wrote:
>Gerald Carter wrote:
> >
> > On Wed, 2 Oct 2002, Andrew Bartlett wrote:
> >
> > > > 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.
> >
> > Ahhh....ok I see now.  But it still seems like a lot of duplicated
> > code.
>
>I'm starting to agree that putting it in the interface is a 'good
>thing'.  If the backend wants to double-check, then that's fine, but the
>intereface should be handed back a sec desc to check itself.  (A SAM
>that really wants to get around this can return an allow-all sec desc if
>it must...).  This does make it harder for module writers to 'stuff up'.

what's about a BOOL flag in the SAM_METHODS struct :
BOOL access_check_intern;

if False the interface should handle the sec_check.
if True the backend will handle it.

And double access check isn't a good way!
(we want to handle large domains, and for this we have to be as fast as 
possible)


> > Taking another perspective, i'm still not convinced why a security
> > descriptor on each SAM object is needed.  What do we gain by it
> > at the cost of added complexity?
>
>NT allows these to be set remotely on each SAM object.  In particular
>the 'user cannot change password' is implemented in terms of an NT ACL
>on the user in the SAM.

We didn't have to store a SEC_DESC on each entry. We can use a default, but 
we have to be able to store it on each entry if the admin changes it 
explicit on the entry.


> > > > 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
> >
> > By policies you mean "rights" like "backup files" ?
>
>Also 'max password age' etc.
>
> > > 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.
> >
> > What "wider scope of problems"?  Without knowing what you are trying to
> > address, it's pretty hard to comment.
>
>Mostly to cope with all the things that can be set over the SAMR pipe.
>(most of which are above).  I think we are also meddiling a little in
>the LSA pipe too, which may or may not be a good thing...
>
>It may well make sense to store all the replication stuff in the same
>backend, to avoid having to run muliple synronistation setups.  (ie if
>LDAP is doing all the SAM stuff, make it keep the LSA secrets too).  I'm
>still thinking on this stuff, but that's the kind of longer-term I'm
>looking for.

that would be fine:-)


>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


metze
-----------------------------------------------------------------------------
Stefan "metze" Metzmacher <metze at metzemix.de>