PASSDB: local and domain accounts

[Gerald Carter]

Folks,

Here are my current thoughts on winbindd, passdb, group 
mapping, etc... (after talking with JF and Tim).  Comments 
welcome :)

Basically we need to deal with a couple of design problems
(or issues, however you look at them).

  o What is the relationship of and interaction between
    the local passdb storage and winbindd?

  o local vs. domain accounts

I see winbindd and the passdb storage at the same 
abstraction layer (with possibly one abstraction 
layer covering the two to make them appear as a 
single mechanism).  So it would appear something like

   	        smbd
  ----------------------------------
	GetAccountInformation()

  ----------------------------------
	passdb 		winbindd
	(local)		(remote)

This gives us a nice distinction between local 
and domain accounts.  Here is my taxonomy:

  o security = user
	- Samba as a standalone server
	- Samba as a PDC
  o security = domain
	- Samba as a BDC
	- Samba as a domain member

I am ignoring security = share because it is really 
just a variant on user mode security from the passdb 
perspective.  I am also ignoring security = server
because it should be superseded by domain level security.

Now given the way an actual NT host works, we have 
the following

1)
  o NT as a domain member has a local sam as well 
    as access to the domain sam

  + Samba as a domain member should have a local list
    of account (those stored in the local passdb storage)
    and use winbindd for access to the domain SAM

2)
  o NT as a standalone server has only a local sam

  + Samba as a standalone server should utilize only
    the local passdb storage

3)
  o NT as a PDC has no local SAM.  Rather the local 
    sam becomes the domain SAM

  + Samba as a PDC should utilize the local passdb 
    storage for domain accounts.  No local accounts 
    are necessary

4)
  o NT as a BDC replicates the domain SAM into a 
    copy in the local sam

  + Samba as a BDC should replicate the domain SAM
    into a copy n the local passdb storage

Group mapping should be integrated into the passdb
for local accounts.  This would fit with what 
Jean-Francois has already started on.  The winbindd 
daemon already handles mapping between remote domain 
accounts and the dynamically allocated gid.

Here are some thoughts from Tim...

> OK here is a bit more info on some ideas for 
> passdb stuff.  In my opinion you need to be able to:
> 
>   - Read/write/update sam entries in a tdb on a pdc.

This works.

>   - Read entries from the unix password file (may have to
>     store encrypted passwords in an adjuct file).
> 
>  - Use local users from the passwd file (may need to
>    store encrypted passwords in an adjnct file)

This brings up my next thought: "The relationship between 
passdb and clear text authentication."

The combining on /etc/passwd and the passdb 
storage into one logical volume is an interesting 
problem.  I propose the following rules...

  o If there is no passdb local storage 
    implemented, use /etc/passwd as the local 
    SAM and fake up account information such 
    as rids, profile path, etc... as we currently 
    do for smbpasswd.

  o if a local passdb storage exists, use **only**
    that as the local SAM.  

This means that only accounts (and groups) in the 
current local passdb storage should be enumerated.
These could be ones from /etc/passwd (if there is 
no passdb storage defined) or Samba's own SAM
implementation in a TDB or LDAP.

Now for plaintext authentication, this solution will 
still work.  I should say that all passdb will work with
plain text passwords.  The main distinction made by as
passdb storage module is which accounts should be 
considered to be in the local SAM.

This solution will also work for the 'update encrypted = yes' 
scenario as well.  

Intuitively, things look like this

passdb modules		
---------------------------------------------
libpdbpasswd.so		/etc/passwd and fake
			up SAM_ACCOUNT.  This
			one is the default in the
			absence of any other modules.
				

libpdbsmbpasswd.so	identical in functionality
			to libpdbpasswd.so with the
			addition of support for 
			password encryption

libpdbtdbsam.so		full local SAM stored in a TDB

libpdbldapsam.so	full local SAM stored in an LDAP 
			directory

    

>  - use winbind users and pam_winbind

winbindd can point to a local Samba PDC running on the 
same host.

> Be able to choose combinations of all the above 
> as required.  The appliance is a good example - it needs 
> to be able to use local passwd users and winbind users as 
> a domain member but not display any local users itself.

So for our network appliance example, as a domain member
you will have accounts in \\DOMAIN and \\SAMBASERVER.
Viola!  The above proposed solution works.

There is one minor problem.  Really it has not so much 
to with Samba as it does with winbindd and pam_winbind.
Consider the case where you would like to configure sshd
for authenticating against remote domain accounts.
This is only case when operating as a domain member
(not as a PDC).

In this case, winbindd will only check against domain
accounts.  However, I can envision cases where you would
want to validate against local Samba accounts as well.
There is currently no way to access these.

No you may be thinking to yourself, "but local 
Samba accounts already exist in /etc/passwd.  You can 
use those."  However, consider the unification of
passwords.  What if the Samba lanman/nt password is 
different than /etc/passwd?  Also consider the case 
of uid allocation upon demand for creating new local 
accounts in samba.  These would never exist in 
/etc/passwd.  Only as a uid in a Samba TDB.

This problem can be solved in one of two ways:

  1) make winbind check local accounts on the 
     samba server (via MS-RPC) as well as domain
     accounts on the PDC

or,

  2) develop as pam_passdb.so and nss_passdb.so 
     module. 

I like #2 better as it maintains the distinction 
of passdb handling local accounts and winnbindd 
handling remote accounts.

What is required to make all this work is an account 
management tool.  The following functions implemented
by the passdb API are used to actually update persistent
storage

	BOOL pdb_update_sam_account(SAM_ACCOUNT*);
	BOOL pdb_add_sam_account (SAM_ACCOUNT*);
	BOOL pdb_delete_sam_account (char* username);

If you want to add update capabilities to the passdb
(/etc/passwd for example), then you write these routines.
Currently the pdb_add_sam_account() call for smbpasswd
requires that the UNIX account already exist.  The 'add 
user script' is called before pdb_add_sam_account() is.  This 
should be moved below the API.  smbd should not have to 
worry about this.  By moving the 'add user script' to 
a lower layer, things like "smbpasswd -a <user>" will work
even if the UNIX account did not exist beforehand.


Make sense?  We can support user manager as tool.  If so,
the I really think that we should follow the rpcclient / 
samedit path as well.






-- 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.eng.auburn.edu/~cartegw

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