Explaining the new SAM
Jean Francois Micouleau
Jean-Francois.Micouleau at dalalu.fr
Wed Oct 2 20:57:00 GMT 2002
On Wed, 2 Oct 2002, 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'.
> > 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.
> > > > 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.
It's getting clear that you are reinventing something we already have.
All your SAM api is simply the SAMR server pipe code. Why do you want to
implement a new api as we already have one ?
More information about the samba-technical