passdb redesign

[Mayers, Philip J]

Hmm. <warning - stream of consciousness follows>

I see two levels of isolation possible:

1) All NT-type information stored in a passdb, SMBD still handling the Unix
side of things

e.g.

setuid(pdb_get_uid(SAM_ACCOUNT_HND*));

2) All information stored in a passdb, SMBD calls generic functions in the
passdb API to do user-related things.

pdb_switchtouser(SAM_ACCOUNT_HND*);



It's worth noting that in one years time, I predict the majority of
authentications to Samba will be SNEGO-based, with GSSAPI tokens. I'm making
good progress on that - more details in a few days.

The design of the current passdb API or the new one will restrict what can
be done. It's important to distinguish getting user *information* from
actually authenticating and authorising a user. I believe they are separate
and have very little inter-dependency.

I suggest you drop all password/authtoken checking capabilities from your
current passdb API, and make it purely an informational one. But bear in
mind, the authentication API (which is basically going to need to be an
extended GSSAPI-style API) will have some interactions with the
informational data.

If you haven't already, look at the SSPI or GSSAPI (they're functionally
identical, just different APIs) for a good start of how to authenticate a
user with a given API. I envisage something where the server uses an
SNEGO-capable GSSAPI implementation purely for auth purposes. To support
downlevel clients, we fake up an NTLMSSP token using the information
available. For really downlevel clients, we have the plaintext password
available, and I have no problem with defining a GSSAPI plaintext mechanism
- suitable use of the word MUST with respect to not using it across
non-secure channels ought to do it.

One thing the SSPI has that GSSAPI doesn't is (effectively) a setuid call.
We would want a UseSecurityContext function (or equivalent) to drop down to
the given user. So, our SNEGO/GSSAPI library will have to call the user
information db to get the local username it should be using... There's more
crossover in one direction than another.

The advantage of that being that we can plug in additional mechanisms
completely independently of Microsoft - how about a PGP auth mechanism for
Samba? Easy, specify a GSSAPI mechanism for it. SecureID? Easy too.

So, we'd use an SNEGO/GSSAPI mechanism for authentication. When the user is
finally logged in, we get the information back from the auth API using the
aname and sname functions, and any informational data (required for PDC
support, for example) comes from there.

My 2 pence.


Regards,
Phil

+----------------------------------+
| Phil Mayers, Network Support     |
| Centre for Computing Services    |
| Imperial College                 |
+----------------------------------+  

-----Original Message-----
From: Gerald Carter [mailto:gcarter at valinux.com]
Sent: 09 November 2000 19:52
To: samba-technical at samba.org
Subject: RFC: passdb redesign


Here is my current stat of mind wrt passdb/*


Problems
--------
  o current samba code is filled by functions that half
    use passdb backend and half use lp_..() defaults from
    smb.conf

  o two structure are used to represent an account entry.
    smb_passwd {} and sam_passwd{}.  These are used 
    inconsistently through the code.  The major differences 
    exist between the rpc subsystem and normal file/print 
    serving operations.


The Proposal
------------

  o Introduction of new smb.conf parameter to specify the
    shared library to be used for accessing account information.

	passdb module path = <filemname>

  o removeal of smb_passwd {} struct all together and 
    replacement of universal use of sam_passwd {} via an 
    opaque handle.

  o removal of passdb_ops {} structure.  This struct is for
    defining a set of functions pointers which currently 
    implement the passdb API.  This was previously needed
    as passdb backend support was chosen at compile time.
    This will be replaced by a well defined and documented
    interface shared between the passdb API and the loadable
    backend modules.  More on this in a minute.

  o Implement support for the following backends

      - smbpasswd 	(file)
      - TDBPWB 		(local DB)
      - LDAP 		(using AD schema)

    This means the experiemental NIS+ support  
    will be removed.  I think the general stand on NIS+
    is that it is dying (at least that is my opinion).


Advantages
----------

  o experiement with shared libraries for future use relating 
    to MS-RPC pipe support

  o a single interface allows a single tool to access/update
    all passdb backends without recompiling.  The same tool
    can put from smbpasswd and push to LDAP.

  o fewer compile time descisions (except on platforms 
    that do not support shared libraries of course).

  o More flexibility. For example, you can use 
    include parameters to validate clear text logons 
    against /etc/passwd and encrypted logons against LDAP
    from the same server.


Proposed Interface
------------------

Functions for manipulating sam_passwd struct (common to all
backends)

   pdb_get...(SAM_ACCOUNT_HND *hnd)
   pdb_set...(SAM_ACCOUNT_HND *hnd)

Backend storage access functions which must be implemented
by each passdb module

   /* search functions */
   SAM_ACCOUNT_HND* pdb_getsampwnam (char* username);
   SAM_ACCOUNT_HND* pdb_getsampwuid (uid_t uid);
   SAM_ACCOUNT_HND* pdb_getsampwrid (uint32 rid);
   SAM_ACCOUNT_HND* pdb_getsampwent ();


   /* create a new (and empty) sam_passwd struct */
   SAM_ACCOUNT_HND* pdb_new_sam_account ();


   /* write change to persistent storage */
   /* add a new acount*/
   BOOL pdb_add_sam_account (SAM_ACCOUNT_HND *hnd);
   /* update an account entry */
   BOOL pdb_update_sam_account (SAM_ACCOUNT_HND *hnd);
   /* delete an account entry */
   BOOL pdb_delete_sam_account (SAM_ACCOUNT_HND *hnd);

  

Note that certain functions have been left out of 
the interface (e.g. getsamdispnam()) as these are often 
convienence functions and can easily be added to the basic
passdb.c general interface.

I have started working on this already.  It is the 
first step to implementing group mapping and LDAP support
(officially).  Comments welcome.






Cheers, jerry
----------------------------------------------------------------------
   /\  Gerald (Jerry) Carter                     Professional Services
 \/    http://www.valinux.com/  VA Linux Systems   gcarter at valinux.com
       http://www.samba.org/       SAMBA Team          jerry at samba.org
       http://www.plainjoe.org/                     jerry at plainjoe.org

       "...a hundred billion castaways looking for a home."
                                - Sting "Message in a Bottle" ( 1979 )