Explaining the new SAM
Andrew Bartlett
abartlet at samba.org
Wed Oct 2 02:22:01 GMT 2002
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
More information about the samba-technical
mailing list