Re: Explaining the new SAM

[Simo Sorce]

On Thu, 2002-10-03 at 03:13, Andrew Bartlett wrote:
 Jean Francois Micouleau wrote:
 
  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 ?
 
 I have a history of doing this - and I intend to continue...

I think jfm was criticizing the fact that you are building the interface
too much close to samr one, and that we do not have the need to do so.
I really do not think the jfm was proposing to use the samr interface
for internal use.
I agree to this vision, following too much the samr interface make us
only more unfriendly to the rest of samba code, that need much greater
flexibility as you recognized.

Simo.

-- 
Simo Sorce - [EMAIL PROTECTED]
Xsec s.r.l.
via Durando 10 Ed. G - 20158 - Milano
tel. +39 02 2399 7130 - fax: +39 02 700 442 399



signature.asc
Description: This is a digitally signed message part

Re: Explaining the new SAM

[Andrew Bartlett]

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.
 
 Ahhhok 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.

Andrew Bartlett

-- 
Andrew Bartlett [EMAIL PROTECTED]
Manager, Authentication Subsystems, Samba Team  [EMAIL PROTECTED]
Student Network Administrator, Hawker College   [EMAIL PROTECTED]
http://samba.org http://build.samba.org http://hawkerc.net

Re: Explaining the new SAM

[Jean Francois Micouleau]

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.
 
  Ahhhok 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 ?

J.F.

Re: Explaining the new SAM

[Andrew Bartlett]

Jean Francois Micouleau wrote:

 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 ?

I have a history of doing this - and I intend to continue...

It could be argued that the AuthRewrite was just a duplication of the
NETLOGON code.  Indeed, my original plans on that front called for the
use of NETLOGON to perform the operations.

However, I find the idea that the rest of Samba should call MS-defined
SAMR APIs less than appealing.  (As you well know, this is the approach
taken by Samba-TNG).  Instead, I prefer to construct an API that meets
the needs of the various 'users' (be it SAMR, the auth subsystem,
lanman.c etc) without using MS defined wire structures, and to which we
can add a little more flexibility.

For example, the auth subsystem allows the use of 'security=server',
which I could not force through the NETLOGON interface.  Similarly, I
expect that there will be other cases where we will want information
about a user that cannot be easily (or efficiently) extracted from SAMR
calls.  

Finally, I don't think that smbpasswd etc should have to go so far out
of their way (linking our rpc client and server code) in order to
perform their operations.

I prefer to take one step back, and construct an API that is influenced
by, but not dictated by, the SAMR pipe.

Andrew Bartlett

-- 
Andrew Bartlett [EMAIL PROTECTED]
Manager, Authentication Subsystems, Samba Team  [EMAIL PROTECTED]
Student Network Administrator, Hawker College   [EMAIL PROTECTED]
http://samba.org http://build.samba.org http://hawkerc.net

Re: 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 [EMAIL PROTECTED]
Manager, Authentication Subsystems, Samba Team  [EMAIL PROTECTED]
Student Network Administrator, Hawker College   [EMAIL PROTECTED]
http://samba.org http://build.samba.org http://hawkerc.net

Explaining the new SAM

[Andrew Bartlett]

It seems the 'new SAM' is suffering a bit on the PR front...  I'm hoping
this is mainly a matter of communication, because we (tried!) to put a
lot of thought into the interface.

Security in the 'new SAM'
=

One of the biggest problems with passdb is it's implementation of
'security'.  Access control is on a 'are you root at the moment' basis,
and it has no concept of NT ACLs.  Things like ldapsam had to add
'magic' 'are you root' checks.

We took this very seriously when we started work, and the new structure
is designed with this in mind, from the ground up.  Each call to the SAM
has a NT_TOKEN and (if relevant) an 'access desired'.  This is either
provided as a parameter, or implicitly supplied by the object being
accessed.

For example, when you call 

NTSTATUS sam_get_account_by_name(const SAM_CONTEXT *context, const
NT_USER_TOKEN *access_token, uint32 access_desired, const char *domain,
const char *name, SAM_ACCOUNT_HANDLE **account)

The context can be NULL (and is used to allow import/export by setting
up 2 contexts, and allowing calls on both simultaneously)

The access token *must* be specified.  Normally the user's token out of
current_user, this can also be a global 'system' context.

The access desired is as per the ACL, for passing to the seaccess stuff.

The domain/username are standard.  Even if we only have one domain,
keeping this ensures that we don't get 'unqualified' usernames (same
problem as we had with unqualified SIDs).

We return a 'handle'.  This is opaque to the rest of Samba, but is
operated on by get/set routines, all of which return NTSTATUS.

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.

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.

(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)

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.

Andrew Bartlett

-- 
Andrew Bartlett [EMAIL PROTECTED]
Manager, Authentication Subsystems, Samba Team  [EMAIL PROTECTED]
Student Network Administrator, Hawker College   [EMAIL PROTECTED]
http://samba.org http://build.samba.org http://hawkerc.net